Sunflow Renderer

Ideas, enhancements, feature requests and development related discussion.

Postby sascha » Mon Feb 26, 2007 9:03 pm

Assuming JPatch supports returning sub-frame triangle positions... I don't have the code handy at the moment.

JPatch currently doesn't support motion blur at all, but it isn't hard to add. I wouldn't export any sub-frame triangles though - all thats needed is the start and the end position of everything. I'd say that the renderer is responsible for the interpolation, and linear interpolation should be sufficient. Alternatively JPatch could output start position and velocity and end position and velocity of each vertex - this way the renderer could even decide to do cubic interpolation.
Another interesting thing is to simply interpolate the x/y (screen!) velocity over the triangles/quads and export it as separate channels. This way a postprocessing tool could do (fake) motion blur later.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Feb 26, 2007 11:20 pm

The part that I'm a bit unclear on is whether JPatch will not render the same set of triangles for frame n as it will from frame n+1.

Since JPatch adaptively tesselates as mesh, might some triangles in one frame disappear on another (because they aren't needed)? :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Feb 26, 2007 11:35 pm

The part that I'm a bit unclear on is whether JPatch will not render the same set of triangles for frame n as it will from frame n+1.

It could either export (per frame), the data for this and for the next frame, or for this and for the previous frame.
I think using this and the next is more intuitive. It would logically map to "at the beginning of this frame" and "at the end of this frame".

Since JPatch adaptively tesselates as mesh

It does this only for the interactive display. When exporting to a renderer it either uses some high-level primitives (Bezier patches or now SDS) - in which case the renderer may or may not perform adaptive tesselartion, or JPatch dices it to a fixed subdivision level.
So - no, the topology does not change.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Tue Feb 27, 2007 3:41 am

Argh... I found some bugs in the latest Sunflow export code:
  • When I export the points and vertices, I didn't negate the x axis value. As a result, the image is flipped.
  • I got the image width and height backwards.
  • The smooth_normals parameter isn't needed.
  • I'm getting an odd artifact on one of the characters, as if the normals are flipped.
  • I'm getting noise on the distant volcano.
  • I still have no clue how to set up the aspect ratio.
I'll try to get a corrected version out tonight. :?

Edit: I won't get a chance to post the code tonight. I spent most of my time tracking down a rendering glitch in Sunflow:
Image]
It appears to be related to the size of the triangle in the mesh. When I made the mesh huge, I got:
Image
I've posted a question about it on the Sunflow forum.

I rendered a chunk of my Moai animation in Sunflow. It averaged about 8 seconds per frame, which is pretty fast. However, there's no texture on the Moai, and the lighting isn't quite as nice as with Inyo. Odd... :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Tue Feb 27, 2007 6:40 pm

It looks like it's a known issue related to massive objects. At least I know I didn't screw up the export routine. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Mar 01, 2007 9:57 am

Sunflow's got builtin support for SDS, so when it's ready in JPatch, I can add it to the Sunflow exporter code.

It's also got support for Bezier patches, so I could steal the code from the POV-Ray exporter and add support for that, too. But is that worth doing? You had it listed as an "experimental" features in POV-Ray, so did it work well, or are there issues with it? Obviously, 5-point patches won't export. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Mar 01, 2007 11:57 am

Obviously, 5-point patches won't export.

That's exactly where the problem is: 5-Point patches are exported as 5 regular (4-sided) patches (sharing a common hub in the original 5-point patch), but I never got it right, so the 5 patches don't connect smoothly without creases. There's a similar problem with hooks, and even if those two problems were solved, the "flat spot" problem remains. This is caused by using twist vectors of 0 (in the Hermite form of the Bezier patch) for computing the missing inner 4 controlpoints.
I've read a paper about twist estimation, but it only dealt with rectangular topologies, and I was unable to map that to arbitrary topologies with 3- and 5-point patches.

That's one of the many reasons why I'm happy that I've switch to the Catmull-Clark subdivision scheme. Although the implementation wasn't easy, it is a well researched and well documented topic, so I wasn't on my own. The code that dices the mesh is much more complex than e.g. the code that evaluates a bezier patch (a one-liner :)), but on the other hand the internal representation of the mesh is much simpler and less error prone than the patches were.

So the bottom line is (I guess): Forget patches. I'll try to make a converter that converts old JPatch patch models to SDS as good as possible, but there's no need to export patches to a renderer. If the renderer has native support for SDS that's good, if not JPatch will do the dicing (and export a quad or triangle mesh).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Mar 01, 2007 8:12 pm

