next »

[ChrisE]

I'm attempting to do some visualization work using Xith, and am having a couple of conceptual issues.

First, I'm unsure how easy it is to change the geometry attached to a node during runtime. As far as I can tell, the Shape3D subclass of Leaf is what actually holds some sort of geometry, which in turn actually holds the triangles or whatever I want to draw. When I change this geometry, will the bounds of the Leaf containing it update, and propagate up the graph as well?

Second, I'm under the impression that I need to store external references to my Leaf and Geometry objects to interface with them outside of Xith; I believe this because I have an external data model I am interacting with, and am mostly using Xith for rendering and culling. Is this correct?

Third, I think that in order to change a Geometry object, I need to have some way of locking it if being accessed through an external reference as described above. How would I go about updating the geometry on a separate thread (in this case, a user sketching thread), and then having that carried over into Xith?

In summation:
1. Can geometry be updated at runtime for a Shape3D?
2. Will the update in (2) update the bounds and propagate up the graph correctly?
3. Is the use of external references to Xith nodes an accepted practice (thus allowing me to back the nodes with data model information that would like to change their geometry)?
4. Is there a thread-safe way of manipulating the geometry in (3)?

I really appreciate any help you can give on this!

-Chris

[Marvin Fröhlich]

As far as I can tell, the Shape3D subclass of Leaf is what actually holds some sort of geometry, which in turn actually holds the triangles or whatever I want to draw.

Yes

When I change this geometry, will the bounds of the Leaf containing it update, and propagate up the graph as well?

Yes

Second, I'm under the impression that I need to store external references to my Leaf and Geometry objects to interface with them outside of Xith; I believe this because I have an external data model I am interacting with, and am mostly using Xith for rendering and culling. Is this correct?

I'm not sure, if I got you right. But I think, this is not true. Xith3D doesn't force or encourage you to lay any kind of interface over the geometry or shape API. Of course you're free to do so.

Third, I think that in order to change a Geometry object, I need to have some way of locking it if being accessed through an external reference as described above. How would I go about updating the geometry on a separate thread (in this case, a user sketching thread), and then having that carried over into Xith?

Have a look at the ScheduledOperation class and Updatable interface. These are the techniques, that xith provides to manipulate the scenegraph from another thread.

I also suggest to read XIN (Xith3D in a nutshell), available on our homepage. And it is certainly not a bad idea to browse through the examples in xith-tk.

Marvin

[ChrisE]

Thank you for your prompt reply!

So, I've been looking through the XIN manual (prior to posting, even--your docs are why I'm looking into this instead of Arbor3D or jME), and while I believe I see the reason you suggest using the scheduled operations, I think that I may have misrepresented my problem to you.

So, there is a great deal of external (to Xith) code that manipulates a data model that I have. Due to the size of that code, and the size of the code for the data model, adding dependencies on it to my Xith code probably isn't feasible. However, if I can access the scene graph of the Xith code safely from the external code, I'll be fine.

A simple version of my problem is this:

I have a data model of some objects--perhaps some planets in orbits--and am using Xith to render it. Simultaneously, I've got another thread manipulating the model, perhaps updating positions of the objects. Let us ignore the fact that this simple example is a prime candidate for a scheduled operation in Xith--the real model is a great deal more convoluted and can't be integrated in that fashion (trust me on this).

So, one design philosophy is to have the scheduled operation the data model in the render thread context. This won't work, because the update logic is (far) too convoluted (it involves a great deal of interfacing with Swing, AWT, our own data model, etc.). So, that's out.

So, another design philosophy is to have the scheduled operation acquire a lock on the model, extract the data it needs, and unlock it, thus preventing the data model update logic from trampling data Xith is trying to get at. When the update logic needs to update, it acquires a lock on the data model, and thus prevents trampling from Xith. Regrettably, this won't work, for two reasons: first, the data model and update logic aren't separated currently (nor are they likely to be in the future); second, Xith would effectively be polling the data model, and our data model is quite large, so this isn't feasible either.

So, yet another way of skinning this cat is to use scheduled operations to check a list of updates. This list is lockable, and only contains "update messages" from the data model/update logic. Thus, the scheduled operation can update the scene graph internal to Xith, and our existing code never has to know anything other than that it should notify some queue of messages that "object x at place y is now at place z with geometry {w}". This actually seems like a decent way of handling things.

