> 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. > 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. ============================================================================ == I dont really have a performance problem with the RMI call, as it performs to my satisfaction when I just pull the data from the rmi server without poping it into the scenegraph. "Its only when I have perf problem when I add/detach data into the live scenegraph". What I understand from the DistanceLod example is you have all the lods ready even before your scene graph is live, so you are not editing the data structure of the scenegraph in true sense. Actually I have also found that the bit masking does not time at all, its pretty fast, so this example is not goiung to work in my case. Do you agree? Let me know if you think my assumptions are wrong. Another very interesting observation which you will appreciate is that the time taken for adding a bg node into the Switch is much much heigher than the time taken for adding and detaching a bg into a live bg ! I found this quite strange and trying to understand why this happens as Switch class does not have any over-ridden implementation of the addChild() method and simply uses addChild() of Group.class. Infact the time relationship goes as shown below TaddNewbgtoALivebg + TdetachOldbgFromLivebg < TaddNewbgtoALiveSwitch For 2000 bg test case that we are discussing( adding 2000 bgs with cubes and then adding 2000 bgs with Spheres and detaching the cubes) - TaddNewbgtoALivebg = 1.5 sec TdetachOldbgFromLivebg = 2.8 sec Ttotal = 4.3 sec TaddNewbgtoALiveSwitch = 4.4 sec I am totally lost here !! > 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. ============================================================================ ========= yeah, it sounds like. But we need to do this because of a singular fact that j3d allows only bgs to be added to live scenegraph. So, in that case, if we have to maintain the granularity, we dont have any option open. One possible option may be to just update the geometry and not editing the scene graph, but that did not help. But I am yet to try on BY_REF option, that I will try next. > > 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(). > ============================================================================ =========== Yeah. individually on each bg. I tried to collect the bgs in groups of 10, 100 & 1000 and the results are not impressive, I have already given the results on the top of the mail. > > 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. ============================================================================ ============= Yes, I also concluded like this. But is there any platform where I can really see the time benifit for this? Solaris? > > > 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? ============================================================================ ================ yes, I have even tried start/stopRenderer() methods in scenegraph, as I have described above. Thanks for being patient & reading the long mail, now please go on and suggest me someything !!!! thanks Anir > > -- 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". =========================================================================== 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".
