Sunflow Renderer

Ideas, enhancements, feature requests and development related discussion.

Postby sascha » Thu Feb 15, 2007 7:57 pm

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.

Well, I'd say that XML is a lot easier to generate and to parse (and there are a lot of standard tools and libraries). Compactness is relative, as the file size doesn't matter for small files, and large files should be zip compressed (I guess that with zip compression all ASCII representations will have approximately the same size).

I agree that the format you suggested is more readable (for humans), and if it's intended to be used like POV-Rays scene description language that's a clear advantage.

I like XML because, with a little care, it's easy to add new features to your files while maintaining back- and forward(!)-compatibility.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby pndragon » Thu Feb 15, 2007 9:13 pm

dcuny wrote: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.

This is my personal choice, too, just because it is more user friendly. And I don't want to code each vertex by hand if i can avoid it... Just about every modeller allow you to export .obj files.

Laziness is the father of invention...
sascha wrote:Well, I'd say that XML is a lot easier to generate and to parse (and there are a lot of standard tools and libraries). Compactness is relative, as the file size doesn't matter for small files, and large files should be zip compressed (I guess that with zip compression all ASCII representations will have approximately the same size).

I agree that the format you suggested is more readable (for humans), and if it's intended to be used like POV-Rays scene description language that's a clear advantage.

I like XML because, with a little care, it's easy to add new features to your files while maintaining back- and forward(!)-compatibility.

These are both good arguments. Would it be possible to allow the user to set a preference of some kind...

--- Jim

P.S. This part of this thread should probably get moved to here.[/url]
"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 9:20 pm

pndragon wrote:P.S. This part of this thread should probably get moved to here.
Yeah, I'll continue Inyo-specific things on that thread. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Thu Feb 15, 2007 9:42 pm

sascha wrote: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).
Noise is always and issue with anything that uses monte carlo sampling. But there are various ways to keep the variance down, and other ways to filter out noise. (Check out Statistical Acceleration for Animated Global Illumination at the Pixar papers site for one clever method). But the proof is in the pudding, and the best way to see is to try it out. There are a couple of videos on the Sunflow gallery page. I had to convert them using Bink because Quicktime for Windows wouldn't render them properly, but they look noise-free to me. There is an issue with the edges of the walking character looking jagged, but that's probably an export issue, not one of noise.

So, is it feasible to use a GI renderer to render HD animations?
I think so, depending on the GI method that you're using. For example, this release has a new method for sampling area lights, so I know he's focusing on getting a cleaner image. The real question is probably whether the GI renderer run fast enough to be useful for animation.

I played a bit more with Sunflow on my Linux box. I'm guessing that Chris is a Windows coder, because the experience is generally better under Windows. Under Linux, I couldn't get the shell script to run properly, and had to run it from the command line. Sunflow complained that I gave it less than 1 Gig of memory (!), and that I didn't have the -server set, so it was likely to run much slower than was optimal.

It (like all raytracers), it does take a while for a large image to render in Sunflow. For the examples I posted, I cut the image size down to about the sized I've been rendering using Inyo. I had also reduced the sampling size from 32 samples/pixels to 16 samples/pixel. It adds a bit of grain to the image. Playing with an animation would answer a lot of questions.

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.
Great! I'll try to hack together a simple exporter this weekend (probably only supporting basic colors and a diffuse shader) and see if I can get anything useful out off it.
I agree that the format you suggested is more readable (for humans), and if it's intended to be used like POV-Rays scene description language that's a clear advantage.
For the Dancing with Moai animation, I used Papagayo to do the lipsync. Their file format was plain text, and very readable. It was particularly easy to cut and paste from that format into JPatch's XML format.

When I started playing with Sunflow, I popped open the example scene files and saw stuff like this:
Code: Select all
image {
  resolution 340 280
  aa 1 1
  samples 4
  filter gaussian
}
I felt very comfortable fiddling with the various parameters. You can do the same thing in XML, but I think it's just a small fraction less user friendly.

