Reyes Renderer

Ideas, enhancements, feature requests and development related discussion.

Re: Reyes Renderer

Postby dcuny » Fri May 28, 2010 12:21 pm

I've pretty much gutted Inyo in trying to adapt it to the Reyes architecture. I'm only left with a couple of classes - the Triangle, the OctTree. The entire Material system had to be discarded, since Reyes calls shaders to make determinations about color. RenderMan can return the surface color of an object, but my code's not that clever yet. So I'm holding off on implementing the trace() function.

To be honest, I've been a bit fuzzy on exactly how shadows work in RenderMan. I get that there's an illuminance loop, which iterates through each light. (That's another "on hold" feature).

I think the illumination (and shadow) magic occurs in the functions ambient(), diffuse() and specular(). So if the raytracing component is available, it should calculate the light contribution from the lights tagged as ambient and provide that to ambient(), and the contributions from all other lights to diffuse(). I'm guessing that specular() uses the same illumination value as diffuse().

If there's no raytracing component, it seems that RenderMan can provide shadow maps on request, and there's no need to directly access them. There are some clever tricks which can be done to simulate soft lighting via shadow maps, but it's late and my brain is tired. I'm not likely to get to shadow maps in the immediate future, although they would be cool.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Sat May 29, 2010 5:02 am

I've rewritten the code to use programmable surface and light shaders. They're coded in Java, of course, but they follow along the lines of the Renderman documentation. For example, here's the RSL version of a diffuse shader:
Code: Select all
   normal Nf = faceforward( normalize(N), I);
   Oi = Os;
   Ci = Cs * diffuse(Nf) * Oi
   normal Nf = faceforward( normalize(N), I);

Here's what my shader's actually running:
Code: Select all
   Vector3f Nf = new Vector3f();
   Nf.set(Op.faceforward( Op.normalize(sv.surface_N), sv.surface_I));
   sv.surface_Oi.set(sv.surface_Os);
   sv.surface_Ci.set(Op.mul(Op.mul(sv.surface_Cs, sv.diffuse(Nf)), sv.surface_Oi));
This is hand coded, but it's basically a 1:1 map with what's in the RSL. So (in theory) it should be possible to write a parser to convert RSL into Java.

Of course, it would be faster to just implement a diffuse shader with a call to diffuse(), but the normals on some of the models are messed up, so it returns a bunch of black polygons. :(

I've also implemented the illuminance() loop, but I haven't had much time to test it out. There only light shader I've written is a point light, which just passes on the default values.

I've translated all the basic shaders - Constant, Diffuse, Matte, Metal and Plastic.

The point of all this isn't to implement programmable shaders (although they would be nice), but to add shadows into the framework. So at this point, I should be able to add raytracing code into the light shaders to get raytraced shadows. So back to hacking the Inyo code... 8)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Sat May 29, 2010 6:16 pm

Raytracing works... sort of. Here's an triangulated model from an old Inyo demo rendered in the zbuffer:
colored_shadows_cropped.png
Colored shadows using Inyo's raytracing code.

There are two colored lights, one in front, and one in back.

I don't want to admit how long it takes to render that scene. Suffice it to say that I'll be looking for faster code at some point. I'll probably be looking at this implementation at some point. It would also be faster if I could cull backfacing micropolygons, but the normals aren't all correct on the model

Yes, I know there are cracks in the triangles. I'm wondering if perhaps it would have been better to use double instead of float resolution. The anti-aliased rendering using the "classic" renderer with jittered sampling comes out smoother, but the cracks are still visible. Hopefully the dicer will create tighter geometry. :?

The reason I say the code is "sort of" working is that it's only works with triangles. Since the raytracer works directly with triangles, there's no need to dice them, so they go directly into the triangle queue. However, when I try dicing other geometric primitives, it dices it down until the stack overflows. So I'll need to work on that a bit.

In theory, I could do direct raytracing as well. I might have a go at that if it's fairly straight forward. For more advanced shaders, I'd need to store values such as u and v with the triangles.

I'm not quite sure what to do with the AAO. In theory, it should filter the results of the ambient function. Since I currently don't have any ambient lights defined, I've cheated and put it into diffuse() instead. Here's the rabbit rendered with AAO:
rabbit_aao_cliiped.png
AAO on a model with normals facing the wrong direction.

Finally, here's the same model rendered with shadows and AAO:
rabbit_shadows_and_aao_clipped.png
Raytraced shadows and AAO.


Back to work in the raytracer's dice code. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Sun May 30, 2010 3:12 am

It turns out there wasn't any problem with the dice code. It was just that the scaling factor was way off. Here's an interesting rendering from the raytracer:
odd_shadow_cropped.png
The shadows don't match, do they?
odd_shadow_cropped.png (17.31 KiB) Viewed 8130 times

Looking at the debug output from the raytracer clears things up:
odd_shadow_cropped_tris.png
Here's what the raytracer sees.
odd_shadow_cropped_tris.png (9.6 KiB) Viewed 8130 times

Fiddling with the scale factor fixed it pretty easily. But a cool bug! :P

I have doubts that the program can handle anything other than lightweight scenes. I may look at geometry caching, but I really don't want to go down that path.

The next thing on my "to do" list are shadow maps. Most of the code can be pilfered from the zbuffer Hider, so mostly it's getting a grip on matrices. Specifically, I need to figure out how to create a matrix that converts from the eye vector to the light direction vector. It's times like this I wish I had math skills.

After that, I still have a parser for programmable shaders and SDS tessellation to look into. I'll probably look at the SDS code, since programmable shaders was the huge timesink that killed Marin last time. There are still a handful of other features, like an accelerated zbuffer and merging in code from the more recent version of Marin, which supports more primitives and better support for the RIB format.

And there are all sorts of lighting and shading bugs to track down. :(

But I doubt much of that will make it into this coding sprint. That's not really a problem, because I made better progress on this than I expected. 8)
Last edited by dcuny on Sun May 30, 2010 3:13 am, edited 1 time in total.
Reason: I've always got something else to say.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Tue Jun 01, 2010 6:21 am

I can now generate shadowmaps. I was stuck for a while because of some stupid bugs in the lookAt matrix, but it seems to be working OK now. Here's a visualization of a shadowmap:
shadowmap.png
Visualization of a shadowmap.

I'm hoping I can get shadowmaps working by the end of the day... We'll see.

One interesting comment I ran across on one website about the Reyes renderer was support for different sorts of cameras:
There are also several different cameras available, including a fisheye lens, which I until now had thought only a raytracer could handle.
It seems to me that this could be applied to shadow maps as well - for example, a point light's shadow map could be mapped to a spherical camera, so you could get full coverage of the light. That could make dealing with some light sources a bit simpler.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby John VanSickle » Wed Jun 02, 2010 2:40 pm

dcuny wrote:One interesting comment I ran across on one website about the Reyes renderer was support for different sorts of cameras:
There are also several different cameras available, including a fisheye lens, which I until now had thought only a raytracer could handle.

It's a simple matter of replacing one set of projection calculations with another. I suspect that renderers which support only one camera type have optimized the code for the supported type, which might make the developer reluctant to support other types. We programmers like our optimizations.
John VanSickle
 
Posts: 189
Joined: Sat Feb 16, 2008 2:17 am

Re: Reyes Renderer

Postby dcuny » Wed Jun 02, 2010 7:34 pm

John VanSickle wrote:It's a simple matter of replacing one set of projection calculations with another. I suspect that renderers which support only one camera type have optimized the code for the supported type, which might make the developer reluctant to support other types. We programmers like our optimizations.

Yeah, that's my thought as well. There are two approaches: re-invent everything, or use a pre-existing library.

I've gotten shadowmaps to work somewhat:
with_shadowmap_shrunk.PNG
Shadow map shadows (reduced 75%)
with_shadowmap_shrunk.PNG (63.88 KiB) Viewed 8114 times

You can see some odd artifacts on the ball, where no shadow should be cast. It makes the ball look like it's a glass sphere. :(

Additionally, I'm having trouble getting the lookAt matrix to work properly, which makes me think I've screwed something up in the matrix calculations. I'm going to take a break from the code for a while, although I may first try to implement Pixar's percentage closer filtering since the original paper includes the complete code.

I'm re-reading the literature on approximate Catmull-Clark surfaces. The most popular approach seems to be Loop's approach, but this paper suggests that "proper" C1 surfaces can be used by using bi-cubic patches with 13 control points for polar triangles, and Pn patches for extraordinary surfaces. If I can go that route, I'll be able to skip having to deal with fixing the normals on the patch surfaces, which would be a good thing.

    Edit: It appears that the above approach may convert triangles into triangles. My renderer assumes everything tessellates down to quads. If I needed to, I could modify the renderer to create micropolygon triangles as well, but I need to read further to get a better grasp if this. :?

    Edit #2:There's a method in Graphics Gems III for converting a bezier triangle into a bezier patch, so that's a possibility as well. :)

I'm also working on rewriting my mesh code to create half edge data structures, which should make dealing with SDS a bit simpler than it currently is.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Thu Jun 03, 2010 9:36 am

Cool.

I think point cloud AO is the way to go. 3Delight implements it too, it looks great and is really, really fast. Plus: for static parts of a scene you can re-use the point clouds for the next frame(s). Not that generating the point-cloud is such a time consuming task, but it can sum up in an animation.

One thing to keep in mind is that the point cloud generation also uses the dicer. 3Delight is quite flexible here. For example, you can combine multiple point-clouds, e.g. one generated by the dicer from the camera point-of-view (I used a slightly wider viewing angle to also capture some off-screen geometry), plus others generated with orthographic projections (to also catch objects that are out of view or behind the camera and use them for AO).

I did not understand that raytracing approach you've mentioned (the one that does not use ray differentials to estimate the subdivision level needed). I see that this can work for primary rays, but how do you handle reflected rays (especially reflections on a curved surface, which can act magnifying, thus requiring a higher level of subdivision)?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Thu Jun 03, 2010 4:30 pm

sascha wrote:I think point cloud AO is the way to go.

There's no question about it. It's much faster than raytraced AO, and requires much less overhead.

One thing to keep in mind is that the point cloud generation also uses the dicer.

Yes, but there are many different sorts of dicers which can be written, with different sorts of acceptance criteria.

Normally, the dicer calculates two sets of points - the "true" geometry, and the "display" geometry. The "display" geometry is normally the position of the point of the display surface, and is handled by an object derived from a Display device. But you can have any sort of display that you want.

For the raytracer, I'm following the suggestion of the Production Rendering book, which targets a Reyes-style renderer.

They suggest that the simplest approach is to project points onto a sphere. This is quite easy - create a vector from the eye to the point, normalize, and then scale by the radius. This creates tessellation which is more or less equivalent to the scanline projection.

But as you noted, it doesn't handle reflections and refractions from curved surfaces. They suggest two options: tagging objects for finer tessellation, or ray differentials. Since the my goal was to get raytraced shadows, I didn't really have to worry about either.

I'm thinking about implementing ray differentials, but it's not high on my priority list. Raytracing is much slower, and I can't imagine my raytracer being able to complete with something like 3Delight. So I figured it would be more pragmatic to focus on other things the renderer needed first. And since projecting to a sphere was adequate for shadows, that's the route I took. :)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby dcuny » Tue Jun 29, 2010 8:46 am

I've been working on adding Catmull-Clark subdivision surfaces to Marin, but it's been slow going. I'm using a half-edge structure, and it's taken me several rewrites to get things right. What's causing me the most grief is dealing with edges that aren't connected to faces. It's just slow going debugging the code.

I also ran across Ian Stephenson's rendsh program, which earned a place in the 2008 Stupid RenderMan Tricks presentation. It's a fairly complete renderer written using the Bourne shell. This has further shamed me into adding RIB compatibility to Marin. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Reyes Renderer

Postby sascha » Wed Jun 30, 2010 7:36 am

I'm using a half-edge structure, and it's taken me several rewrites to get things right. What's causing me the most grief is dealing with edges that aren't connected to faces. It's just slow going debugging the code.

I know the feeling. :? Took me eons to get that working in JPatch...
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Re: Reyes Renderer

Postby dcuny » Wed Jun 30, 2010 8:07 am

Hi, Sascha! It's good to hear from you again! :D

There are a lot of things I'd like to do with Marin in the long term, but the real goal is to use it as a backend renderer for JPatch for another IRTC submission. So I'm hoping that you can get some version of JPatch running again by the end of summer... :o
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Previous

Return to Development

Who is online

Users browsing this forum: No registered users and 3 guests

cron