Lotta hassle with 11/24/03 release

[Java Cool Dude]

Now even the JWS demo on the home page that involve interaction crash blaming it on:

1   2

java.lang.Error: Illegal Scenegraph Modification         at com.xith3d.scenegraph.View.checkForIllegalModification(View.java:256)

Sigh! Looks like it's suicide time

[Java Cool Dude]

Fixed tada

1	main.view.stopView();

That's all what it is required to prevent my demo from crashing.
I call that once just before I detach attach some BranchGroup

[Daath]

actaully I just got same exception using latest build

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

[Java Cool Dude]

actaully I just got same exception using latest build

Dude wait till you bump into some other nasty exceptions as well, I had to throw view.stopView() everywhere to get my work up and running again :/

[DavidYazel]

Sorry guys.  The check which you are referring to can be deactived in View.java, there is a constant there which controls whether the check is done.

We could also remove it completely, or tie it to a property.

Please remember that it is a design tenant that the scenegraph is not threadsafe.  Having a swing component modify the scenegraph means that the swing thread is modifying the scenegraph.  If you add a branchgroup or change a transform while the view is rendering it will eventually bite you bad, and believe me that bug is hard to track down.

Many of the users of Xith3d are writing demos and perhaps arnt interested in building a solid game rendering engine.  For those of you that are, remember that you should be updating the scenegraph between frames, not while the view is running.  In Magicosm we have a lot of messages coming into the client on different threads.  We queue up scenegraph modifications and process them each frame.  This is done by having a SceneUpdaterInterface which can be implemented to perform scene modifications.  So for example we have an UpdateAddBranchGroup and UpdateChangeSwitch types.  In addition, groups of updates which must be done in between a frame switch are added to a special UpdateTransaction which is guarenteed to be executed all at once.  Other than that the scene updater, which is called once per frame, paces the updates so that no one update to the scenegraph takes too long.

Perhaps this type of archtiecture can be an add on to Xith3D to provide a more complete and robust game engine, but I don't think it belongs in the core.  How people design their frame rendering loops is very unique to their project and I don't want to go down the path of Java3d which took it to incredible heights to ensure that the scenegraph could be modfied by differnet threads and still work.

[endolf]

Hi
 Right, if your are updating the scenegraph outside of your rednering thread you *have* to sync them up, which the view.stopView() does. What I've done in the past with java3d and am in the process of doing again for xith is having a data model of my game state and a 3d model of it, nice and seperate, seperation of data and presentation , the data model gets updated on the fly from swing or mouse/keyboard events. The thread with the view.renderOnce() in it runs round rendering as fast as it can with an update before each render that updates teh 3d model from their respective data model components.
 From my own point of view removing that check is just asking for trouble . If your going to do it can we have it as a property that is enabled by default?

Cheers

Endolf

[Preston]

Please remember that it is a design tenant that the scenegraph is not threadsafe.  Having a swing component modify the scenegraph means that the swing thread is modifying the scenegraph.  If you add a branchgroup or change a transform while the view is rendering it will eventually bite you bad, and believe me that bug is hard to track down.

Thanks for that article. It explains some things I noticed a short time ago.

Most of the collections are thread-unsafe, too, by default. It's a good design decision that those who need multi-threading have to activate this with own means.

How people design their frame rendering loops is very unique to their project

I fully agree. The typical model-view-controller pattern logic belongs to the application.

Xith3d is so nice.

[Daath]

Dave's post should go to Xith3D FAQ -  I am sure newcomers will run into that issue again and again. Also idea about having xxxUpdate interfaces is most excellent one. Worth reading every word!

[Jens]

This is now a FAQ. Please complain if the explanation isn't good.

[Daath]

Complain? ...no way   .. I shall resolve into reading DOCS and FAQ once in a while  

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

[shochu]

I set up my mouse and keyboard listener's like in the demo.  I'm using the keyboard to move my character around on the screen by updating the translate tranform on the model.  I noticed that when I hold down the keyboard to move my character he flashes and jumps on the screen.  Would this be because the keyboard input is done in a sperate thread and it's trying to make changes to the scenegraph while the view is being rendered?  If this is the case how would I change the mouse and keyboard input to be threadsafe?  THanks for the help!

[kevglass]

Generally you have a listener that sets flags to indicate that keys are pressed.

Then in the scenegraph thread you check the thread and cause the effects. This way, no actual change take place in the AWT event thread (that has responded to the key press).

Kev

[shochu]

THanks .... I'm working on that now =)