Simple question. How do I pursuade a given Canvas3D to show more of the virtual world, without altering the viewpoint or resizing the actual window?
How do I impose a 2D UI on top of a 3D canvas? Or should I render the UI offscreen and slap it on top of the canvas3D every frame?
Is there some reason why View.setSceneAntialiasing(true) would have no effect?
Thanks for your time.
Look at View#setFieldOfView(…)
There are folks here who have studied it better than I.
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:
GraphicsConfigTemplate3D tpl = new GraphicsConfigTemplate3D();
tpl.setSceneAntialiasing( tpl.PREFERRED );
GraphicsConfiguration config = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getBestConfiguration( tpl );
Canvas3D c = new Canvas3D( config );
[quote]. 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:
[/quote]
Thank you, I’ll try that out and get back to you.
[quote]Look at View#setFieldOfView(…)
[/quote]
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.
import java.awt.*;
import javax.media.j3d.*;
import javax.vecmath.*;
import com.sun.j3d.utils.universe.SimpleUniverse;
import com.sun.j3d.utils.behaviors.vp.OrbitBehavior;
public class Engine {
SimpleUniverse universe;
BranchGroup master;
Viewer viewer;
Engine() {
stage();
lights();
camera();
action();
}
void stage() {
viewer = new Viewer();
universe = new SimpleUniverse(viewer);
master = new BranchGroup();
master.setCapability(Group.ALLOW_CHILDREN_EXTEND);
master.setCapability(Group.ALLOW_CHILDREN_READ);
master.setCapability(Group.ALLOW_CHILDREN_WRITE);
}
void lights() {
BoundingSphere bounds = new BoundingSphere(new Point3d(0.0, 0.0, 0.0), 1000.0); // Create a bounds for the light source influence
AmbientLight ambient = new AmbientLight(true, new Color3f(1, 1, 1));
ambient.setInfluencingBounds(bounds);
master.addChild(ambient);
Vector3f direction = new Vector3f(0.35f, -0.5f, -1.0f);
DirectionalLight directional = new DirectionalLight(true, new Color3f(1, 1, 1), direction);
directional.setInfluencingBounds(bounds);
//directional.setCapability(DirectionalLight.ALLOW_DIRECTION_READ);
//directional.setCapability(DirectionalLight.ALLOW_DIRECTION_WRITE);
master.addChild(directional);
}
void camera() {
OrbitBehavior orbit = new OrbitBehavior(viewer);
orbit.setRotXFactor(5);
orbit.setRotYFactor(0);
orbit.setZoomFactor(5);
orbit.setTransXFactor(5);
orbit.setTransYFactor(5);
orbit.setSchedulingBounds(new BoundingSphere(new Point3d(0.0, 0.0, 0.0), 10000.0));
//System.out.println(universe == null);
universe.getViewingPlatform().setViewPlatformBehavior(orbit);
TransformGroup vtg = universe.getViewingPlatform().getViewPlatformTransform();
Transform3D moveback = new Transform3D();
moveback.setTranslation(new Vector3f(0.0f, 0.0f, 100.0f));
vtg.setTransform(moveback);
View view = universe.getViewer().getView();
view.setTransparencySortingPolicy(View.TRANSPARENCY_SORT_GEOMETRY);
view.setDepthBufferFreezeTransparent(false); //aha!
view.setSceneAntialiasingEnable(true);
view.setBackClipDistance(10000.0);
view.setProjectionPolicy(View.PARALLEL_PROJECTION); //Will have to scale the sprites appropriately.
//view.setScreenScale();
//view.setViewPolicy(View.HMD_VIEW);
//view.setWindowEyepointPolicy(View.RELATIVE_TO_FIELD_OF_VIEW);
//System.out.println(view.getFieldOfView());
//view.setFieldOfView(Math.PI);
}
void action() {
master.compile();
universe.addBranchGraph(master);
}
void addSprite(Sprite sprite) {
sprite.update();
sprite.compile();
master.addChild(sprite);
}
static class Viewer extends Canvas3D {
final static GraphicsConfiguration CONFIGURATION = CONFIGURATION();
final static GraphicsConfiguration CONFIGURATION() {
return GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice().getBestConfiguration(new GraphicsConfigTemplate3D());
}
Viewer() {
super(CONFIGURATION);
Screen3D screen = getScreen3D();
double w = screen.getPhysicalScreenWidth(), h = screen.getPhysicalScreenHeight();
System.out.println(w + " " + h);
screen.setPhysicalScreenWidth(w * 20);
screen.setPhysicalScreenHeight(h * 20);
}
}
}
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…
OK, then an option might be to apply a scaling factor to the Transform3D of the TransformGroup holding your ViewWorld.
[quote]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…
[/quote]
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.
[/quote]
I shoulda thunk of that.
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.
There is code that does this in JNWN in the MDLTranslator (https://jnwn.dev.java.net/source/browse/jnwn/src/com/worldwizards/nwn/j3d/MDLTranslator.java)
A key is the ImageCOmponent2D class (see the J3D API docs.) In particular yo uare going to have to use the imageUpdater callback sdince yo uwant to chnage the image while the poly is being displayed.
[quote]You render whatever you want into a BufferedImage and then make a texture out of it.
[/quote]
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.
[/quote]
No worries, I’m used to GeometryUpdater.
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.
[/quote]
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…
Hi
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.
Endolf.
[quote]Once you have created the texture I believe you can dispose of the image.
[/quote]
Seems somewhat wasteful in any case.
[quote]Clearly Im not following something still…
[/quote]
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]Hi
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.
[/quote]
I’ll take a look once I can start the UI coding. Thanks again.
Seems somewhat wasteful in any case.
[quote]Clearly Im not following something still…
[/quote]
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.
[/quote]
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.
Btw End, you just convicned me to use your GUI lib for JNWN 
[quote]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.
[/quote]
“(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.
[quote]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.
[/quote]
Not to pry, but any word on that issue? What’s happening internally might be important.
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.
But Ill check next time I see Kevin and Paul. Unfortunately thats not likely to be til tuesday as Im doing exec meetings monday.
[quote]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.
[/quote]
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.
[/quote]
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…
[/quote]
[quote]If this would work, why wouldnt multi-texturing to combine the etxtures ona single poly work?
[/quote]
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.