3. Firstly, you'll have to determine if your driver supports it. Run PackageInfo/QueryProperties.java that comes along with the Java3D demo bundle and see if sceneAntialiasingNumPasses has a value > 0. If it is 0, and if you're running DirectX version then try updating the driver.

If it is > 0, then make sure you've also passed in an appropriate "Template" -> GraphicsConfiguration -> Canvas3D like so:

. Firstly, you'll have to determine if your driver supports it. Run PackageInfo/QueryProperties.java that comes along with the Java3D demo bundle and see if sceneAntialiasingNumPasses has a value > 0. If it is 0, and if you're running DirectX version then try updating the driver.

If it is > 0, then make sure you've also passed in an appropriate "Template" -> GraphicsConfiguration -> Canvas3D like so:

Thank you, I'll try that out and get back to you.

Quote

Look at View#setFieldOfView(...)

I'm afraid I'm using parallel projection mode, so this has no effect. Screen scale doesn't seem to do the job either, or modifying the Screen3D's physical width and physical height.Perhaps it would be better if you saw the code. The important bits are down toward the end, in the Viewer class and camera() method.

Best approach is to render the UI to a texture that is kept on a transparent poly perpindicualr to the viewing lineand at a fixed distance from the viewpoint.Ther are a numerb of libaries to do this already floating around for J3D. I downloaed the one Dave Yazel wrote but havent ahd time to integtrate it into my game yet..

Thanks, that does seem the best option.

Quote

OK, then an option might be to apply a scaling factor to the Transform3D of the TransformGroup holding your ViewWorld.

New topic, for 10 points and a bonus round- How do I create a texture that maps to several overlaid (partially transparent) ImageComponents using different UV maps for each, for a single surface? Jeff, you didn't have to develop this for JNWN, by any chance?Also, shouldn't there be some class that allows you to generate textures dynamically at runtime?

You render whatever you want into a BufferedImage and then make a texture out of it.

I was afraid of that. That could be a significant drain on memory over a larger terrain map, which is what I had in mind. At 250x250 tiles, 1 meg per texel per tile isn't unlikely. I suppose I could cache common texture combos in a hashtable, but that might not cover all contingencies. I could try and implement RenderedImage to do things more cleverly, assuming Java won't brute-force things internally regardless...

Quote

A key is the ImageCOmponent2D class (see the J3D API docs.) In particular you are going to have to use the imageUpdater callback since you want to change the image while the poly is being displayed.

You render whatever you want into a BufferedImage and then make a texture out of it.

I was afraid of that. That could be a significant drain on memory over a larger terrain map, which is what I had in mind.

Once you have created the texture I believe you can dispose of the image.

I could be wrong, I'll double check with Kevin and Paul. But if this is tiled why are you writing them repatedly to one texture? Why dont you put one tile per texture and then assemble the tiles as geometry?

Clearly Im not following something still...

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

On the ui front I wrote a Java3D HUD around the same sort of time as David Yazel's. It's available in the resouces section of the NewDawn website. The source is there also. You can have mulit layers hud with different components on different layers so that you can have say a fixed window with a dynamic content on a closer layer, this way, you only have to refresh the dynamic content which is faster.

It uses the idea of a component painter, from the hud component you can just get a graphics 2D object, use Java2D calls to draw what you want, and then call update(), and the next frame will have the new contents drawn to it. I also created some utilities so you could create components that resize if the canvas does, stay at a fixed size, are positioned by screen coords, positioned by relative coords, or are a mix of any/all of the above.

It wasn't perfect, but it worked quite well.

If you want a copy you can go download it and use it, and the source is there too. And I'm also still around in these forums. David had real life take over so had to cut back, which is a shame as he was a useful member.

Once you have created the texture I believe you can dispose of the image.

Seems somewhat wasteful in any case.

Quote

Clearly Im not following something still...

I should explain in a little more detail.I have a basic terrain-display algorithm set up which generates 8 polies per terrain tile (except for those at the edges.) It's working well, thank you, but the boundaries between different terrain types are unnaturally sharp. From looking at warcraft 3 I noticed that they blended different terrain types together at the edges using a system where one terrain type was dominant over the other and would partially overlap the 'fringe' tiles. It's a good system, but it means that assigning a single texture to a given terrain tile don't cut it. And on a map with many (that is, 8 or so) terrain types, storing every possible fringe combo just isn't feasible (for n textures, you have (n+1)^8 combos, possibly more with a more comprehensive system, character footprints, special effects, building foundations, roads, splats and so forth.) So, I'll either have to generate them dynamically or cache common combos, or most likely both. A hassle, but if I restrict zoom I'll only have to do so for the relatively small number of tiles onscreen at one time.EDIT: I've attached a pic where you can see the problem yourself.

Quote

