Re: [brlcad-devel] [GSoC] Next steps...

[Guilherme K. <kun...@gm...>]

On Sun, Jul 31, 2011 at 3:24 PM, Christopher Sean Morrison
<br...@ma...>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
> brl...@li...
> https://lists.sourceforge.net/lists/listinfo/brlcad-devel
>