Hi Artur > [...] it seems to be float precision error. It is not important that you use doubles - > java3d will still convert them to floats internally (I also do not think that > any of cheap GPUs out there support double precision - but I may be > mistaken). > [...]
I am conscious about that float and even double may not suffice to represent locations and transformations to a certain precision (in particular when dealing with cosmical distances;) and also know about the fact, todays GPUs mostly (or maybe even entirely) only use single precision floats. I'm not sure about, but as far as i know java3d uses doubles internally as long as possible until passing it's data to the system APIs (be it OpenGL or DirectX). In fact the data will converted to single precision when passing them to the GPU at the latest. > Moving both viewplatform and object by similar transform will degrade > quality. You should try to keep all objects as close to center as > possible - within 100000 units let say. Exatly this is the point! The only transform i apply is a transform to the viewplatform: viewTransform.mul(moveTrans); If we talk about precision, this is the only point, where precision may play a role. The multiplication is only numeric, so errors will surely occur and accumulate over time. BUT after this, i do no more transformations, i just take the translational part out of the viewtransform (-matrix) and rebuild my objecttransform: viewTransform.get(viewTranslation); StarsTransform.setTranslation(viewTranslation); StarsTransformGroup.setTransform(StarsTransform); viewTransformGroup.setTransform(viewTransform); So in turn i should have two transforms with should be equal (at least in the translational parts). (In fact i tested it, objecttransform and viewtransform ARE equal the whole time in my testcase.) So even if java3d would use integers internally, after all the transforms are the same ;) The error in the rendering persists nevertheless: object- and viewtransform are not reflected in the same frame although the APIDoc (javax.media.j3d.Behavior) states that this is guaranteed: "[...] All modifications to scene graph objects (not including geometry by-reference or texture by-reference) made from the processStimulus method of a single behavior instance are guaranteed to take effect in the same rendering frame. [...]" > Using normal rendering to display objects at great distance is not a > right solution - you should probably cut world at some point and project > rest of things at background object if you really need to, scaling them > accordingly. I already do something similar in my project. I use a logarithmical transform (in scale and position) to project objects into the viewvolume wich would be clipped by the far clippingplane otherwise. But this is another problem wich does'nt matches the topic ;) -emanuel -- +++ GMX - Mail, Messaging & more http://www.gmx.net +++ NEU: Mit GMX ins Internet. Rund um die Uhr f�r 1 ct/ Min. surfen! =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
