Reyes Renderer

Ideas, enhancements, feature requests and development related discussion.

Re: Reyes Renderer

Postby dcuny » Tue Sep 09, 2008 8:26 am

It looks like Marin will continue to be on hold for the rest of September. Everyone here's sick, and my allergies have kicked in as well. Any sort of momentum I had going from Summer is pretty well gone, so once I get feeling better, I'll have to psych myself into working on the code again. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Mon Sep 15, 2008 10:11 am

I know the feeling.
I'll have to psych myself into working on the code again.

If it worked, would you coach me? ;-)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Mon Sep 15, 2008 4:43 pm

sascha wrote:If it worked, would you coach me? ;-)

I'll get back to you on that one. :P

When a programming project bogs down for me, there are usually a number of factors that come into play:
  • The project reaches a point of complexity that prevents progress. With marin, it's the interaction of the light and the surface shaders. It's not that it's particularly difficult, but it requires a level of focus that I haven't got at the moment. The result it that I stop making forward progress on the project, and lose momentum.
  • There are fundamental bugs in the project. To some extent this is true with all coding projects. This starts to eat away at confidence that there's any hope that the project will get completed. There are so many small bugs in marin that make me wonder if I'll ever get the project completed.
  • Something changes physically in the environment. With marin, it's a combination of the change of the season and physical illness. This breaks the "coding groove", which is really hard to get back.
There's some amount of self-doubt, as well. There are already a number of free projects similar to marin, and it's not clear that the world needs another REYES renderer.

But I'm (slowly) starting to feel better, and taking a break from the project really helps. Being away from the problem helps get a new perspective as well, as well as getting back a realistic emotional perspective. Getting back into the code groove will probably be tricky, but there's no point in starting until I start feeling healthy again.

The biggest problem is that, once I leave a project alone for too long, I realize that life goes on just fine if I'm not working on it. That's one of the reasons I pester you about JPatch. While marin is replaceable by other software, that's not the case with JPatch. So if enthusiasm for a project doesn't work, I fall back on guilt - in the case of JPatch, by bugging you endlessly. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Mon Sep 15, 2008 7:48 pm

I've got a cold, but besides that, I feel the same about the three points you've mentioned.

I had quite a coding run before visiting my in-laws about three weeks ago (the morph system is almost complete now), but after we returned I couldn't catch on.
I second the complexity point, but it has never stopped me from working on. But some times, when I feel that things become too complex, I need to let it rest for a while, sometimes even a month or more. But all in all the situation looks much better now than with JPatch 0.3 or 0.4 - there I had doubts (about patches in general, the problems with patch modeling and the artifacts visible in renderings), and there have been quite a few unresolved bugs (I rewrote the parts that modify the patch-topology about three times, and ran into the same problems again and again).

There's nothing like that now - the code's become a lot longer, but in some ways also simpler. I'm confident that modeling with SDS will be easy, renderings will look good, and there's no fundamental flaw. Bugs are always annoying, but this time they are harmless compared to JPatch 0.3 or 0.4. All in all, the puzzle pieces fit together much nicer than ever, so there's nothing that would stop my continuing from working on JPatch.
I guess the reason for the extremely slow pace these days is real life with family and kids, not to mention work - even if I had time in the evening or at night, I'm much too tired. But this should get better from now on, I think we're over the most stressful days (Noah's 2 years now, and we don't plan a third child at the moment ;-) )

I'll try to continue working on JPatch this week, hopefully it will keep up until I can finally upload something useful.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Tue Sep 16, 2008 6:35 am

sascha wrote:I guess the reason for the extremely slow pace these days is real life with family and kids, not to mention work - even if I had time in the evening or at night, I'm much too tired. But this should get better from now on, I think we're over the most stressful days (Noah's 2 years now, and we don't plan a third child at the moment)

Don't let JPatch get in the way of that. ;)

But seriously, there's something to be said for spacing kids close together. My older brother is about a year older than me, and my younger brother only 11 months younger. It must have been tough on my parents, but it was great for us. (My three sisters were similarly spaced). In contrast, there were a number of years between my wife's siblings, and she ended up acting more as a baby sitter than a sister much of the time. My own kids are spaced a couple years apart, and they get along... well, about as well as you could expect siblings to get along.

I'll try to continue working on JPatch this week, hopefully it will keep up until I can finally upload something useful.

As always, I'm looking forward to whatever you've got.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Ambient Occlusion

Postby dcuny » Mon Dec 22, 2008 11:25 am

I was looking at Pixar's paper "Point-Based Approximate Color Bleeding", which uses a REYES style renderer. The author writes:

    The input is a point cloud of surftels (direct illumination sample points). In our illumination, we use a REYES-style renderer [Cook et. al 1987] to subdivide the surfaces into small micropolygons, compute the color of each micropolygon, and store the colored polygons as surftels.
So it's essentially the same as the normal REYES rasterization, but that it uses none of the usual optimizations. For example, the entire point cloud has to be retained, and culling because surfaces are occluded or backfacing isn't used. They also note:

    To generate the point cloud representation, the camera must be pulled back or the viewing frustrum enlarged so that all the parts of the scene that should contribute color bleeding are within view.
