> Date: Mon, 10 Feb 2003 15:59:43 +0530 > From: Anirban Bhadore <[EMAIL PROTECTED]> > > "I need to update 3 times" - this means in the life time of the scene. > Initially while creating the scene I have some coarser geometries, which I > want to load and show because that helps me in showing the first scene > quickly. After that I refine these geometry nodes around three times adding > more refined forms at each step. And in the last round I add the final > geometries which I dont edit till the lifetime of the scene.
This sort of progressive refinement scheme can be very effective with immediate mode rendering API's when facing bottlenecks in the actual rendering speed. It's less effective with scene graphs, depending upon their complexity, because the structure update time can be significant compared with the time it takes to render; you can move the bottleneck from rendering speed to CPU speed and internal data bandwith and memory constraints. Are you sure you need progressive refinement while loading your data? Are you hitting a bottleneck in actual rendering performance? What you're doing is very similar to what the abstract LOD (Level Of Detail) Behavior can do. It's only concrete implementation in the Java 3D core is DistanceLOD, which switches between refinement levels based on distance from the viewer. You might try extending LOD to switch levels based on maximum time to render -- slow, medium, or fast. This would be helpful for speeding up local scene graph manipulations, but maybe not for rendering while loading from your RMI server. > above two are experiments that I had done with HelloUniverse demo > j3d1.2.1_03 and jre1.3.1_03 versions. > > In my application I have 2000 BGs each of them has a bg, a tg and a shape > with Geometry (varies in size). In this case the total addChild() time is > 1.5 minutes and total detach time is 2.5 minutes. That's a lot of BranchGroups. You seem to be encapsulating your scene graph structure at a very low level. A BG and a TG for each shape is a huge amount of overhead. Are you batching your addChild() calls to the live scene graph or calling them individually for each BranchGroup? You might find it faster to build a complete scene graph for each level of refinement and then replace the current one with the new one using a single detach() and addBranchGraph(). > Moreover, while doing this, it makes the application thread( main thread) > slower, so the data pushing thread (fetches data from a remote rmi server and > adds the data to live scenegraph) also takes around 60% more time than it > takes if we dont pop the data into the scenegraph. What is happening is when > we call addChild() and detach() one after another continuously, the whole > application becomes slower and most probably the data pushing threads dont > get CPU attention properly. I even tried to reduce the thread priority of all > java3d rendering threads by using VirtualUniverse.setJ3dThreadPriority() call > which seems to be ignored totally ! Your analysis makes sense. I don't know why the thread priority call has no effect; Java 3D just calls Thread.setPriority() on each thread in the J3D group. There may be an OS issue here -- some flavors of Windows or Linux may not be handling multi-threading priorities well. > question : does application writers have any control on the java3d threads? > I mean can I control the rendering thread by saying that I want to edit the > scenegraph but you dont need to update the view till the time I tell you to > do it explicitly. There's not a lot of explicit control. The stopRenderer() and startRenderer() methods of Canvas3D were designed for immediate mode, but you've already given that a try. Have you tried using these methods with the scene graph? -- Mark Hood =========================================================================== To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message "signoff JAVA3D-INTEREST". For general help, send email to [EMAIL PROTECTED] and include in the body of the message "help".
