Why does it

[Java Cool Dude]

mad flicker when I try to use the function view.getTransform().lookAt(...) to move around my 3D world?
Besides when I change the location of the eye, the effect lasts even less than a second before it gets back to where it was + more flickering...
Grrrrrr

[Java Cool Dude]

lookAt(new , new , new) strangely fixed it...

[Yuri Vl. Gushchin]

Strange...

BTW, I had similar behavior when my changes to lookAt() were not synchronized with rendering thread, so the eye position was changing in the mid of rendering pass (your instance of View can be used for such sync).

Yuri

Games published by our own members! Check 'em out!

[DavidYazel]

He is right.

Lookat unfortunely modifies the input parameters.

[Java Cool Dude]

He is right.

Lookat unfortunely modifies the input parameters.

Can you fix that Sir

[Yuri Vl. Gushchin]

I even don't know [read: don't think] it should be fixed because of it will introduce synchronization calls in the rendering pass.

I believe it should be done on application level [at least for now].

Yuri

[swpalmer]

Should thread local storage be used to avoid synchronzation?

[abies]

If this is synchronization issue, I think we should consider more strict rules about what can and what cannot be done at what point.

For me, calling ANY scenegraph method from anything other than rendering thread is major offense. This includes direct modification of values from AWT event thread. AWT listener should only enqueue actions/events which will be processed later by main rendering thread - be it in Behaviour, or just before/after renderOnce in main loop.

In java3d, it was possible to change scenegraph from event thread, because all access was done through synchronized messages, which where processes later by rendering thread. In xith3d, with direct access to everything, I think it should be the first big advice for any programmer - do not touch scenegraph from event thread.

[kevglass]

Absolutely!

Could this be enforced this via some checking on the current Thread (compare to the rendering Thread). An assert would seem to be ideal here, assert if you're making modifications from any thread other than the rendering thread?

Kev

[Jens]

I completely agree here and will include this in the tutorials.

Games published by our own members! Check 'em out!

[endolf]

I agree, one of the things I learned from doing java3d was to use behaviors for *everything* that touched the scenegraph, I have a TransformGroupUpateBehavior (or something like that) so I can set a transform during a frame render and  it won't take effect untill the bahvior fires inbetween the next frames.

Endolf