[brlcad-tracker] [ brlcad-Bugs-2898655 ] Rt (and Rtedge) Clips Image

[SourceForge.net <no...@so...>]

Bugs item #2898655, was opened at 2009-11-16 19:49
Message generated for change (Comment added) made by brlcad
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=640802&aid=2898655&group_id=105292

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Raytrace
Group: unexpected behavior
Status: Open
Resolution: Invalid
Priority: 8
Private: No
Submitted By: Tom Browder (tbrowder2)
Assigned to: Keith Bowman (indianlarry)
Summary: Rt (and Rtedge) Clips Image 

Initial Comment:
This problem is identical to bug ID 1525332 and has resurface.  I added a comment to that bug and tried to attach xpart.g but could not.  The problem:

When I programmatically use rtedge, the object is not filling the view so I get very few pixels compared to doing rtedge in mged. I've attached xpart.g. Try rtedge on object "curved" inside and outside mged to observe the difference.  See that rtedge works when called from inside mged but not as an executable.


----------------------------------------------------------------------

>Comment By: Sean Morrison (brlcad)
Date: 2010-04-15 13:22

Message:
lgt taken away?  We still build and install lgt...

As to the ideal workflow, to be clear we're covering everything, you
mentioned:
1) a picture generator
OK: rt/rtedge
2) specifying objects
OK: listed on cmd line after db name
3) want to specify az/el in degrees
OK: -a ## -e ##
4) the number of pixels
OK: -s ####
5) center on center bb of objects
OK: default view
6) all objects in view
OK: default view
7) minimum padding on most restrictive dimension
FAIL

Right now, the amount of padding depends heavily on the boolean operations
being performed and the shapes of their component bounding boxes.  The
default view is guaranteed to capture the entire object(s) specified, but
may be up to 2x too much depending on orientation.  Before delving into
what we might do about that, though, I still want to make sure 1-6 are okay
and that there aren't other issues.  LGT of course provides a LOT more
configurability than 1-6.  RT does as well, but it does it through a script
interface fed to it via standard input.


----------------------------------------------------------------------

Comment By: Tom Browder (tbrowder2)
Date: 2010-04-15 13:02

Message:
After looking at my process, what I would like to have rtedge (and rt) do
is to have the same kinds of inputs lgt used to have to enable the user to
configure the viewing parameters "easily."  As you stated, the problem I'm
having is getting the viewing parameters correct, and lgt was a known beast
that worked fine until it was taken away.

Ideally I want to have a picture (hidden line or shaded) of a group of one
or more objects by specifying the viewing az/el in degrees and the number
of pixels and know that the center of the resulting pix would be the center
of the bounding box of the objects, and all objects would be in the view
with minimum padding on the most restrictive dimension (view x or y).

----------------------------------------------------------------------

Comment By: Sean Morrison (brlcad)
Date: 2010-04-15 02:14

Message:
Well you can always render a bigger image and get a detailed rtedge at any
size you desire but you'd need to crop the image to the portion of
interest.  I suspect the process and subsequent problem is reversed though.
 If I run rt on "curved" outside of mged, I get a nice detailed object
filling the view.  That same object inside of mged has a big subtraction
that makes rt from inside of mged result in a really tiny object relative
to the view size.

If you're running rt/rtedge outside of mged and providing it a view script
with the -M option, then the easy solution is to change or remove the view
script.  Anything else will probably require a mod -- which should be
really trivial -- so we need to figure out what that change you need is. 

----------------------------------------------------------------------

Comment By: Tom Browder (tbrowder2)
Date: 2010-04-14 21:17

Message:
Sean, let me revisit the process I use to get the inputs so I can maybe
relate better to your explanation.  Would playing with the -V option (view
aspect ratio)  or -w and -n options help the situation?

-Tom

----------------------------------------------------------------------

Comment By: Sean Morrison (brlcad)
Date: 2010-04-14 20:34

Message:
Thanks for the sample geometry!  From what I've seen, this is different
behavior altogether from what was going on in bug 1525332.  Here, the
difference is actually intentional behavior (albeit undesirable and
unexpected to you).

The difference comes from how MGED and RT use different methods to
calculate a display volume.  MGED looks at the size of your graphics window
and sets the view on the center of the object with a view size that
encompasses 2x the bounding box of all objects.  That makes sure that the
entire wireframe is neatly centered regardless of orientation.

RT, on the other hand, looks at the bounding box of all union and
intersection objects, sets the view center on that bounding box, and makes
the view size big enough plus a little padding.  That is because there is
no wireframe to display, no missing information.

There are a couple workarounds that you can use to get them to match now. 
You can reduce the size of the arb8 being subtracted to the smallest size
necessary.  Alternatively , if you set a view in MGED you want and then run
'saveview', that will write out a script that will raytrace that exact view
outside of MGED as a shell script.  That text file can be modified and
reloaded with the MGED 'loadview' command too.

To get the view that RT uses is a bit more tricky and probably will
involve a feature request to make better.  We could enhance MGED's autoview
command with an option to replicate that view, we could add view size and
positioning parameters to the various ray tracers as command line options,
we could make rtedge match rt view initialization if they're different,
etc.  What sounds most useful to you? 

----------------------------------------------------------------------

Comment By: Tom Browder (tbrowder2)
Date: 2010-04-09 19:13

Message:
The file 'xpart.g' was successfully added.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=640802&aid=2898655&group_id=105292