[Source] Extrusion diagnostics improved; how to get the DEF name of a node?

[Alan Hudson]

On 8/20/2012 10:17 PM, Don Brutzman wrote:
> On 8/20/2012 9:46 PM, Alan Hudson wrote:
>> On 8/20/2012 12:43 PM, Don Brutzman wrote:
>>> [..]
>>> What should be an FAQ: how to get the DEF name of a node?
>>> It doesn't appear that this important value is saved as part of
>>> a node's base class information.  Not having it greatly obscures
>>> diagnostic and error output.
>>>
>>> Example reference or snippet to getDEF from within OGLExtrusion
>>> would be appreciated.
>> You can't.  The information is only contained at the scene level not per node.  We decided the memory overhead of having an pointer per node was not worth it.
> I'm afraid that approach is simply insufficient for proper testing.
> We must be able to test and diagnose Xj3D with nontrivial X3D content.
> You can't just guess which node (among dozens or hundreds) causes an
> Xj3D error when debugging unit-test content.
>
> Minimum approach:  utility method that somehow looks up DEF name from
> a table or hashmap, if you are already keeping it there.  (Presumably
> DEF info is kept somewhere, otherwise you can't add a ROUTE at runtime.)
feel free to add this its the scene that will have the information you want.
> Simple, typical approach:  add DEF string to base class for all nodes.
> Provide get/set accessor methods similar to other fields.
We don't want this approach as it wastes memory and implies def names 
are changeable which they aren't.
> Optimization decision guidance:
> a. Necessary functionality first.
> b. Use monitoring and metrics (e.g. Netbeans profiler or other tools) to
> 	make tradeoff decisions about performance and memory footprint.
> c.  Performance metrics may differ depending on end-use case (e.g. X3D
> 	profile support, desktop/mobile/embedded application/JNLP/etc.)
>
> Did I miss anything?  Articulating best practice would seem to be valuable
> to capture in the Xj3D developer documentation.
or multiply the numbers of nodes in a scene times the pointer length and 
decide that using that much memory is a problem.  In the cad space we've 
seen node graphs in the millions of nodes
> BTW another thumbrule:  developer time is more valuable that computer time!
>
> It is quite a picture puzzle debugging the Extrusion anomalies, as you
> might expect from the scene and console outputs provided.  The current
> text console output (after manually removing "System.out: " distractors)
> is 1724 lines long for 10 Extrusion nodes.  Not having a positive DEF indication
> of which node is which consumes further developer time for each trace attempt.
I don't disagree that having node name access would be helpful for 
debugging.  But the primary design guidance of the graph has been 
rendering performance.  Java already has a reputation of being a 
resource hog.  Adding more per-node fields is a way to make that 
reputation true.

-- 
Alan Hudson, Director 3D Tools
www.shapeways.com