Menu
▾
▴
#233 Rt (and Rtedge) Clips Image
closed-invalid
8
2010-04-20
2009-11-16
No
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.
database to illustrate the bug.
The file 'xpart.g' was successfully added.
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?
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
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.
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).
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.
Upon further investigation, I notice that rt and rtedge have much different option lists--but the fundamental difference between the two is that the output is either a shaded drawing for rt or a hidden line drawing for the other. Both menus should be almost identical (I like rt's better--it's closer to lgt and allows for user input of az/el), and may be achieved through a single source file with the common trick of basing behavior on what name is used for execution.
A couple of more points:
Both rt and rtedge need an option like '--force' to enable overwriting any existing output file if desired.
Executing rtedge without an argument show that the output may be redirected to a file--I can't get that to work.
Sean, I see I'm out of synch with your comments--sorry (that's why I like e-mail threads better).
Regarding lgt: we started using rtedge several years ago when lgt started putting out the message that it is deprecated and interrupted our scripting and hidden line drawing process. I, like a good scout, got rtedge to work most of the time until we started having the clipping problems. The easiest way to solve MY problem may be to either (1) un-deprecate lgt or (2) add an option to it (say, '--batch') to stop the message from interrupting scripting.
Regarding your understanding of my problem and requirements: I think they are right on the button. And later changes to fine tune the view to better accommodate long objects from end on would be great.
I found this message from 2006 that describes my initial problem and lack of understanding of rtedge:
https://sourceforge.net/mailarchive/message.php?msg_id=E1FoRJr-0002Cm-03%40sc8-sf-web2.sourceforge.net
I also see (and remember now) that rtedge does have the -a and -e options but no mention of autosizing in the help. At any rate it didn't work in my initial investigation (and I admit I did not have much time then to do a whole lot of research).
I've annotated the force option as a feature request. I've also documented the rtedge bug redirecting to a file as well. You can work around that issue with the -Ffilename.pix option or -o filename.pix option. Do those also not work for you?
Considering lgt deprecated is a good thing and your efforts are certainly very much appreciated. The tool makes a lot of things accessible in a powerful/simple fashion, but did so at a relatively high maintenance cost as well. It's not very well written, has many bugs, is time-consuming to maintain, and all of it's features are provided by other tools in more powerful (albeit different) ways. I feel your pain though and I want to address every single one of the issues you've raised.
You mentioned rtedge not mentioning autosizing in the help. What would you want it to say? The intent is more that it's an intuitive default that shouldn't need explaining. Adding new options that modify from the default would certainly warrant explanation.
I think one of the points of confusion here is that calling the "saveview" command in mged creates a view script that *overrides* the viewing parameters for any of the rt* tracers as the view is specified in the script. That view overrides the default view that rt/rtedge would otherwise use by default. To get the default "centroid" view that is documented, you wouldn't specify the view parameters that were automatically included in the saveview script.
Sean: "You can work around that issue with the -Ffilename.pix option or -o filename.pix option. Do those
also not work for you?"
Yes, I've used the '-o' option successfully.
Sean: "You mentioned rtedge not mentioning autosizing in the help. What would
you want it to say?"
My main point is that I believe rt and rtedge should have identical descriptions for identical options (same for man pages and user feedback) if my assumption is correct that both are almost the same except for hidden-line versus shaded output.
If they are almost the same, merging the sources and changing behavior by executable name might help that situation.
Agreed regarding the descriptions needing to be more in sync.
All of the rt* ray trace tools have nearly identical options and already share common code for the bulk of their functionality including option processing for common options, grid setup, parallel processing, and more. Each tracer is basically one view*.c file in src/rt with the logic and code specific to that tracer.
I think the bigger problem is that there isn't shared documentation even though the options are 95% the same. Each tracer has a core set and can add additional options specific to that raytracer. I've put in another to-do item to consider trying to refactor out common documentation as well.