HiOn the ui front I wrote a Java3D HUD around the same sort of time as David Yazel's. It's available in the resouces section of the NewDawn website. The source is there also. You can have mulit layers hud with different components on different layers so that you can have say a fixed window with a dynamic content on a closer layer, this way, you only have to refresh the dynamic content which is faster.

Once you have created the texture I believe you can dispose of the image.

Seems somewhat wasteful in any case.

Quote

Clearly Im not following something still...

I should explain in a little more detail.I have a basic terrain-display algorithm set up which generates 8 polies per terrain tile (except for those at the edges.) It's working well, thank you, but the boundaries between different terrain types are unnaturally sharp. From looking at warcraft 3 I noticed that they blended different terrain types together at the edges using a system where one terrain type was dominant over the other and would partially overlap the 'fringe' tiles. It's a good system, but it means that assigning a single texture to a given terrain tile don't cut it.

Cant you just multi-texture the tile?

if not for some reason, cant you just pre-create "transition textures" for the tiles at the edges? This is what many 2D games do.

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

Cant you just multi-texture the tile?if not for some reason, cant you just pre-create "transition textures" for the tiles at the edges? This is what many 2D games do.

"(for n textures, you have (n+1)^8 combos."So, for 3 basic textures, that's roughly 65,000 transition textures I'd need to prepare. Actually, now that I think of it, the terrain type dominance hierarchy would cut this down closer to n^8, but it's still exponential.I've considered multi-texturing, but that just brings up the same problem on a smaller scale. It *would* reduce the brute-force approach to 8(n^3), if I assign a different texture to polygon, which is manageable for a fairly respectable number of textures. I was just hoping J3D would have some built in dynamic image-compositing system to save me the trouble.

Well it shouldnt be improtant unelss you are short on memory.I am ALMOST positive that when you create a texture Java3D copies the image to an internal J3D structure and the source can be disposed.

Two words. Exponential. Complexity.I'd have to use image-by-reference as well as rendering dynamically and hope that java doesnt hang on to data persistently regardless, depending on what's done with the Raster ("...the data itself is not necessarily copied (although it may be, depending on the value of the yUp flag, the format of the ImageComponent, and the format of the RenderedImage.")

Quote

But Ill check next time I see Kevin and Paul. Unfortunately thats not likely to be til tuesday as Im doing exec meetings monday.

No hurry. I'm beginning to think a more convenient solution would be to create some extra semi-transparent polygons just above the terrain surface and hope no-one looks too closely.

Well it shouldnt be improtant unelss you are short on memory.No hurry. I'm beginning to think a more convenient solution would be to create some extra semi-transparent polygons just above the terrain surface and hope no-one looks too closely.

If this would work, why wouldnt multi-texturing to combine the etxtures ona single poly work?

Im still not quite following that. It seems to me you could make fethered edge textureto layover the seam and combine with the next texture where the shift occurs...

Got a question about Java and game programming? Just new to the Java Game Development Community? Try my FAQ. Its likely you'll learn something!

If this would work, why wouldnt multi-texturing to combine the etxtures ona single poly work?

Good grief. I completely missed the multi-texturing capabiltiies in the Appearance class. I thought you were talking about applying different textures to different polys within the same tile! Sorry, pardon my ignorance.

Tried the extra polys solution with very... mixed results. Technically it's working, Java just handles the display terribly. Problems with transparency blending again. I'll post about them on the other thread.

I'm afraid I'm using parallel projection mode, so this has no effect. Screen scale doesn't seem to do the job either, or modifying the Screen3D's physical width and physical height.Perhaps it would be better if you saw the code. The important bits are down toward the end, in the Viewer class and camera() method.

For using screenScale, are you specifying View#setScreenScalePolicy( View.SCREEN_EXPLICIT ) ? If not, try it. As an alternative to screenScale or scaling the ViewWorld, you could also try using a scaling on the ViewPlatform Transform.

For using screenScale, are you specifying View#setScreenScalePolicy( View.SCREEN_EXPLICIT ) ? If not, try it. As an alternative to screenScale or scaling the ViewWorld, you could also try using a scaling on the ViewPlatform Transform.

Good idea. I've used SCALE_EXPLICIT (I think) with some success, but I'm going to give the TransformGroup option a shot.

One more question. Is there any simple way to synchronise my Geometry updates with the main rendering loop within the Canvas3D? The preRender(), postRender() etc. methods won't allow me to do this, and pure immediate-mode rendering is probably more hassle than I need right now.

Also, an exact explanation of how to convert from screen x/y coordinates to their equivalents in 3d space (assuming fixed depth and a straightforward axial projection.) I've tried fiddling about with physicalScreenWidth in Screen3D but can't seem to get the exact numbers I need. Also, clipping distances seem to alter when I resize the screen.

One more question. Is there any simple way to synchronise my Geometry updates with the main rendering loop within the Canvas3D? The preRender(), postRender() etc. methods won't allow me to do this, and pure immediate-mode rendering is probably more hassle than I need right now.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org