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

[Don Brutzman]

On 8/21/2012 5:38 PM, Alan Hudson wrote:
> 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.

Prove it with testing.  Anything else is conjecture.

BTW am not sure why "must minimize memory" is such a constraint when this
player is so much bigger than the others.

>> 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.

Functionality first please, we must be able to debug this codebase
by testing it with X3D scenes.

As far as performance goes, I will be among the first to believe
when tests show a result.  Other than that is opinion, which sometimes
can be incorrect.

all the best, Don
-- 
Don Brutzman  Naval Postgraduate School, Code USW/Br       brutzman at nps.edu
Watkins 270,  MOVES Institute, Monterey CA 93943-5000 USA   +1.831.656.2149
X3D graphics, virtual worlds, navy robotics http://faculty.nps.edu/brutzman