Hi there,
I am developing a vizualization system with Xith and I have a couple of questions about Xith…
Is there a way to implement LOD based culling in Xith ?
What are the culling mechanisms currently implemented in Xith?
What could be the implications of thread unsafe scenegraph, potential problems versus performance benefits?
Hi,
[quote]Is there a way to implement LOD based culling in Xith ?
[/quote]
If you speak about Java3D-style LOD, this is not implemented yet in Xith3D, but architecture of the engine designed to support it.
In Xith3D, you have direct access to Local-to-Vworld transforms, as well as to Vworld bounds of every object, so you can try to play with manipulating switch nodes (this is what LOD in Java3D does for you) in order to turn ON/OFF desired LOD level.
[quote]What are the culling mechanisms currently implemented in Xith?
[/quote]
Frustum culling is build in.
BSP culling can be implemented by application code (there is an example of Quake level renderer by David Yazel somewhere on this forum).
There is a plan to support occlusion queries/occlusion testing, but it has not beed implemented yet.
[quote]What could be the implications of thread unsafe scenegraph, potential problems versus performance benefits?
[/quote]
In thread-unsafe scenegraph when you have your scenegraph updating thread running in parallel with rendering thread, it is possible that you change some object properties in the middle of scene rendering, and may potentially get visible side-effect artifacts (inconsistent rendering, object jittering, etc.).
In thread safe graphs, all scene updates typically posted to rendering thread via queue or event-style mechanism, and rendering thread applies them only between frames rendered. This saves from inconsistent rendering, but does not help with object jittering and some other rendering artifacts.
Thread synchronization is very expensive (time-consuming) operation (especially in Java). In truely thread-safe scenegraph engines, every fragment of code that modifies scenegraph should be synchronized, which results in multiple monitorenter/monitorexit JVM instructions executed in addition to scenegraph modification code. Additionally, JVM truns off some code optimizations for synchronized methods and methods that contain synchronized statements. These things make thread-safe code noticeably slower that non-thread-safe. You can try to make your own microbenchmark with synchronized method access and non-synchronized one, or search performance-related forums here at java-gaming.org for some results measured by other people.
In thread unsafe scenegraphs (for example, Xith3D) the good practice is that your application has own application-specific modification synchronization mechanism (one global synchronization statement, event queue, change atomization mechanism, etc.). The easiest way to avoid ALL the thread safety problems in Xith3D is to put all your scenegraph modification code inside
synchronized (view) {
// modify scenegraph here
...
}
statement, beause of all thre rendering happens in synchronized View.renderOnce(…) method, so you are 100% sure that whenever you modify your scenegraph, there is no frame rendering in progress.
This is not the most efficient solution, and if you want to minimise pauses between rendering consecutive frames, you have to implement more sophisticated sync mechanism (change queue, for example), but at the end you apply changes again inside synchronized (view) statement.
Yuri
Thanks