came across another one with spectral rendering
http://www.steckles.com/metropolis.html
he seems to have nurbs and low memory Micro Poly displacement intergrated as well - nice!
Use a Reyes geometry system, so that allows for that sort of stuff easily. Read his blog for more details
some nice links on the left as well
Another MLT renderer
Re: Another MLT renderer
1. there are quite a few spectral mlt renderers flying around in the shadows these days...
2. reyes rendering is fundamentally different from ray tracing (it's rasterising-based, based on micropolygons), so it's not going to be an exact match. probably it's more related to the pharr-hanrahan scheme: http://graphics.stanford.edu/papers/displace/
the big question is, how effective is this caching scheme with an incoherent rendering method like mlt?
2. reyes rendering is fundamentally different from ray tracing (it's rasterising-based, based on micropolygons), so it's not going to be an exact match. probably it's more related to the pharr-hanrahan scheme: http://graphics.stanford.edu/papers/displace/
the big question is, how effective is this caching scheme with an incoherent rendering method like mlt?
It's really, really similar the the Reyes pipeline. Similar enough that I wrote a Reyes renderer just by copying and pasting most of the code.lyc wrote:2. reyes rendering is fundamentally different from ray tracing (it's rasterising-based, based on micropolygons), so it's not going to be an exact match. probably it's more related to the pharr-hanrahan scheme: http://graphics.stanford.edu/papers/displace/
Reyes has five steps:
Bound
Split
Dice
Project
Sample
with the bounding and splitting done recursively.
The pipeline in my little raytracer is identical, except for the last two steps. Instead of projecting, the grids are simply added to the cache.
In its original form, the geometry cache worked fairly well as long as the total size of all the microgrids was smaller than the system memory. I've since added multi-resolution geometry caching (http://www.seanet.com/~myandper/abstract/eg03.htm) which drastically increased the efficiency. Sure, it's not 100% accurate, but it's so close that it's pretty much impossible to tell.lyc wrote:the big question is, how effective is this caching scheme with an incoherent rendering method like mlt?
Well, when an html document that only gets four or five requests per day suddenly gets hundreds, somethings probably up.
I'd post additional renders, but don't have anything that couldn't be done as well or better in Indigo. Really, who cares about seeing another Cornell Box or skylight image anyway. It's been done to death.
In any case, I've since switched to Reyes as my toy renderer algorithm of choice. Somehow I think that's a bit antithetical to the main interest on this forum.
Anyway, I've been following the progress of Indigo since the very first IOTD image on Flipcode. It's progress in the intervening time has been quite impressive. Every programmer dreams that their raytracer might one day be used by other people. As far as I know, Indigo is the only recent one that's actually achieved that.
I'd post additional renders, but don't have anything that couldn't be done as well or better in Indigo. Really, who cares about seeing another Cornell Box or skylight image anyway. It's been done to death.
In any case, I've since switched to Reyes as my toy renderer algorithm of choice. Somehow I think that's a bit antithetical to the main interest on this forum.
Anyway, I've been following the progress of Indigo since the very first IOTD image on Flipcode. It's progress in the intervening time has been quite impressive. Every programmer dreams that their raytracer might one day be used by other people. As far as I know, Indigo is the only recent one that's actually achieved that.
Who is online
Users browsing this forum: No registered users and 104 guests