If you're willing to wade through volumes of debug output, there's an
option you can pass to rt that will output lots of information about
the ray shooting process. You should be able to identify what geometry
the convergence fails on by running rt with that debug flag, locating
the converge failure message and then back-tracing the debug log to see
what geometry was involved.
The debug flag to librt for rt is the -x option, 4 is the number for
debugging ray shots. The -x 4 debug option will output too much
information to be useful from within mged, so you'll have to run rt
outside of mged. An easy means to do that is to open up the
geometry/view that you wish to render in mged and type:
This will create a raytrace shell script called poly.rt that contains
the saved mged view. You can then run the script outside of mged on a
terminal command line as follows:
./poly.rt -x 4 -s 32
That will render a 32x32 image with ray shooting debug turned on. It
may take it a very long time to complete but when it does, you should
have a very large log file called poly.rt.log. You should be able to
review that and see which primitive is causing the problem.
If you don't see the converge warning in the log, then you'll have to
use a different/larger render size (-s 64, -s 256, etc).. Doing so
will take orders of magnitude longer to complete and will dump out even
larger data files.
Another path that I'd use myself would be to run rt through a debugger
and break on either the convergence failure line or rt_poly_findroot..
That would probably be the fastest. If you can share the geometry
file, or even a subset that presents the problem, I'll take a look at
it and see if I can figure out what's going on as well..
p.s. Be sure to remove the output pix and log files for subsequent runs
of the raytrace script.
On Mar 9, 2005, at 3:48 PM, Browder, Tom wrote:
> When ray tracing some objects, one gets an error message through
> 'bu_log' like:
> 'rt_poly_findroot: didn't converge in 20 iterations...'
> Is there any way (without modifying the source code) to get the name of
> the region or, better, the solid causing the problem?
> Tom Browder