One interesting thing that Sunflow appears to have done is embedded the .obj format into their file format. This is clever, because it allows you to cut and paste together a file from an existing .obj file, without having to create a visual editor to do it. :)
I like XML because, with a little care, it's easy to add new features to your files while maintaining back- and forward(!)-compatibility.
I made a mental rule to use XML, just because it's the standard. But I've never used a proper XML parser, so I've never really taken advantage of XML in that regard. If an element is missing from the expected sequence, I just throw an error.

It's not really any more or less difficult to code one way or another. If there's ever any real demand for XML output, I can go that route.

One of my motivations for playing with Sunflow was to see how quickly the tubes primitive rendered. I'd like to export some of my furballs to Sunflow and see what they look like.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Feb 15, 2007 10:37 pm

Code: Select all
image {
  resolution 340 280
  aa 1 1
  samples 4
  filter gaussian
}

Yes. That's easier to read and write than
Code: Select all
<image>
    <resolution>340 280</resolution>
    <antialias>1 1</antialias>
    <samples>4</sample>
    <filter>gaussian</filter>
</image>

or alternatively
Code: Select all
<image>
    <resolution width="320" height="240" />
    <aa x="1" y="1" samples="4" filter="gaussian" />
</image>

The nice thing about POV-Ray is that it has some "high-level primitives" (spheres, cylinders, cones, etc.), supports GSC and has a macro-language. This way it actually is possible to code complex scenes in SDL by hand. It's clearly impossible to code triangle meshes by hand, so importing geometry from a simple, ascii based geometry format like off or obj makes a lot of sense*.

But this also means that the file-format we're talking about will only be used to describe renderer parameters (resolution, antialiasing, etc.) and perhaps shaders. POV-Rays material and texture commands are quite powerful, but not nearly as flexible as RenderMan Shader-Language or even OpenGL SL.
Writing a GUI to control the renderer parameters should be straightforward. A GUI shader builder is more difficult to develop, but would be a nice thing too.
So the question is - who will use the ascii based Inyo input format? If the files are to be generated by (yet to be written) GUIs, I'd go the XML route. If they are meant to be hand-edited, I'd use a POV-Ray like format. But keep in mind that XML maps nicely to object-graphs, so a "shader" built with a GUI tool can be easily exported to XML, no matter how its OO-design looks like. If you design your own "shader language", you'll have to be very careful to not introduce unnecessary limitations.
But I've never used a proper XML parser

Note that Apaches Xerces parser has been included into Java 1.5 - no need to download or install it separately anymore. And using SAX to parse documents is pretty simple.

*But note that you'll need (per vertex) at least position, reference-position, texture-coordinates (u/v) and the surface-normal. I don't think that .obj can do this, but a workaround could be to store reference-geometry and the transformed model in separate files. Nevertheless you might want to pass additinal per-vertex information to the renderer (both, RenderMan and OpenGL can do this), so I think you'll eventually end up creating your own geometry file-format.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Feb 17, 2007 7:56 pm

I'm trying to set up the camera parameters for Sunflow. It expects the following block:
Code: Select all
camera {
  type <type=thinlens, pinhole>
  eye    <x> <y> <z> -- eye position
  target <x> <y> <z> -- "look at" object
  up     <x> <y> <z> -- up vector
  fov    <field of view>
  aspect 1.333333
  fdist  320 -- only with thinlens?
  lensr  9 -- don't know what this is yet
}
I can use camera.getPosition() to get the eye position, but what about the lookAt vector? Can I call camera.getOrientation() and then use the x, y and z values, or is there another way to get this? :?
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sat Feb 17, 2007 9:06 pm

Doesn't it support a matrix definition for the camera, like POV does?
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sat Feb 17, 2007 10:22 pm

It (probably) does from the internal interface, but from the external interface, it expects those vectors.

I can always punt and just use (0,0,0) to get something working, and worry about it later.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Sun Feb 18, 2007 12:12 pm

