Sunflow Renderer

Ideas, enhancements, feature requests and development related discussion.

Sunflow Renderer

Postby dcuny » Wed Dec 08, 2004 5:59 am

I just found out that Christopher Kulla has resumed work on Sunflow. I immediately sent him an email to see if he was interested in getting it into Inyo. He said that he'd like to see it integrated into other projects, but didn't have the time to work on it personally. Still, he offered to help me get it done. :D

I'm pretty excited by this - I was under the impression that Christopher wasn't going to be able to continue work on Sunflow, and that's one of the main reasons that I started working on Inyo. I've had a chance to look through his code, and it's very nice.
Last edited by dcuny on Wed Feb 02, 2005 1:09 am, edited 1 time in total.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Dec 09, 2004 6:27 pm

Just a small update - Christopher's confirmed that the interface to Sunflow would be roughly the same as with Inyo. Sunflow supports custom textures, so linking into JPatch's textures can probably be done via that mechanism. So we should be able to get the goodness of JPatch's textures. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Tue Feb 01, 2005 11:18 pm

I've created a SunflowAPI class that encapsulates the Sunflow API without needing to go through the GUI. I just hacked up SunflowInterface.java; it's pretty cleanly written.

Unfortunately, I only get black images out of it. I'm probably doing something really, really stupid, but I don't see it. I'm hoping that Chris can take a look at the code and find the bug. The zipped source file can be found here.

There are only a couple other small changes to make this work as an interface that JPatch can use. These were actually already in the SunflowInterface class, but I ripped them out because I wanted to get rid of the GUI dependancies, so putting them back in should be easy:
  • Make render threaded, so it's non-blocking;
  • Add a callback to progress;
  • Add a cancel interface;
  • Modify the Bitmap class so it can return an Image. Right now, Sunflow assumes it will generate an output file. I had to make a small change to the Scene.java file, so that it returns a Bitmap instead of rendering it to a file.
That's about it. It should be as easy to integrate into JPatch as Inyo. :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Wed Feb 02, 2005 10:17 am

Feh, lots of stupid errors, not the least of which was posting a zero byte zip file. :roll:

Most importantly, Chris pointed out that the strength of the light was way too low given how far away it was. A few minor tweaks, and it was working. :D

I thought I was going to have to do a lot more work, but Sunflow already had implemented getProgress and cancelRendering functionality via a ProgressDisplay Interface class. I made a small addition to the Bitmap class to support returning an image, and that was about all the changes Sunflow needed.

On the JPatch side, I didn't have the JPatch classes, so I hacked together SunflowTester to pretend it's JPatch. It calls Sunflow to create and render a test scene. The SunflowJPatchInterface and JPatchSunflowInterface define the interfaces, and rendering takes place on a background thread.

The main limitation is the shaders, which are limited to diffuse, glass and mirror. Texture is also supported, but expects a texture file. I suspect that relatively simple scenes would translate over pretty well.

I know you're primarily interested in supporting RenderMan compliant renderers, but I'd really like to see Sunflow in action, and benchmark it against Inyo.

You can find the new source at the same old location: sunflow_api.zip
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Wed Jun 08, 2005 10:34 pm

I took a look at the Sunflow site, and I see there have been a number of updates during the month of May. The gallery has a couple of stunning new additions to it, showing what can be done with lightprobes and motion blur... :shock:
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Jun 10, 2005 4:10 pm

Nice. It would be interesting to compare it with Inyo - I think Inyo's AO and depth of filed features could produce similar images - and implementing HDRI should be trivial.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Jun 11, 2005 8:06 am

For some reason, I keep thinking that HDRI is cheating. ;)

I'll look into it. I'm curious to find out what it would take to make a HDRI shot of a CGI environment.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Jun 11, 2005 10:37 am

I think the main application for HDRI is taking HDRI images of actual sets and using them in CGI (I think they take photos of a large reflecting sphere).
But I think it can be used together with AO to get a cheap radiosity/GI effect. Just sample a HDRI image of the scene (a sphereical projection or a cube-map, just like making an environment map for reflections), then use it as the background when applying ambient occlusion.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Jun 11, 2005 8:56 pm

Yes, most HDRI images are made by photographing "light probes", which are large reflective spheres. What's special about these pictures is that they are actually several images taken at different focal stops. The difference between the different f-stops isn't linear, so you're actually capturing a fairly complex light phenomena.

Still, you can get passable results using a plain old photograph as a source image instead of an HDRI image.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Mon Jan 16, 2006 10:37 am

The Sunflow version 0.05.1 was released today. I grabbed a copy and went to compile it, but javac isn't available from the command line of my Linux box. :evil:

It's good to see progress on it continuing. I took a look at the code I had written a while back to glue it to JPatch, but it's hopelessly out of date; I'd have to rewrite it from scratch. But getting Sunflow working with JPatch is still on my "To Do" list for this year. Someone's already added support for Blender. Since Sunflow is a native Java application, it would be especially sweet to have support for it in JPatch.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Feb 15, 2007 1:37 am

There's been a new release of Sunflow. I've been playing around with it, and it's really, really nice. :) The thing I really like about Sunflow is that the renderings look like they're real objects. A lot of this has to do with having a pretty sophisticated handling of lighting.

