On Jul 30, 2011, at 8:52 AM, Guilherme Kunigami wrote: > I've implemented a basic interface to OSL through a BRL-CAD shader (sh_osl). > The problem is that I based my code on a path-tracer algorithm, which > requires many samples. Since BRL-CAD only shoots a single ray, I added a loop > on the osl_render function whenever the ray is the viewing ray (depth = 0). > > Then, I was asked to implement a simple ray-tracer using direct illumination > in sh_osl. I'm not sure OSL was designed for this end, but in the past week > I've been researching and performing tests without success - but maybe it's > just my lack of knowledge on these algorithms. Besides continuing this > research, there are several other options for next taks I have in mind: > > - Add some perturbation on the rays received by sh_osl so we can perform > anti-aliasing; > - Add a framebuffer mode that refreshes at each sample (the problem with this > is that the sampling loop would have to be the outermost. Currently, it's the > innermost -- I see it's kinda different behavior that would be useful only > for the path-tracing algorithm, so wouldn't be better to implement a new, > standalone application?)
It's actually very similar to incremental mode. Sure there are some differences, but from the framebuffer's perspective, you're just streaming more pixel updates. It'd be particularly useful to specify all of the various raytracer buffering modes as a command-line option: line-buffered, frame-buffered, incremental, and unbuffered. A new "random streaming" mode could be added to support the path tracer, which would be similar to a multi-frame unbuffered render. That kind of "multi-sampled pixel" rendering would be useful for jitter and hypersample too, where you might want to incrementally see pixels updated.. > - Implement an interface to build the osl shader groups. It's cumbersome and > error-prone to add them by hand, but this seem to be too long for the given > timeframe, since I also would have to learn Tcl. It'd be more useful to make OSL pull information from our existing non-OSL shader descriptions that are set on objects and use that when setting up parameters to OSL shaders. That way, I could take an existing model as-is with colors, transparency, reflectance, lights, etc all described, but use OSL to render the image without having to change the model at all. > Which of these do you think are more desirable? Any other suggestions? You've made excellent progress integrating support for path tracing, so I'd think at this point it's probably best to continue focusing your efforts there to make it production-usable. That is, work on making it fully integrated, cleanup any messy code, resolve any hacks, document the logic, document how a user might try it out in the next release, add any command-line options to rt for the aforementioned unbuffered/streaming framebuffer modes, etc. Basically, working towards making it as absolutely easy to use as possible. That means we'll have to sort out compilation/integration of OSL too, so we can enable it when we push out a future release. If you can document what steps are presently required, hopefully that process can become fully managed or painless too. Cheers! Sean ------------------------------------------------------------------------------ Got Input? Slashdot Needs You. Take our quick survey online. Come on, we don't ask for help often. Plus, you'll get a chance to win $100 to spend on ThinkGeek. http://p.sf.net/sfu/slashdot-survey _______________________________________________ BRL-CAD Developer mailing list brlcad-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/brlcad-devel
