This is a follow-on to three other ray sampling tasks.
Basically, show what the sampling currently looks like for all sample parameterizations by either 1) extending rtshot with a new plot/debug option or 2) utilizing existing debug infrastructure (see -x and -! command-line options). Output a 3D visualization for the actual calculated ray values from rtshot.
You can either create actual geometry (e.g., call mk_rcc() for each ray), create 3D line segment plot data representing each ray (brlman plot3, see include/plot3.h), or utilize existing debug infrastructure where the library does the latter for you (run "grep -i plot include/* | grep -i debug" and set the debug code on the command line).
Submit one or more images per sample pattern that help convey understanding of the pattern(s) possible along with the plot files for each pattern or a .g file with all pattern visualizations as separate combinations. Submit any patchfile changes to rtshot if modified.
References:- include/optical.h
- include/raytrace.h
| File name/URL | File size | Date submitted | |
|---|---|---|---|
| task-51-bundle-visualizations-2.tar.gz | 68.0 KB | January 12 2015 21:27 UTC | |
| task-51-bundle-visualizations-2-v2.diff | 9.5 KB | January 12 2015 22:15 UTC | |
| task-51-bundle-visualizations-2-v3.diff | 11.5 KB | January 13 2015 04:17 UTC |
I would like to work on this task.
This task has been assigned to Andromeda Galaxy. You have 100 hours to complete this task, good luck!
The biggest modification to rtshot/librt in this patch is that it changes rt_raybundle_maker() to use an rt_shootrays()-style api, returning a struct xrays, instead of the rt_shootray_bundle() api it had previously been using. This was necessary because rt_shootray_bundle() only calls a_hit() once, and rtshot doesn't seem to be able to extract the necessary information to graph the rays from that result. The patch also makes rtshot be able to use the new bundle types, and fixes a couple of errors that I found using these visualizations that were in the bundling functions. The png, plot3, and log files were generated from a run of run.sh, which automatedly created all of the necessary visualizations.
The work on this task is ready to be reviewed.
Sorry for the slightly differing zooms in the png files; it took me about 4 hours to get rtshot set up properly, fix rt_raybundle_maker() so that the plot3 files came out right, and write the first version of these scripts, so I didn't try to refine the images too much more after I got these ones done.
I just found out that while working on that, starseeker found one of the problems that this testing uncovered that caused an unused variable and removed the variable; the -v2 version of the patch adds the variable back in, as is necessary for the fix included in the patch.
One of the mentors has sent this task back for more work. Talk to the mentor(s) assigned to this task to satisfy the requirements needed to complete this task, submit your work again and mark the task as complete once you re-submit your work.
Oof, you're definitely starting to poke a hornets nest now... ;)
So this looks fantastic, the visualizations are perfect. Heck, I didn't even realize that's what the rt_raybundle_maker sampling looked like... That said, changing that already-published function's API violates our CHANGES contract as it's not a minimally impacting. I'll have to talk with some people to see if this will break their usage. This is our problem to sort out, though, as the change seems reasonable at first glance (we just can't release until we resolve this).
We really probably want a hybrid of shootrays and bundle_maker because I think an array will be more desirable long-term than a linked list, but that's a change for another day.
That said, that's not the reason I marked this as needing more work. That was simply because you modified rtshot with new command-line options and don't document them in doc/docbook/system/man1/en/rtshot.xml! They go hand in hand. ;)
On that note, instead of -A, you should probably use -p for perspective angle so it's consistent with the other rt* tools. Also, the help text for -c and -l indicate they're the same thing. Perhaps you meant -c is per ring/radius/depth or ring/radius/width or perhaps you did mean ring/radius/length and -l needs to be -d and use some other word like dimensions. But then if they're dimensions, then what is -c length supposed to mean for a rect/frustum type? For that matter, does -l also apply to frustum grids?
Just some minor consistency clean-up and careful wording should clear that up quickly.
-c is the number of rays per ring/radius/length, whereas -l is used to specify what the length actually is
The work on this task is ready to be reviewed.
Congratulations, this task has been completed successfully.