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

[Richard Puk]

Hi, Alan --

Perhaps you can have your cake and eat it too. Why not provide a run-time
switch that either enables the saving of DEF names or disables it?

  -- Dick

/*****************************************
* Richard F. Puk, Ph.D.
* President, Intelligraphics Incorporated
* 7644 Cortina Court
* Carlsbad, CA  92009
* Tel:  1-760-753-9027 E-Mail: puk at igraphics.com
\*****************************************




> -----Original Message-----
> From: source-bounces at web3d.org [mailto:source-bounces at web3d.org] On
> Behalf Of Alan Hudson
> Sent: Tuesday, August 21, 2012 5:38 PM
> To: Don Brutzman
> Cc: source at web3d.org
> Subject: Re: [Source] Extrusion diagnostics improved; how to get the DEF
name
> of a node?
> 
> 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
> 
> 
> _______________________________________________
> Source mailing list
> Source at web3d.org
> http://web3d.org/mailman/listinfo/source_web3d.org