next »

[outlawski]

Hi Folks,

i spent a year on programming a game project based on Java3D and got recently in troubles with this engine. But before moving to the other technology, i would like to ask your advice about some specific Xith features.

1. Terrain CLOD: is there any continuous level of detail or ROAM algorithm for representing huge terrains in Xith3D?
2. Clean transformations: while moving away from coordinate system origin (let's say 1E7, 1E7, 1E7), is there any jittering while transforming an entity, or camera? Right now, this is the kick out criteria with Java3D. As soon as my entities get beyond 100km distance, the position setting and transformations get dirty and inexact.
3. Is the coordinate system of Xith same as in Java3D?


Kind Regards
Paul

[Marvin Fröhlich]

Yes, there is a terrain implementation in Xith3D. But I don't know the exact way, it is implemented. It just wasn't my business. But the terrains in the testcase are pretty large and I do know, that terrain tiles are used to lazy-load only the parts around the camera.

The coordinate system in Xith3D is the same as in Java3D by default, but can be changed to anything. The coordinate system shifting is something, that was once in Xith3D. I never understood, what it was good for and nobody seemed to use it and it was spamming the code base a little. So I removed it quite a while ago. But I think, this is pretty easily added, since it is not too complicated. Actually this is just a virtual vector offset to the camera. If you're in a specific "cell" of your world, all other cells are transformed by this vector (well very raw description).

So the answer is, yes, this is theoretically possible, but would need slight tweaking of the code base.

Marvin

[outlawski]

Hi Marvin,

thanks for the quick answer. My greatest problem with Java3D for now is the unsharp positioning. As soon as my vehicle is far away from origing (more than 100000 units, in terms of J3d 100km) the model positioning gets unexact and "noisy". I tuckled the problem on the native side: J3D performs fine the transformation calculation with doubles but finally passes all the data in float format to OpenGL/Direct3d. So the position for rendered object is less exact then calculated in j3D. Classical problem overseen here. How about Xith3D. What is the current state of JOGL/LWJGL in this respect?

Is it possible to control, which matrix transformation functions are used? From what i remember about OpenGl, they have for any gl...f.. function according gl...d.. function for doing same in double format.


Regards
Paul

[Marvin Fröhlich]

Xith uses floats only. But as I said, this problem can be pretty easily worked around. If the camera is inside of a virtual cell (subspace of the whole space), use different coordinates than when the camera is outside.

I can try to have a look at the code this evening, if it is possibly to add code for that will little effort.

Marvin

[Marvin Fröhlich]

Just to make sure. It would be enough, if you would (for example) attach an offset vector to a RenderPass or BranchGroup (root) and when its children are rendered all the used (effective) matrices are offsetted by this vector. Is this true? If yes, it's pretty simple. All the matrices would be calculated in float precision, but in a small subspace, which is offsetted after all.

Marvin

[outlawski]

Marvin, thank you very much  for the research and great input!
Most probably Xith3D would suffer from same problems as Java3d here. I used of course same approach there. The Model is in transformation group, rotations and movement applied on the TG, but since the distance is beyond floating point number precision, the models are getting wobbly. Repeated positional update produces slightly different result, i.e. the model's position vary. F.e. you are 1e7 meters away from coordinates origin and move inside camera of the vehicle or the the vehicle itself. Fascinating: you can actually see the error rooted in float use while f.e. changing the model's position by just x += .001;


BTW, is it difficult to port Java3D based code to Xith3D? I believe that Xith3D follows the same JSR proposal, so the Xith3D class interfaces might be pretty similar.


Kind Regards and thanks!
Paul

[Marvin Fröhlich]

Ok, I thought the only problem was doing all the nested matrix multiplications in float precision when the out most matrix has very large values. In this case our solution would work. Otherwise you would just need a sub space definition for each offsetted BranchGroup. And if the camera is within this group, the offset is not in effect for this group, but all the other groups are offsetted appropriately.

Example:

Code:

|0         |10        |20    C   |30        |

This would be your subspaces simplified to one dimension. Each subspace has an offset (a scalar in this example, a vector in 3d). Now the camera is where the C is. All objects in this group would not be offsetted. All objects in the first group would be offsetted by 0 - 20, the second group by 10 - 20 and the fourth group by 30 - 20. So the closer to the camera, the higher the precision and vice versa.

Whould that work?

BTW, is it difficult to port Java3D based code to Xith3D? I believe that Xith3D follows the same JSR proposal, so the Xith3D class interfaces might be pretty similar.

This is not true anymore. Xith has a way more improved API and doesn't carry all the rubbish from the Java3D API anymore. Though it is indeed still similar here and there. I must admit, that I have never ported Java3D code to Xith code.

Marvin

[badboyboogey]

It's been about 3 years since I made the move from J3D to Xith3D, and havn't gone back once.
The porting of my code was relativly simple.. The scenegraph basics are all the sam..
eg. A TransformGroup in J3D is still called a TransformGroup in Xith
A Shape3D in J3D is still called a Shape3D in Xith.
the only major differences really are the way you set up the initial engine, and the math library..

in javax.vecmath.Point3f for example you would use x=point.x;
while with openmali you use point.getX(x);
Thats probibly the worst task going through and all your classes with find and replace.

Well theres bound to other differences now, but Xith is leagues ahead in my opinion.. give it a try..
BTW I'm currently using a 163.84X163.84 (and will handle as big a mosaic tile landscape as you can make) terrain generated with L3DT in my project so yes it handles large landscapes beutifully

Which brings me to a question for Marvin, Does Mathias Henze still have anything todo with xith? (I have some question about the ChunkedTerrain and some features to add to it)

[Marvin Fröhlich]

Which brings me to a question for Marvin, Does Mathias Henze still have anything todo with xith? (I have some question about the ChunkedTerrain and some features to add to it)

No. He has personal duties and doesn't have time for open source in general anymore.

Marvin

[Jankovic]

I completely agree, great aricle! I’m glad I stumbled across this website!

[outlawski]

I solved the problem same way as you suggested to do in Xith3D and it works... at least with DirectX pipeline. The OpenGL and JOGL piplines produce flickering effects on the terrain. C-LOD is a fine solution for great areas anyway: 90x90 km area visible all the time, variable detail level, 1025x1025x3 floats are the baseline information for building and re-building terrain.

Java rocks  !

Thanks for inspiration, Marvin!

P.S. Project screenshots: http://www.flickr.com/photos/43342833@N04/

[ChrisE]

Looks great! Good work sir (or madam).

What did you settle on for doing terrain? ROAM, or some kind of chunked LOD?

Out of curiosity, saw that you are using Perforce...how's it treating you?

[terrence530]

I am agree with you...Nice work..It's Seems like a lot of effort has been put into this.. Keep up the good work....

[flatbrokegtrplyr]

I'm writing a Java application that contains multiple windows.  Some will display streaming video, some will display 3d objects that update periodically, other components will include updating text.

I've never worked with any Java 3D technology and I'm checking out Xith, Java3D, JOGL, LWJGL, etc...

Does Xith lend itself well to providing "3d windows" on a 2d display (vice what I'd typically think of as a 3-d world with a 2d UI)?

Any advice would be greatly appreciated.

Thanks.

[Marvin Fröhlich]

Xith integrates seamlessly into your existing Swing environment.