There's a lot of talk here, but the main problem is: why do you need 2000 bg ? Do you really, really need to attach/detach every one of the bg's individually ? Is there absolutely no way you can reduce the complexity of the scenegraph ? For example, 10 bg with 10 tg operating on shape3d's *each* containing 20 geometries ? That's roughly similar to 2000 bg each having 1 tg with 1 shape3d with 1 geometry. The difference is that the first case is much, much easier to handle by j3d then the second one, and the overall performance of the system will be greatly improved.
If you can do nothing to simplify the scenegraph, then the use of the switch is mandatory. Using LOD objects are no improvements, because they operates on switches. So let's detail a little the way I see the use of switches. BTW, if you really want to go along the j3d design pattern, you can encapsulate your whole switch logic into a behavior extending LOD. 1. First problem, too many bg's. You should consider using a group of switches, not only one switch. Do NOT use 1 switch per every BG, instead try to group several bg's. For example, you need 3 bits per bg, so think of grouping 32 bg's per switch, that will make a mask of 12 bytes per switch, and you will need 63 - 64 switches. 2. The attach / detach time increases with the complexity of the scene. Since you are already using a progressive refinement, I don't see why are you so bothered by the time needed by the switch to add ??? Because you *first* add the new structure, then enable it while disabling the old one. That way, you shouldn't see any glitch on the screen, only that suddenly, one of you objects is more refined. You can refine your scenegraph incrementaly, I mean do not refine the whole scenegraph at once, but refine each bg individually: i) get new bg; ii) add new bg to switch; iii) change switch mask; iv) detach old bg. You should see the refinement spreading on your scenegraph, same as when you load a big interlaced gif over a slow internet connection. 3. You shouldn't care about the number of j3d threads, they are really not many, and in most of the cases, they are only sleeping. The j3d threads are: 3 main threads (MasterControl, RenderingAttributesStructureUpdateThread and TimerThread) and another 10 threads for every canvas3d you are creating (Renderer, BehaviorStructureUpdateThread, GeometryStructureUpdateThread, etc...). For an application using 1 canvas embeded into 1 swing framework, I have a total of 25 threads. That's not really much, considering that my W2K is reporting 265 running threads on my system, of which 200 I don't know from where they come. 4. You really need to know the rendering time. If the renderer is consuming all the cpu because of a too complex scenegraph, there's no wonder why it takes so much time to change the scenegraph. You can use one of the framerate counters available on the internet. They give you quite good figures of the performance of your system. I have attached the one I'm using. You are free to do what ever you want with it. 5. Don't forget that the whole j3d is based on a message driven architecture. Even when you are using the so-called pure immediate mode, it's not like directly drawing to the graphic card. Each operation you are doing on the canvas in pure-immediate mode is in fact encapsulated into one message object which is passed to the MasterControl which in turn decides what to do with it. That's why pure-immediate mode is so much slower compared to the scenegraph based drawing. 6. Stopping the renderer thread really stops all the relevant threads, but don't forget that it is stopping *only* after it finishes the current work. If your scene graph needs 6 sec to draw, then the call to stop the renderer may need up to 6 seconds to complete! Cheers, Florin -----Ursprüngliche Nachricht----- Von: Anirban Bhadore [mailto:[EMAIL PROTECTED]] Gesendet: Dienstag, 11. Februar 2003 08:12 An: [EMAIL PROTECTED] Betreff: Re: [JAVA3D] AW: [JAVA3D] Performance problem with live scenegraph > 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? ============================================================================ I tried immediate mode rendering. Could not get any better result from it, following is the results. operation ~ time for scenegraph editing(sec) ~ time for drawing in immediate mode(sec) addition of 2000 bgs Tadd = 1.6 ,Tdetach=2.6, Ttotal=10.0 Tdraw = 8.9, Ttotal =14.2 with cubes, then addition of 2000 bgs with spheres detaching the old bgs The times given above are cumulative times for the method calls. Do you think the draw time in the immediate mode is quite high? What I have done is I have created a Canvas3D, a SimpleUniverse, added the Canvas to the Universe, and before adding the Canvas to its container, I have stopped the renderer, am I missing something here. The time it takes to draw seems to be quite hish and I am not very sure whether stopRenderer() call "stops all the thread associated with Rendering process" or just stops the renderer thread which is just one of them ! In scenegraph editing mode I tried to collect the bgs in groups of 10, 100 & 1000 and doing the addtion. But it did minor changes in the times and did not really give a benifit(varied from 9 sec to 9.4 secs). Also I had stopped and started the renderer while doing this addition and detaching. I need progressive refinement for my application for sure. And the problem is not just the rendering time. In fact I could not even find a reliable and good method to find the rendering time that java3d is taking other than just a feel( is there any way??). Along with renderer thread the other threads are running( 7-8 of them for behavior scheduling, user input handling etc etc) and they are making the other method calls slower, so the effect is cumulative and not just on a single method or area where we can fix something. ............
FPSCounter.java
Description: Binary data
