next »

[Marvin Fröhlich]

As you may know, the default value of the pickable flag (of the Node class) is false. When the Xith3DEnvironment is used, the default is true. Xith3DEnvironemnt simply switches the global default in the constructor. This can lead to confusion, when Nodes are created before Xith3DEnvironment is created (e.g. in a static block).

I would like to set this default generally to true. Nothing else makes sense as a default, since the Nodes of interest are preselected by the group, which is passed to the pick method. The pick methods either take a VirtualUniverse, or a GroupNode or a List<GroupNode> (or nothing, which default to VirtualUniverse). So you can easily minimize the tested Nodes.

Is everybody ok with setting the default pickable property to true?

Marvin

[horati]

Updating the default makes a lot of sense.  We have definitely have means to reduces the traversed nodes.  This will allow us to program following the "make it work easily and optimize it after proving there is a problem."  Along those lines, what means do we have or can you easily add (maybe 1 or 2 trace statements)  to allow us to see picking metrics so that we might know we accidentally traversed too many nodes?

['n ddrylliog]

Along those lines, what means do we have or can you easily add (maybe 1 or 2 trace statements)  to allow us to see picking metrics so that we might know we accidentally traversed too many nodes?

That's hard to define how many is "too many". That's the problem of "mechanized" debugging...

[horati]

That's hard to define how many is "too many". That's the problem of "mechanized" debugging...

That's why I asked for a feature to provide counts or metrics of some kind to a human.  That way, we can inspect to discover what's taking the most time when we believe CPU is being consumed by picking code.

['n ddrylliog]

That's hard to define how many is "too many". That's the problem of "mechanized" debugging...

That's why I asked for a feature to provide counts or metrics of some kind to a human.  That way, we can inspect to discover what's taking the most time when we believe CPU is being consumed by picking code.

Yeah, I plan to implement that soon in Xith3D.

[Marvin Fröhlich]

That's why I asked for a feature to provide counts or metrics of some kind to a human.  That way, we can inspect to discover what's taking the most time when we believe CPU is being consumed by picking code.

I'm not sure, if I understand you right. But isn't this done by profiling tools like YourKit?

Marvin

[horati]

Never used YourKit.  Does it work well with X3D and does it give information that's easily useful?

For instance,

Code:

env.getCanvas().get3DPeer().getTriangles()

and

Code:

renderLoop.getIterationsCount()

both provide information that is directly usable for optimization purposes without a lot of fuss.  Similar utility would be:

Code:

public class DebuggingSingleton
{
    public static final boolean DEBUG = Boolean.getBoolean( DebuggingSingleton.class.getName() );
}

Code:

onRenderLoopStarted()
{
    node.getTriangleCount();
    node.getVertexCount();
    DebuggingSingleton.instance().monitor( node );
}
loopIteration()
{
    Map<String,Number> nodeInfo = DebuggingSingleton.instance.getInfo( node );
    this.maxBoundingSpheres = Math.max( nodeInfo.get( PickLibraryClass.BOUNDING_SPHERES_DEBUG_NAME ), this.maxBoundingSpheres );
    ...
    DebuggingSingleton.instance().resetInfo( node );
}
onRenderLoopStopped()
{
   print the results
}

This seems like a very easy, flexible way to add application-specific instrumentation to the library without incurring any penalties when it isn't used.  All the memory is stored inside the DebuggingSingleton and all the blocks of code scattered throughout the system with

Code:

if( DebuggingSingleton.DEBUG )
{
    perform an expensive diagnostic calculation
}

will get removed by the JVM because the static final boolean is false (one of the known JVM optimizations).

Methods that could be expensive would just need a Javadoc comment telling us that they are intended only for debug usage... or even an annotation   Examples that would fall into this category are: node.getTriangles() and node.getVertexCount() listed above.  These would be hideously expensive because they would have to traverse the graph to answer the question, but they ought to be pretty easy to write.  O(1) full graph traversal only when I'm debugging is fine as long as I understand what will happen if I read the Javadoc.  Those who don't read the docs or ask questions get what they deserve

[Marvin Fröhlich]

Cool ideas about the triangles- and vertex count. I will implement that. But it is certainly not done in O(1) when invoked on a group, but in something like O(log n), if the graph was balanced, which it is not in most cases. So it is actually something between O(log n) and O(n).

YourKit doesn't give you information ala getTrianglesCount(). It gives you information about the what are the most expensive parts in your coding or where is the most GC produced. And much more. Sometimes the user interface is a bit strange. But it is a very cool tool.

Marvin

[horati]

My O(1) was referring to invocation count of the top-level call, not the internal count.  My O(1) isn't nearly as expensive as O(f) where f is a frame resulting in O( [ f log n, f n ] )    No matter how hideous the call is, I'm only calling it once and only when I'm debugging.

Ah, I see.  YK is a pretty standard profiler then.  For those most part, I think library users shouldn't have to deal with that level of detail unless they want to.  I'm a big believer in optimizing the really big stuff and letting compute power handle the rest.

For instance, the MultiCubeBenchmark convinced me I had to use fewer spheres because they involve so many triangles.  That alone produced a huge FPS boost for me so other than not doing completely stupid stuff I won't worry about performance until the next problem arises

I've never actually created a problem where I had to use a memory profiler to fix it.  I guess I'm careful that way.  My hard line regarding optimizing only that which absolutely needs it usually means I can get away with the profiler built into the JVM LOL

[Marvin Fröhlich]

Now I understand you.

YourKit is more sensible for us API programmers. The users are more interested in information provided by such getXXXCount methods. But we can tune the API itself by using a tool like YourKit.

Marvin

['n ddrylliog]

Now I understand you.

YourKit is more sensible for us API programmers. The users are more interested in information provided by such getXXXCount methods. But we can tune the API itself by using a tool like YourKit.

Marvin

Absolutely.

I think the debug tools I want to implement will be based upon the Scenegraph Tree. There will be probably several views, with one reporting the biggest objects (in polygon count)..

Also, why not make a detector of shapes which could be static (=using display lists) and aren't yet ? That'd be useful (otherwise users, would just go and say "wow, Xith3D is just shitty, I don't even get 500FPS ).

Some "contextual development tips", to sum it up.