I haven't tried this and I'm almost sure that there's a simpler solution, but anyway:

* Take JPatch's camera transformation matrix.
* Create a new Point3d object (0,0,0) and transform it with the camera matrix. This should yield the cameras position.
* Create a new Vector3d(0,0,1) and transform it with the camera matrix. This should yield a direction vector. If you need a look-at point, add the position from the previous step to this vector.
* Create a new Vector3d(0,1,0) and transform it with the camera matrix. This should yield the up vector. Normalize it if Sunflow expects normalized vectors.

You may have to use the inverse camera matrix, and maybe (0,0,-1) as a basis to get the direction - as I said, I haven't tried it so you'll need to experiment a little :)
Note that points are not vectors, so it's important to use a Point3d instance for the position and a Vector3d instance for the vectors.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Sun Feb 18, 2007 2:46 pm

After way too many hours of hammering on the code, I've finally got Sunflow rendering images. :D

It only took a couple of hours (interrupted by making the kids breakfast, etc.) to get the glue code working. But when I went to call Sunflow, it complained that I hadn't set up the X11 environment variable properly. Even through Sunflow has an option to render without a display, since it's an option, Java needs the information.

I figured that this sort of thing would make it entirely unportable, so I dropped the Sunflow code into JPatch. That wasn't too painful, but it wanted Janino as well. Oh, well... I may as well keep bloating the JPatch source. There were a few classes that wouldn't compile, but I could run it under Eclipse. Wonderful.

Well, not really. It didn't seem to want to render anything. Lots of bug fixes later, I finally got a legal Sunflow file parsed, and a black image generated.

More head scratching, and finally I started getting some images. But control of the camera wasn't working properly. I fiddled with this and that... I could get the camera to mostly, but not quite work. Late into the night, I finally figured out that Sunflow has the x axis flipped around. :x

Image

Most of the renderings are using the IPR option, which is pretty low-res, but fast. It's a good thing, because I had to render lots and lots of frames to figure out what was going on. :roll:

Once that was done, I had to come up with unique names for objects and their materials. I had initially used model.getName(), but that returned the name of the model from the Model view, not the Design view. Another hour of my life, down the drain. ;)

There are a couple of things still not right, like the aspect ratio and the relative brightness of lights. All lights are currently point lights. Sunflow supports spherical lights, but again, I need to calibrate the relative brightness. The command line output from Sunflow should also be captured; I don't know how to do that, either.

I'm getting images to render, but they're way too bright. I don't see any setting for adjusting the f-stop... :? Here's a render with the "quick gray renderer", which isn't as quick as one might hope:

Image

Playing with turbidity should do the trick... Render, render, render... No, wrong settings... Render, render, render...

Gah, I can't seem to fix it. Oh, well... Here's an earlier image I had rendered:

Image
Must... get... sleep...
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sun Feb 18, 2007 9:12 pm

I figured out the problem... I was mixing Color and Color3f without scaling them properly. So, for example, the ground plane would be fine because it was a Color ranging from (0..1), but Color3f ranged from (0.255). As usual, it was something I had already "fixed", but removed when I got confused between the two types. :?

It takes about 4 minutes for a 200x200 image to render with a sunsky in the scene. No doubt it would be faster if I set up the Java VM parameters correctly - on my Windows machine, it runs a lot faster.

Pretty picture time (still not balanced correctly):

Image

I'm also cutting and pasting values for the sunsky from example files; I doubt the camera's facing in the right direction. It would be cool to play with focal distance a bit.

From playing around with it the other day, my impression was that most of the "cool" factor that I saw was from the sunsky lighting the scene. I've been considering adding something similar to Inyo for a while. Since I've pretty much worked through my fear of matrices, I don't really have much of excuse for not implementing it. ;)

IPR is still spiff, and it would be nice to have "live" feedback from JPatch. As I mentioned, I've got it currently built into Inyo, it's just a matter of figuring out how it's going to work.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Sun Feb 18, 2007 10:58 pm