Of course, if there was a locking mechanism on nodes that code external to Xith could get at, we could avoid coding the above mechanism.

Any thoughts?

EDIT: Perhaps the UserData member could be used to provide this mechanism?

[Marvin Fröhlich]

UserData is just an abritraty object, that you attach to scenegraph objects. So the answer to the last question is No.

The Xith3D scene graph isn't thread safe for performance reasons. So there can't be any way to lock parts of in in any way. Though you have read access to it's transformations at all times. Theoretically you also have read access to the vertex data, but you may never manipulate the buffers' positions, limits, etc. without handling thread safety.

I admit, that I don't know your code. So I cannot really tell, if there might be a way to use scheduled operations. But tbh. I don't believe you, that there is no way to do so. You would simply update your data model in your own thread(s). Any update would cause a scheduled operation with the update information to be created and pushed into the scenegraph's updater. Since you're using Swing, you probably don't care about garbare collection times anyway. So creating a new object every time (fire and forget) should be no problem. Hence the effort should be pretty low.

Creating the scheduled operations and pushing them into the updater could be done behind the scenes of an abstraction layer. So your data model doesn't need to know anything about xith3d.

Hope, this helps.

Marvin

[ChrisE]

Ah, okay, I think I see what you're saying. So, I'd add code to my model to inject a scheduled operation into the rendering thread, and have the injected code handle the geometry/scene graph updates? It hadn't clicked with me that you could add those operations external to Xith, hence my confusion.

Interesting. My only other question is manipulating the geometry--presumably I just replace the geometry on a Shape3D in the above-mentioned operation, as the geometry currently attached is read-only?

Thanks again for all the help; would be fun to trade notes on engine design some time, as I'm dealing with one over in C++ right now. Also, I noticed some passing similarities (probably just in nomenclature) between Xith and Java3D; any opinions as a developer on Sun's architecture there? I found it kind of obtuse, to be honest.

EDIT: As an aside, how would you go about handling thread-safety in a scene-graph? The obvious solution is to lock everything at and below a node in contention, but that hardly answers the question of keeping reasonable rendering output at decent frames.

[Marvin Fröhlich]

So, I'd add code to my model to inject a scheduled operation into the rendering thread, and have the injected code handle the geometry/scene graph updates?

Yes

Interesting. My only other question is manipulating the geometry--presumably I just replace the geometry on a Shape3D in the above-mentioned operation, as the geometry currently attached is read-only?

No. You can safely manipulate the Geometry from within the Xith rendering thread (-> not ro).

would be fun to trade notes on engine design some time, as I'm dealing with one over in C++ right now.

Sure. Any time.

Also, I noticed some passing similarities (probably just in nomenclature) between Xith and Java3D; any opinions as a developer on Sun's architecture there? I found it kind of obtuse, to be honest.

Initially Xith was very much influenced by Java3D. It was someting like an open source non-synchronized implementation of the Java3D API. Over time Xith3D has evolved and some ugly Java3D constructs have been removed. The API is much nicer now and easier to use. Xith is way faster than Java3D. Many great features have also been added.

I have never talked to a Sun developer about Xith3D explicitly. So I don't know, what they're thinking about it, if they have even noticed.

EDIT: As an aside, how would you go about handling thread-safety in a scene-graph? The obvious solution is to lock everything at and below a node in contention, but that hardly answers the question of keeping reasonable rendering output at decent frames.

How would you go about "locking"? This can't be any smarter than using Java's synchonizing approach. And the problem is, that any node, that is synchornized and the monitor is locked can't be rendered. The render thread even has o wait for this node to be processed. This can only be very bad for the performance.

Marvin

[ChrisE]

Ah, thanks. Cool.

Another question, then: What's the story about OpenMali and JAGaToo? Where do they fit in the development hierarchy of things?

[Marvin Fröhlich]

We needed a better Math library than Sun's vecmath, which was producing loads of garbage, which is very bad for realtime rendering systems. So we created a derivate based on Kenji Hiranabe's vecmath implementation. Soon the OpenMaLi codebase grew to what it is now.

