Hi Alejandro, i think, the package-info in the first line of the sources is wrong ( package jittertest; ) try remove it and recompile, i think it should work then
-emanuel > After compiling, this is the exception I get when I run your code: > > Exception in thread "main" java.lang.NoClassDefFoundError: testJitter > (wrong > name: jittertest/testJitter) > at java.lang.ClassLoader.defineClass0(Native Method) > at java.lang.ClassLoader.defineClass(Unknown Source) > at java.security.SecureClassLoader.defineClass(Unknown Source) > at java.net.URLClassLoader.defineClass(Unknown Source) > at java.net.URLClassLoader.access$100(Unknown Source) > at java.net.URLClassLoader$1.run(Unknown Source) > at java.security.AccessController.doPrivileged(Native Method) > at java.net.URLClassLoader.findClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClass(Unknown Source) > at java.lang.ClassLoader.loadClassInternal(Unknown Source) > > Why is it happening? > > Alejandro > > > -----Original Message----- > > From: Discussion list for Java 3D API > > [mailto:[EMAIL PROTECTED]]On Behalf Of Emanuel Brzostowski > > Sent: Friday, November 15, 2002 9:23 PM > > To: [EMAIL PROTECTED] > > Subject: Re: [JAVA3D] no Sync when using Behavior processStimulus (some > > code > > > > > > Hi > > > > I see my argumentation was a bit short-sighted. > > The samplecode is in the attachment, hope this helps. > > > > > You might be able to use the Background node as a workaround > > Maybe for this case i used in my sample (Stars in the > > Background), but there > > are other things in my application, which can't be done this way, > > so leading > > me to the same problems. > > I already thought about using locales too, and i surely will have to use > > them, when i start to model bigger parts of the cosmos. > > > > - emanuel > > > > > > Date: Fri, 15 Nov 2002 14:21:18 +0100 > > > > From: Emanuel Brzostowski <[EMAIL PROTECTED]> > > > > > > > > > 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 ;) > > > > > > Because this is a scenegraph, the view transform has to be inverted > and > > > multiplied with the object transform to get the transform from object > > > coordinates to view platform coordinates (and from there to eye > > > coordinates and > > > projection/clipping coordinates). But since the view and object > > > transforms are > > > just translations, Java 3D should recognize that all it needs to do is > > > subtract > > > the translation components. > > > > > > Bottom line, we can't tell from the code snippets and description you > > > provided > > > whether this a user error, a problem with scene graph update > > > synchronization, a > > > transform problem, or some inherent precision limitation. Send > > us a small > > > but > > > complete test application that reproduces the problem and we'll > > be able to > > > investigate further. > > > > > > You might be able to use the Background node as a workaround -- it was > > > designed > > > to eliminate translation effects, rendering the Background geometry > "at > > > infinity". And as you noted, the problem is only with large > > distances, so > > > you > > > might consider keeping your objects closer to the origin, or > investigate > > > the > > > use of multiple Locales with different origins in high-resolution > > > coordinates. > > > > > > -- Mark Hood > > > > > > > > ================================================================== > > ========= > > > 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". > > > > > > > -- > > +++ GMX - Mail, Messaging & more http://www.gmx.net +++ > > NEU: Mit GMX ins Internet. Rund um die Uhr f�r 1 ct/ Min. surfen! > > -- +++ 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".
