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.