JAGaToo contains a lot of code, that we externalized from the xith codebase to this project to provide the code for use in other similar open source projects. I personally wanted more cooperation especially with the JME guys. Unfortunately they refused to use it. Many parts of the JAGaToo code are newly developed for this project like the input classes. Others are made for my other projects and I pushed the code into this project, like the ini or XML reader/writer.

Marvin

[ChrisE]

Ah, alright, that makes sense. What problems did Sun's vecmath have? You said it created too much garbage while running... I'm assuming you mean in the sense of too many allocations?

How would you go about "locking"? This can't be any smarter than using Java's synchronizing approach. And the problem is, that any node, that is synchronized and the monitor is locked can't be rendered. The render thread even has o wait for this node to be processed. This can only be very bad for the performance.

An idea about scene graph locking: When a node is locked, clone it and edit the clone, while continuing to render the original. When node is unlocked, swap the clone for the real node (assignments in Java are atomic, right?). This way rendering is unaffected, and you don't have to worry about thread safety.

The naive implementation of this would copy everything below the locked node on the graph, but I think that you could get away with only copying things that are actually going to change. Along these lines, having a flag at construction time (bIsMutable or something) could allow preallocation of the clone, in effect creating a sort of double-buffered node that wouldn't be expensive to lock, if somewhat memory intensive.

I feel like I'm missing a piece of the puzzle, but that's one way of doing it.

[Marvin Fröhlich]

Ah, alright, that makes sense. What problems did Sun's vecmath have? You said it created too much garbage while running... I'm assuming you mean in the sense of too many allocations?

Exactly

An idea about scene graph locking: When a node is locked, clone it and edit the clone, while continuing to render the original. When node is unlocked, swap the clone for the real node (assignments in Java are atomic, right?). This way rendering is unaffected, and you don't have to worry about thread safety.

I expected this kind of idea . Clonig is certainly more expensive than going the ScheduledOperation way.

The naive implementation of this would copy everything below the locked node on the graph, but I think that you could get away with only copying things that are actually going to change. Along these lines, having a flag at construction time (bIsMutable or something) could allow preallocation of the clone, in effect creating a sort of double-buffered node that wouldn't be expensive to lock, if somewhat memory intensive.

Keeping a clong instance is certainly better performance wisely. But if you have a lot of very large geometries, this is inacceptable. And still even keeping the clone is more expensive. What if you only modify a part of the geometry? Then you would swap the two instances and next time you want to modify another part of the same geometry the last change is lost. Hence you would either have to remember the last modification or always update the whole thing, which would be contraproductive for the model apporach.

I am still convinced, that using ScheduledOperations is the most high performance way to go. And it really isn't that hard to do. It should be seamlessly integratable into your model code.

btw. bIsMutable is very old style. I never understood, why one had to prefix a variable with a type indicator nowadays. isMutable tells perfectly, that it is boolean . And it looks much nicer.

Marvin

[ChrisE]

Keeping a clong instance is certainly better performance wisely. But if you have a lot of very large geometries, this is inacceptable. And still even keeping the clone is more expensive. What if you only modify a part of the geometry? Then you would swap the two instances and next time you want to modify another part of the same geometry the last change is lost. Hence you would either have to remember the last modification or always update the whole thing, which would be contraproductive for the model apporach.

I am still convinced, that using ScheduledOperations is the most high performance way to go. And it really isn't that hard to do. It should be seamlessly integratable into your model code.

btw. bIsMutable is very old style. I never understood, why one had to prefix a variable with a type indicator nowadays. isMutable tells perfectly, that it is boolean . And it looks much nicer.

Marvin

Oh, I'm certainly going to try to use the ScheduledOperations method in my own code. The musing about a thread-safe scenegraph is just something I'm kicking around. When you've got several renderers, or a database being accessed by multiple clients, concurrency issues start to become interesting beyond what a render thread might be able to accomplish. Then again, the abstract idea of a central point of access that takes request objects and then manipulates the scene graph (something I'd mentioned before and something that, in effect, Xith3D allows with ScheduledOperations) safely is something I think is fun to think about.

As for nomenclature, I've never been to Hungary.

[Marvin Fröhlich]

As for nomenclature, I've never been to Hungary.

Why Hungary?

[ChrisE]

Hungarian notation: http://en.wikipedia.org/wiki/Hungarian_notation