On Sun, Jul 31, 2011 at 3:24 PM, Christopher Sean Morrison <brl...@mac.com>wrote:
> > 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. Indeed. The only thing is that we'll need a buffer to keep partial sums. As far as I udnerstodd, in incremental mode, each pass is independent from the other. > 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. > Do you mean adding an option like the lightmodel? Something like -fb # Where # 0 - unbuffered 1 - incremental 2 - line-buffered 3 - frame-buffered Is the frame-buffered mode this one I just suggested? I didn't get this "random streaming" mode. How does it work? > > 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. > Do you mean converting a non-OSL shader into a OSL one automatically? > > > 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. > Ok. > > 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. > Ok. > > 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 >
------------------------------------------------------------------------------ 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
