Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#233 Rt (and Rtedge) Clips Image

unexpected behavior
closed-invalid
Keith Bowman
Raytrace (49)
8
2010-04-20
2009-11-16
Tom Browder
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.

Discussion

<< < 1 2 3 > >> (Page 2 of 3)
  • Tom Browder
    Tom Browder
    2010-04-15

    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.

     
  • Tom Browder
    Tom Browder
    2010-04-15

    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.

     
  • Tom Browder
    Tom Browder
    2010-04-15

    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.

     
  • Tom Browder
    Tom Browder
    2010-04-15

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

     
  • Sean Morrison
    Sean Morrison
    2010-04-19

    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.

     
  • Sean Morrison
    Sean Morrison
    2010-04-19

    • status: open-invalid --> pending-invalid
     
  • Sean Morrison
    Sean Morrison
    2010-04-19

    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.

     
  • Tom Browder
    Tom Browder
    2010-04-20

    • status: pending-invalid --> open-invalid
     
  • Tom Browder
    Tom Browder
    2010-04-20

    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.

     
  • Sean Morrison
    Sean Morrison
    2010-04-20

    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.

     
<< < 1 2 3 > >> (Page 2 of 3)