Bug 1102 - No warning/default if glist box does not have upper and lower extent tags
Summary: No warning/default if glist box does not have upper and lower extent tags
Status: ASSIGNED
Alias: None
Product: DIRSIG4
Classification: Unclassified
Component: Geometry (show other bugs)
Version: 4.5.4-release
Hardware: Macintosh Intel MacOS 10.8
: P5 normal
Assignee: Scott D. Brown
URL:
Depends on:
Blocks:
 
Reported: 2014-06-04 15:36 EDT by Paul Romanczyk
Modified: 2014-06-12 11:26 EDT (History)
1 user (show)

See Also:


Attachments
a glist file with a bad box primitive (3.08 KB, application/octet-stream)
2014-06-04 15:36 EDT, Paul Romanczyk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Romanczyk 2014-06-04 15:36:47 EDT
Created attachment 340 [details]
a glist file with a bad box primitive

In a glist file, if you do not have the appropriate tags ("upperextent" and "lowerextent") on a box primitive, neither a warning is given nor a base box built. I would expect either a warning, an error, or a default box to be built (perhaps +/- 0.5 m in each dimension) if these tags are not present.

I was working on an odb to glist converter and had the xml tag as "upper_extent" and "lower_extent". When running on the converted file from the PrimativeObjects1 demo, there was no base box built (other primitives seem to have a default size, e.g., the default cylinder is vertically aligned (along the z-axis) from z = -0.5 to z = +0.5 and has a radius of 1). 

This bug occurred in dirsig 4.5.4 (r13673). To reproduce run the PrimativeObjects1 demo while using bad.glist (attached) instead of primitives.odb.
Comment 1 Scott D. Brown 2014-06-12 11:09:31 EDT
Adam (or maybe it was Niek that wrote it) has most of the primitive geometry parsing setup in GLIST files to have a default value. So in the case of a <box>, there are apparently default extents that make a box centered about 0,0,0 with a size of 1,1,1.  These defaults appear for most of the primitives (for example, a default sphere is centered at 0,0,0 and has a radius of 1.0).

So we have two (at least) options:
1. Leave it the way it is, but document these defaults.
2. Remove the defaults and force the user to specify everything.

Discuss ...
Comment 2 Paul Romanczyk 2014-06-12 11:26:32 EDT
I re-ran the simulation that was "broken", but commented out the sphere centered 8m above the origin. The box was really there, just hidden under the sphere. This really wasn't a bug, just a hidden box under/in the sphere. I should have looked closer to see if there was something at the origin.

I think leave the code as-is. There is less work for this option since most (if not all) of the defaults are in documentation already.