OK, I'll not bother looking at adding support for patches into the Sunflow exporter. :)

I assume that the API interface for generating triangular mesh will be the same for SDS as it is for patches, so when you add it, I'm guessing it will be pretty much transparent.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri Mar 02, 2007 11:12 am

Christopher posted the fix to the shadow aliasing problem this evening. It was a problem with setting the shadow bias. I ran it on my test scene, and it's taken care of the problem.

He's changed the API a bit, so I've had to make a dozen or so minor changes to the exporter. If anyone wants the latest code to play with, let me know and I'll post it. But be warned that you'll need to grab the SVN version of the code as well.

You'll also need to modify one of the lines in the PointLight class if you want infinite point lights.

A lot of the images I get out of Sunflow are overexposed, and I don't have much luck fiddling with lights. There's a simple exposure function that should take care of that. It's only a couple of lines of code to implement, and it gives great results:
ImageImageImage
The first has no exposure control, the second has it with a value of 1, and the third a value of .5. (The noise in the image is because I've got the settings for the renderer really low, so I can get images with sunsky lighting in about 20 seconds). Hopefully something like this will get added. :)

Anyway, you can see that the artifacts are gone from the scene. I've rendered a couple of seconds of animation, and it looks pretty good. I'll set the parameters a bit higher and let it render the Moai animation overnight...
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri Mar 02, 2007 8:25 pm

If you look at the base of the Moai, you'll see that the shading isn't smooth. I'm not sure what's causing it, but Sunflow appears to be using the actual normal instead of the surface normal for shadow calculations.

The result is that the mesh show shadow artifacts when being animated - shadows "pop" on and off, and they aren't smoothly shaded. This is probably why the Sunflow images look less nice than Inyo's.

I've reported the bug, so hopefully it'll be taken care of.

I haven't tried playing with materials yet, but at this point, Sunflow is looking to be a good replacement for Inyo.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Tue Mar 06, 2007 2:17 am

I've been bugged by the colors of the "round" Moai's eyes - later renderings have them as the same color as the Moai itself, which isn't right.

So I'm pretty sure that there's a bug in how I'm declaring the mesh colors. :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Wed Apr 18, 2007 7:15 pm

I'd like to get Sunflow integrated into the upcoming version of JPatch. Of particular interest is the IPR option for (near) realtime raytracing.

I've got a converter that works with the old version of JPatch.

Anything else I can do to ensure my evil scheme comes to fruition? ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Wed Apr 18, 2007 8:20 pm

Anything else I can do to ensure my evil scheme comes to fruition?

Not yet. The API might change a bit, but there will - just as now - be a way to receive the tesselated triangles per material to pass it to the renderer. I don't know how to eventually handle shaders. It would be nice to have a GUI shader builder that can export shaders for a wider range of renderers (e.g. RSL, GLSL, and Sunflow if it supports programmable shaders - I've read something about Janino in one of your messages).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Wed Apr 18, 2007 10:14 pm

What I'm really asking about is having IPR - Sunflow's progressive renderer - to be built into JPatch's viewports. Basically, Sunflow can do successive refinement raytracing, so you can get a very fast realtime rendering of a scene.

IPR can give pretty good quality in a fraction of a second. That way, you could get fast feedback as you move stuff around, change the lighting, modify the materials, and so on.

Image

Hrm... Now that I've reduced these renders to miniature size, it occurs to me that it would be nice to have some sort of "thumbnail" option as well, so it would render in the corner of a viewport. Most of the time, you don't need to see the full render to get a feel for how it looks, and each time you double a render size with a raytracer, the rendering time quadruples... :?

It would also be nice if the final rendering could happen in JPatch's viewport, instead of a popup window. As it currently is, it feels tacked on, instead of integrated into it. That's one of the defects that AoI suffers from as well.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Re: Sunflow Renderer

Postby dcuny » Mon Jan 26, 2009 8:00 pm

It looks like Chris has committed to continuing work with Sunflow in Java. That's good news, but I'm pressing for a few more details, like what sort of features he'll be adding, and what sort of release schedule he has in mind. It's been a couple years since an "official" release, although people have been creating unofficial builds from the SVN. I'll post more details if they become available.

I still think Sunflow would be a great "builtin" for JPatch.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

PreviousNext

Return to Development

Who is online

Users browsing this forum: No registered users and 1 guest

cron