While Googling around, I ran across the code for the Blender exporter. They do a nifty trick where the "Sun" light is set to the sunsky. So I copied the idea, and the light named "Sun" provides the location of the sun. So now I've got control over the actual position of the sunlight. :)

How does the aspect ratio get calculated? Is it aspectWidth / aspectHeight, or is it (aspectWidth * ImageWidth) / (aspectHeight * imageHeight), or something else? :?

Hrm... Sunflow's got a toon shader, too. Lots of goodies under the hood.

Now that it's working, I need to export some furballs and see how they render.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Wed Feb 21, 2007 10:02 am

rjh wrote:Hey Dave ... an exporter for Jpatch ? Could it be used to test some animation ? I would love to test such a feature and see Sunflow's animation viability.
Yeah, it works with animation. It still needs a little bit of work - the lights aren't exported at the proper power level, and I haven't tested transparent or reflective objects yet. It also doesn't calculate the proper field of view. Here's a couple of shots. This is the Preferences panel:
Image
If you want to use the Sunsky, just name one of the lights in your scene "Sun". It'll use the direction of the light for the sun's direction as well.

Here's a scene rendered using IPR:
Image

Here's the same scene rendered using the regular Bucket renderer:
Image
For reasons I mentioned earlier in this thread, I've embedded Sunflow into JPatch. It shouldn't be hard for Sascha to add it into the official version, if he's so inclined. It's just a handful of files, plus the Sunflow source.

If Sascha would rather be able to call Sunflow externally, someone would have to figure out how to properly set environmental variables. It's not a difficult thing to do, I just don't have the expertise to do it. :?

I've pretty much hacked apart the version of JPatch on my machine, so I'm a bit concerned about distributing it. I suspect it wouldn't build properly anyway - I've been running it from Eclipse.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby rjh » Wed Feb 21, 2007 5:41 pm

Hey Dave,

"Yeah, it works with animation"


My hat and most of everything else I have on is off to you

=o

Don't try to visualize this, you will go blind

=>

I am using to following version of Jpatch:
JPatch 0.4 PREVIEW 1 compiled Mon May 9 17:00:10 2005

You may ask yourself why I am using this older version, and my answer would be:
1.) rib export is consistent with the changes saved from the Modeler module (i.e.: shader assignment to specified surfaces)
2.) I have many models "rigged" using the morphing tools available and the effects are satisfactory
3.) Animation files can be saved

All this preamble to ask the following question:
Will / can / could your Sunflow exporter work with this version? If the answer is "yes" or even "possibly", then my next male child will be named David.

=>

I have been able to tweak the Animation export properly and have gotten arealights / gi working w/ bmrt, but the flickering (i.e. inconsistency between frames) is unacceptable as well as the looong render times. I have a couple of projects that require this look, and i really like the Sunflow speed and results (forgive me oh Renderman deity).

Rob
rjh
 
Posts: 179
Joined: Thu Dec 30, 2004 10:33 pm

Postby dcuny » Wed Feb 21, 2007 9:06 pm

rjh wrote:My hat and most of everything else I have on is off to you
*Shudder*
I am using to following version of Jpatch:
I don't think there's anything special that's preventing the exporter from working. Keep in mind that GI (which is why you would want to use Sunflow) is pretty slow. I guess the point of writing an exporter is to let you decide if it's fast enough, right? ;)

If the answer is "yes" or even "possibly", then my next male child will be named David.
Wow, that's some offer. My wife wouldn't let me name any of my children "David" - not even the boys!
I have been able to tweak the Animation export properly and have gotten arealights / gi working w/ bmrt, but the flickering (i.e. inconsistency between frames) is unacceptable as well as the looong render times.
It sounds like you're playing with the JPatch source. Would it be OK if I zipped up just the files you needed and posted them? You'll also need to include a couple of other projects in your source - I'll include information on those as well.

Sound like a plan?
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 2 guests

cron