Sunflow's got an optional GUI front end, so if you haven't played with it, grab a copy and the example files, and have a look.

This was rendered using an example file supplied:
Image
This took 110 seconds to render, and it includes a ton of effects:
  • Sky simulation, including skylight lighting
  • Soft shadows
  • Focal blur
  • Reflections and refractions
It's a lot of fun to play around with the various settings - it would be a lot more fun to be able to use this in JPatch!

My feeling has always been that this would probably be a better solution that Inyo as JPatch's "builtin" high quality renderer. This release only solidifies that feeling.

One of the really nice features is the interactive progressive rendering (IPR), which successively refines the image. It's designed to be interactive, so you can modify the image, and get a quick response back. Here's the same shot as above, using IPR. It took 6 seconds to render, but still includes all the effects (lighting, blur etc):
Image
It would be nice to have something like this for quick "preview" renderings, both from within JPatch (for example, moving lights) or generating animations (a preview renderer with full effects).

Here's the same image, interrupted after only 1 second of rendering:
Image
Imagine having this built into JPatch. :)

It's been a while since I've looked at the Sunflow source, but I'll have another go at it. This time around, I'll have a look at the POV-Ray interface, since it's probably closer to the model that I want to use - pass the parameters via command line, and get an image file back.

So is this something I could convince you to eventually add to JPatch? :P
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Feb 15, 2007 10:41 am

To add a new renderer, you'd create a class like PovraySettings or RendermanSettings to hold the settings. The Settings class extends AbstractSettings, and RendererSettings holds specific settings for the various sorts of settings.

You'd then add the renderer to the list in RendererSettings:
Code: Select all
public static enum Renderer { POVRAY, RENDERMAN, INYO, PREVIZ };
and the include an instance of the new renderer setting in RendererSettings.

You'd need to create a renderer class such as InyoRenderer3 or PovrayRenderer3. It would implement the Renderer class, which only has one method, abort.

The actual work is done by AnimationRenderer, which has renderer specific behaviors in renderFrame. So you'd add renderer-specific behavior for the renderer there. POVRAY and RENDERMAN both give examples of command line calls to an external renderer. Basically, write the commands out, execute it with Runtime.getRuntime().exec(...), and waitFor the process to finish.

Does that sound about right?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Feb 15, 2007 12:20 pm

I agree, the Sunflow renderings are stunning. But can it be used in animations? Even noise that is virtually invisible in stills can be very annoying in animations, and global illumination tends to add a lot of noise, and the only solution is to use more samples, thus multiplying the time it takes to render an image (correct me if I'm wrong).
So, is it feasible to use a GI renderer to render HD animations?

IIRC your description of RendererSettings, InyoRenderer and AnimationRenderer is right. It's not good OO design though (there are multiple classes, but then there's an ugly select block in AnimationRenderer). I'll need to redesign this some day.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Thu Feb 15, 2007 3:23 pm

sunflow is interesting and I will probably play with it (I play with all the free renderers and modelers that come down the pike) as soon as I can figure it out and get the time... but what I would like to see, David, is a separate gui front-end for Inyo.

I use Cutter for editing *.ribs because it is truly excellent. I believe that Inyo is also awesome and I would like to see it as a separate tool from jPatch that can be used to render something in addition to *.jpt files.

--- Jim
"We're so sorry, Uncle Albert,
But we haven't done a bloody thing all day."
--- Paul McCartney
pndragon
 
Posts: 591
Joined: Sun Dec 05, 2004 1:27 am
Location: North Carolina

Postby dcuny » Thu Feb 15, 2007 5:47 pm

Adding a stand-alone GUI to Inyo's a good idea. I don't have one because Inyo's really only intended to support JPatch, but it wouldn't be a problem to add one.

Inyo used to have the ability to render standalone, but that was dropped a while ago. I've got no issue with adding it back in, but what format should it take? I've got a number of (broken) readers in Inyo right now -xml, obj, smf and a "generic" one that (I think) reads JPatch's output. But there's no common format that I know of that supports things like camera position, index of refraction, or things like that. Did you have any suggestions?

I like the Sunflow format a lot; it looks a lot like Yafray, and a bit like POV-Ray. It uses blocks like this:
Code: Select all
camera {
  type thinlens
  eye    -0.754123 -340.443 73.6866
  target 1.17265 -29.155 59.1488
  up     0 0 1
  fov    47
  aspect 1.333333
  fdist  320
  lensr  9
}
Objects in this format use something that looks a lot like the obj format, with a list of vertices and triangles:
Code: Select all
object {
  shader 3---Default
  type mesh
  name Sphere01
  5469 10320
  v 9.12482 -25.8656 107.225    0.19626 -0.456562 0.867775    0 0
  v 15.7221 -21.6807 107.221    0.314302 -0.3142 0.895819    0 0
  ...
  t 646 5161 2581
  t 2581 5160 646
  t 1282 5127 2581
  t 2581 5161 1282
}
I think you can also embed references to external .obj files as well. If not, there's no reason that Inyo couldn't support it.

I like this file format becauseit's easy to parse, easy to generate, and more compact than XML. I think it's more readable as well.

Thoughts?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Next

Return to Development

Who is online

Users browsing this forum: No registered users and 3 guests

cron