So it's got the same sorts of problems that screen-space ambient occlusion has - you've got to extend the frame a bit or you'll get shading anomalies. It's also got a huge footprint - the point cloud ends up having to be put into a disk-based storage. So when I get back to this project, I suspect I'll be focusing on SSAO instead. I've seen some very good results when you allow high levels of sampling.

I also played around with a number of the demos included with Aqsis, and the fake plastic look of the default shader made me realize that some sort of uber-shader might be a good thing to look into. I had read somewhere that Pixar had done this with Wall-E. For example, instead of things like specular being an ad-hoc parameter, it because part of the shader's spectrum. The result was that the shaders were much more realistic in their behavior with light.

Programmability of the shader is still a good thing, but there's no need to duplicate the functionality of Renderman. Better programs (like Aqsis) already to that. For really complex effects (like AO and SSS) it's probably better to hardcode that functionality anyway.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Tue Dec 23, 2008 3:19 pm

IIRC 3Delight does just that.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Tue Dec 23, 2008 8:05 pm

Yeah, 3Delight is a very nice renderer. It's probably what I'll end up using with JPatch. You've already mentioned you're targeting RenderMan as the primary renderer. (I'll still try to get Marin to be usable, though).

I tried installing it under Ubuntu, but ran into some problems. At the point where you release a working version of JPatch, I'll try reinstalling it again.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Wed Dec 24, 2008 8:51 am

No need to wait that long :wink:

Seriously, 3Delight seems to be a very good renderer, and so far I've only scratched the surface of what's possible.
I'd need someone with more in depth knowledge of RenderMan in general and 3Delight in particular to fine-tune the "workflow" - i.e. how and when to set up shadow and environment maps, how to handle shaders, how to do multi-pass rendering to different layers, how to use OpenEXR, etc...

So if you plan to delve into 3Delight anyway, it's never too early. I think you could also use it as a "reference" for Marin.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Mon Dec 29, 2008 11:11 am

I ran across paper that explains Nvidia's Horizon-Split Ambient Occlusion. It goes into a lot more detail than the prior paper. The no longer perform raymarching along the normal, and they solve a number of problems by introducing an angle bias term and an sample attenuation. They clamp at the edges of the screen, and I don't see the sort of artifacts that I've seen in other SSOA algorithms.

They still use blurring to eliminate noise, but their unblurred 16x32 sampling looks close to raytraced quality. I've very impressed. I'll have a look at the code when I get a chance - I'd really like to get this into Marin. :)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Wed Dec 31, 2008 8:15 am

Rather than mess with the Marin code (and break something) I went searching for a Java renderer. I found one here, part of a class assignment. There are a few things intentionally missing from it, so I've been pilfering the missing code (such as matrix inversion and transposition) from Marin. I also need to export some models from Blender, since none of the supplied models have normals.

Hopefully I can get this thing up and running quickly, so I can start working with SSAO. If I can actually get this to work, I'd like to try adding zbuffer shadows and deferred shading as well. I've been wanting a small raster renderer for some time, and this looks like it might fit the bill.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Wed Jan 07, 2009 7:34 pm

Because SSAO uses a depth buffer that only maintains the distance of the closest object, it generates discontinuities when rendering occlusion from the side or near the back of objects.

So I'm looking into possibly using deep shadow maps (DSMs) to store depth information at multiple locations. Another possibility would be to store n number of non-uniform depth samples, stratifying by slices.

One of the downsides of DSMs is that they eat up a lot of memory. I've been playing with the idea of caching Marin's render buffer to disk. This might provide a bit more incentive to work on this.

Interestingly, it looks like Blender may be getting DSMs.

My older (less math challenged) brother is in town, so I should be meeting with him tonight and going over the Nvidia AO shader code.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Wed Jan 07, 2009 7:55 pm

I've been playing with the idea of caching Marin's render buffer to disk

Since you render buckets, there shouldn't be a problem. A single bucket can easily fit into the RAM, and once a bucket is finished, it can be swapped out to disk.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Wed Jan 07, 2009 9:16 pm

There's a small amount of additional complexity here. Because SSAO searches the zbuffer over a given radius (depending on the depth), so there may be need to look at some adjacent tiles, and not just the current tile. But caching into tiles will be much cheaper than holding the entire buffer in memory.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Thu Jan 08, 2009 9:10 am

Is memory really a concern? Even at 1920x1080 a DSM won't take much more than say 250MB. And with buckets, there won't be any issues, since you just need 9 buckets in memory then.

But if you use DSMs for SSAO, I can't see the advantage over the point-cloud approach. SSAO seems to be nice for realtime rendering, so it re-uses the z-buffer. In your DSM approach you'd have to compute the DSM is a separate step, so there's no real gain over the point-cloud approach. Using 3Delight for example, generating the point-cloud is just a matter of a few seconds (it simply runs the dicer and computes the normals), and you've got a lot more flexibility.

IMHO the DSM would be just an unnecessarily complex representation of the point-cloud data, so why not use the point-cloud in the first place?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron