-------- Original Message -------- Subject: Re: [java3d] Shape3D nodes won't compile() Date: Tue, 15 Jun 1999 17:31:43 -0400 From: Shawn Kendall <[EMAIL PROTECTED]> To: Doug Gehringer <[EMAIL PROTECTED]> CC: [EMAIL PROTECTED] References: <[EMAIL PROTECTED]> First off, thank you the sample code and help with my previoues problem with compile. I have gotten my "stuff" to compile fine. However.... I believe there is a serious problem with the design of how you use compile. >From the API, docs, messages etc. compile() is meant to optimize the scene graph for rendering. Two examples of those optimizations are combining Shape3Ds that could share vertices ( tri-stripping ) based on the attributes ( lighting mode, texturing etc ) and sharing attributes that could be shared ( Appearances for example ). The fact that Java3D comes with support this is terrific. It saves me from having to write an optimizer for my data myself. The problem is that once the optimizations are completed, the user can not access the new Shape3Ds. At least I can't find a way. Once a tree is compiled, if you try to access any info that was declared by capability bits before the compile you are locked out and all you get is access errors. I can sort of understand the thinking behind this but I need to get access to the new Shape3Ds that are generated after a compile(). Is there any way to do this? Will I be stuck writting my on optimization methods that replicate compile without restricting access to the nodes? Thanks you any help. Doug Gehringer wrote: > > From: Shawn Kendall <[EMAIL PROTECTED]> > > > > I can't seem to get my scene to compile() correctly. > > I get no errors when I compile but when I check the isCompiled() state > > of my Shape3D's it return false. > > > > Also, I can't tell from my scene graph that nothing has been done and > > there are several Shape3D's that could be combined in my test model. > > What am I missing? > > It is very difficult to confirm that your scene graph has acually been speeded > up by compile(). If you compile() a scene graph and then a child of that graph > returns false for isCompiled(), then you have probably found a bug. > > Remember that if your scene has a Link, compile() won't follow the link to the > SharedGroup, instead you need to compile() the SharedGroup separately. > > The current implementation of compile() will speed up only certain kinds of > scene graphs, and only if you override the default settings on the Shape3Ds. > Here are the details: > > compile() implements two optimizations to the scene graph: attribute sorting and > shape merging. Attribute sorting looks at the attributes on the Shape3Ds and > builds a list of unique appearances. It then replaces the redundant appearances > with references to the unique appearances. This minimizes the overhead to > changing appearances as the scene graph is displayed. Shape merging groups > primitives which share the same appearances and then merges the shapes which are > compatible into larger shape nodes. > > Using compile() can make some scene graphs run 4x (or more) faster. To benefit > from compile() you scene must have lots of Shape3Ds which have the same > attributes and transforms, the Shape3Ds can't use indexed geometry, or have any > capability bits set on their appearances or have the "pickablity" flag set > (pickablity is set by default, so you have to reset it to enable compilation). > The compile optimizations will sort and merge the static subgraphs of your > scene, so if you have writable nodes at the "top" of your scene graph, the > "static" children of the writable nodes will be optimized, but the optimization > won't encompass the dynamic parts of the scene (all of the nodes in the compiled > subgraph will still have the isCompiled() flag set) > > If it sounds like it is hard to make compile() speed up your scene graph, you're > right. At present, the only scene graphs which we find are consistently helped > by compile() are parts derived from MCAD data, where there are lots of small > chunks of geometry which can be combined. > > Java3D 1.2 will do a better job of optimizing the data with or without using > compile(). > > Attached below is a test program which shows some good results using compile(). > It groups a large set of Shape3Ds into blocks, compile() will then turn all the > shapes in each block into a single Shape3D. The application takes the following > arguments on the command line: > > -nocompile Don't compile the scene graph > -pickEnable Don't clear the pickEnable flag (also disables compile) > -cubeSize <size> Set the number of Shape3Ds (size ^^ 3), default 16 > -blockSize <size> Sets the number of Shape3Ds per "block", default 16 > -primType <0|1> Sets the primtive type 0=tetrahedron, 1=icosahedron > > For example "java CompileTest -cubeSize 5 -blockSize 10" will create a scene > graph with 5 ^^ 3 (125) tetrahedrons, blocked into groups of 10. > > Note that this is a very artificial test, so it will produce better speedups > than real world applications. Also, depending the graphics hardware you are > using, it may produce little or no speedup at all. For accurate numbers, let > the test run until it produces consistent speeds. > > I've attached some sample results from a Sun Ultra 2 / Elite3D for comparison. > > Doug Gehringer > Sun Microsystems >
