Sunflow Renderer

Ideas, enhancements, feature requests and development related discussion.

Postby sascha » Wed Feb 21, 2007 9:33 pm

Hey, Rob... animation files can be saved in JPatch 0.5.3_x too! :)
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Feb 22, 2007 11:07 pm

I've posted the source code of my changes here: sunflow_patch.zip. Here's the README file:
Code: Select all
The following files are needed for JPatch to use Sunflow:

\src\org\codehaus\janino
   Janino source files, not included
   http://www.janino.net/
   
\src\org\sunflow
   Sunflow source files, not included
   http://sunflow.sourceforge.org/
   
src\jpatch\boundary\settings\RendererSettings.java
   Added SUNFLOW to the enumerated platforms
   
src\jpatch\boundary\settings\RendererSettings.java
   Sunflow specific settings
   
\src\jpatch\images\prefs\sunflow.png
   Sunflow icon
   
\src\jpatch\renderer\AnimationRenderer.java
   Handle rendering via Sunflow

\src\jpatch\renderer\SunflowRenderer.java
   Code to generate a Sunflow scene file
There are a couple of issues with the code:
  • It doesn't remove the scene files after it creates them.
  • The intensity settings of the lights needs to be scaled properly.
  • It should call Sunflow as an external program, instead of including all the Sunflow source. I didn't do this because it wanted me to set various settings (i.e. for X11 on Linux) that I didn't want to deal with).
  • To properly integrate Sunflow into JPatch, instead of generating a scene file, the scene should be directly passed to the SunflowAPI object. It's actually prettty trivial; you can simply replace the scene file code with the equivalent code that the parser sunflow\src\org\sunflow\core\parser\SCParser.java generates. For example, here's the code that generates the sunsky in SunflowRenderer.java:
    Code: Select all
             // set the sunsky
             float turbidity = Settings.getInstance().export.sunflow.skyTurbidity;
             int skySamples = Settings.getInstance().export.sunflow.skySamples;
             Vector3f sunVector = new Vector3f(light.getPosition());
             sunVector.normalize();
             
             // create a sunsky
             String sunDir = toSunflowTuple(sunVector);
             file.write("light {\n");
             file.write("  type sunsky\n");
             file.write("  up 0 1 0\n");
             file.write("  east 0 0 1\n");
             file.write("  sundir " + sunDir + "\n");
             file.write("  turbidity " + turbidity + "\n");
             file.write("  samples " + skySamples + "\n");
             file.write("}\n\n");
    Here's the code that parses in SCParser.java:
    Code: Select all
       } else if (p.peekNextToken("sunsky")) {
                p.checkNextToken("up");
                api.parameter("up", parseVector());
                p.checkNextToken("east");
                api.parameter("east", parseVector());
                p.checkNextToken("sundir");
                api.parameter("sundir", parseVector());
                p.checkNextToken("turbidity");
                api.parameter("turbidity", p.getNextFloat());
                if (p.peekNextToken("samples"))
                    api.parameter("samples", p.getNextInt());
                SunSkyLight sunsky = new SunSkyLight();
                sunsky.init(api.getUniqueName("sunsky"), api);
            } else
                UI.printWarning(Module.API, "Unrecognized object type: %s", p.getNextToken());
            p.checkNextToken("}");
    So the replacement code would be:
    Code: Select all
       // set the sunsky
       float turbidity = Settings.getInstance().export.sunflow.skyTurbidity;
       int skySamples = Settings.getInstance().export.sunflow.skySamples;
       Vector3f sunVector = new Vector3f(light.getPosition());
       sunVector.normalize();
             
            api.parameter("up", Vector3(0, 1, 0););
       api.parameter("east", Vector3(0, 0, 1););
            api.parameter("sundir",api.parameter("east", Vector3(sunVector.x, sunVector.y, sunVector.z));
       api.parameter("turbidity", turbidity);
       api.parameter("samples", skySamples);
       SunSkyLight sunsky = new SunSkyLight();
       sunsky.init(api.getUniqueName("sunsky"), api);
    I didn't do this, because I don't know if Sascha is willing to include Sunflow in JPatch, or if it's going to be an external renderer. (That, and I didn't know I'd have issues calling Sunflow externally, and I was too lazy to figure it out. ;)). It certainly would be nice to have Sunflow integrated, because it's got a fast preview mode (IPR) that would be useful if it were integrated in.
Anyway, let me know if there are any issues with this. If someone wants to take this project over, that's fine with me. If it's OK to include Sunflow into JPatch, I'll make the changes myself.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Thu Feb 22, 2007 11:19 pm

Cool, I'll have a look at it.

I've tried out Sunflow with the demo scenes the other day, but I found that it's rather slow (at least on Linux). I'll have to try it on Windows for comparison.
I found it strange that it uses the server-VM - in all my experiments the server-VM was a lot slower than the client-VM for typical client applications. I actually have no clue about the difference, but I could imagine that the server-VM is optimized for headless server environments (no GUI) and lots of threads, while the client-VM is optimized for graphical applications with just a few threads running (I'll have to check if I can find any documentation about this).

Personally I never had any performance troubles with Java on Linux - to the contrary, some graphics operations seem to be faster than on Windows (which is very likely a driver issue and not a Java problem).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Thu Feb 22, 2007 11:50 pm

I've also found Sunflow doesn't seem to perform as well under Linux, although I haven't done any solid testing. It's a bit odd. It does seem to start up a number of threads, since it doesn't immediately stop rendering when you click the cancel button.

I haven't tried it head to head with Inyo yet, mostly because I haven't figured the proper scaling for lights from JPatch to Sunflow. I can't seem to get point lights working at all. I should post the question on the Sunflow board. :?

The spherical lights are equivalent to Inyo's (i.e. Inyo treats any light with a radius greater than zero as a spherical light, otherwise it's a point light), so there's some basis of comparison there.

The material settings don't map directly to those in JPatch. There are three different types of materials in Sunflow: diffuse, shiny and glass, so I map to different types based on the material attributes. I don't think that's a big issue, though.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri Feb 23, 2007 12:15 am

I took a look at the Sunflow forum; they're moving to phpBB in the next couple of days.

The pointlights use a physically correct falloff, so the value's got to be really cranked up if the lights are far off. For example, in the aliens.sc file that's included, I removed the sunsky and changed the spherical light to a point light.:
Code: Select all
light {
  type point
  color 1 1 1
  power 40000000
  p -800 -400 500
}
Inyo also has the option of having physically correct falloff for the lights, but by default, I don't think it uses it. You can see why. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Fri Feb 23, 2007 11:09 am

Browsing through the Sunflow source, I found a fake global intensity setting. It's a cute cheat that Peter Shirley pointed out, where you can fake GI when calculating the ambient lighting by comparing the surface normal's direction to the primary light's direction. If the normal points to the light, a "light" color is used, otherwise, a "ground" color is used (both supplied by the user). Here's an example of the syntax:
Code: Select all
gi {   
    type fake % fake global illumination
    up 0 .2 .8 % "up" vector direction, pointing to the light
    sky .9 .9 1 % sky color
    ground .2 .2 0 % ground color
}

In this example, there are no lights in this scene - all the illumination is faked. I'm actually using negative color values for the ground to get dark shadows:
Image

This is a more typical example. The "sun" isn't directly overhead, and the ground color contributes a positive amount. It's overlit, but I'm too tired to futz with it:
Image
It's a cool little fake, and very cheap. (I'm always interested in ways to get faster renderings cheaply). It's definitely something I need to add to Inyo. :D
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Fri Feb 23, 2007 3:36 pm

Yes, I've thought about this too. It should be trivial to create such a "surface-normal dependent" ambient light in RenderMan or GLSL.

To make the sceen look more realistic one could use ambient point lights in addition. They'd have a position, a falloff parameter and perhaps a "sphere of influence" radius and would simply affect (raise or lower) the ambient light level in their vicinity. It should also work with spot-lights, and they could be colored as well.

All computations are even simpler than with real point-lights - all you need is the distance to such an ambient lightsource (and the vector in case of a spotlight), but this is needed for "real" lightsources anyway.
It could also be combined with real lightsources - just add an ambient color term to the lightsource to affect the ambient channel. IIRC OpenGL has this built in.

This would suggest a light-model with these components:
* ambient color, ambient intensity, ambient falloff
* diffuse color, diffuse intensity, diffuse falloff
* specular color, specular intensity, specular falloff
For each channel, colors and intensity would be premultiplied. Falloff could ehter be "none", "linear" or "quadratic" (quadratic is physically correct). Alternatively it could be a user configurable exponent.

Diffuse and specular contribution can be computed e.g. using the Phong model and added to the diffuse and specular channels of the surface respectively (just as always).
Ambient is scaled using intensity and falloff and then simply added to the ambient channel of the surface.

To optimize the code, it could skip the diffuse and/or specular computation if the intensities are 0.
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby rjh » Fri Feb 23, 2007 7:05 pm

WOW! Sorry for the long pause between replies... I stay away for awhile an activity abounds!!!

Hey Dave,

"It sounds like you're playing with the JPatch source"

No ... just the GUI. Jpatch nicely places the lights as the first component within the "WorldBegin" / "WorldEnd" tags. Lights can exist either inside or outside the "WorldBegin" / "WorldEnd" tags, but geometry (i.e.: Arealights) has to be within the "WorldBegin" / "WorldEnd" tags. I use the light properties dialog to specify Arealights and their geometry and the required GI Renderman calls (I also use the light properties dialog to specify pointlights, spotlights, and pointlight arrays of up to 100 pointlights - very long render times).

I am in the midst of a BSIT degree, and we have "touched on" programming, but not as in depth as is required for this project. I will have a look at what you have done and see if I can glean a useful understanding from what you have done. Hopefully I can contribute on that level.


Hey Sascha,

"Hey, Rob... animation files can be saved in JPatch 0.5.3_x too!"

Can I get this version from the archives? I would love to play with the bones more than I have. As it is, I have devised serveral techniques to work with morphing only (with dozens of characters and props "rigged" with morphs), and have several tutorials in their rough form describing how to animate with the older version, but have not offered them due to the dufferent direction the modeler is taking. I currently have a short all but finished (98%) with this technique, and several others in different stages of completion. I'll share more soon about those.


And I see even more has been discussed as well !!!

I will wade through it all and see if I can offer any insight.

Rob

P.S.: I am very excited about this project for many of the reasons David pointed out earlier. The "hook" Jpatch has for me is that I can intuitively animate with the morph only version very fast once the characters have been rigged, and the rib output is consistent and "tweakable". I am going to take a longer look at the 0.5.3_x this week.
rjh
 
Posts: 179
Joined: Thu Dec 30, 2004 10:33 pm

Postby sascha » Fri Feb 23, 2007 8:09 pm

The latest 0.5 version with the animator included was this one:
http://jpatch.com/temp/jpatch0.5.3_02.jar

Beware, undo/redo support is broken in the modeler, but the animator should work. So I'd recommend 0.4 for modeling, maybe 0.5.2 for rigging and this one for animating :?

When I have more time I'll maybe fix the worst bugs of this release, so you'll have at least a usable patch-modeler/animator (although I can't fix all the bugs, that's one reason for the rewrite).
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby rjh » Fri Feb 23, 2007 8:23 pm

Hey Sascha,

The latest 0.5 version with the animator included was this one:
http://jpatch.com/temp/jpatch0.5.3_02.jar

I will grab that one and give it a try and let you know how it goes.

Beware, undo/redo support is broken in the modeler, but the animator should work. So I'd recommend 0.4 for modeling, maybe 0.5.2 for rigging and this one for animating

I will go with that work flow ... as long as I have a clear path that I know works and gives me the results I am expecting.

When I have more time I'll maybe fix the worst bugs of this release, so you'll have at least a usable patch-modeler/animator (although I can't fix all the bugs, that's one reason for the rewrite).

Goodness! I am going to have to have more children ... I already promised David that my next male child would bear his name. Now I have to have another so I can name his Sascha

=>

Good stuff guys ... good stuff ...

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

Postby dcuny » Sun Feb 25, 2007 11:23 pm

In a response to my questions in the Sunflow forum, Christopher suggested that embedding Sunflow was probably the best way to go. He suggested that this would be particularly useful for subdivision surfaces.

I agree, so I'm going to go ahead and change the code to work directly with the SunflowAPI object, instead of writing to an external file. I might also have a look at the preview code, and see if there's a way to get it working interactively with JPatch.

I found a couple images of hairballs posted on the Sunflow site. I've got to get back to my hair code at some point.

One of the things that's really got my interest is the upcoming Janino shaders. In theory, lights and materials can be interactively compiled into Sunflow, so you could create JPatch/POV-Ray compatible lights and materials using Janino. That would make transitioning away from Inyo much simpler, because I could (in theory) just port Inyo's features over to Sunflow.

The impression I get is the Janino is faster than Beanshell, but I really don't follow this sort of thing that closely.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Mon Feb 26, 2007 10:17 am

I've updated the Sunflow exporter so that it writes directly to Sunflow, instead of creating an intermediary file. You can find it here: sunflow_patch2.zip

Let me know if there's any questions about it. Corrections, feedback, and offers to take this project over are appreciated. ;)
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby sascha » Mon Feb 26, 2007 11:38 am

The impression I get is the Janino is faster than Beanshell, but I really don't follow this sort of thing that closely.

That's for sure. Janino is a compiler, while beanshell is an interpreter.

While beanshell is fine to do typical script jobs (e.g. parsing configuration files, constructing some complex objects and passing them to some API, etc.), janino "functions" or "expressions" can be used in performance critical parts (e.g. in shaders).

Janino compiles java sourcecode to java bytecode, so janino generated code will run equally fast as any other java code. It not only allows to compile (and link!) at runtime, you can even compile single functions or even expressions and evaluate them directly - with no performance drop, everything is still compiled bytecode (which in fact is compiled to native machine code by the JVM).
I plan to use Janino for expression evaluators in the constraint system of the animator. Among some prefedined constraints (aim at, move like, etc.) you'll be able to write your own constraints.

Beanshell on the other hand is an interpreter. It reads the source files, interprets them, and uses reflection to access the APIs.

This is not inteded as a rating. Both Janino and BeanShell are great tools and have there legitimate uses.

Note that for my Inyo "shader" support beanshell is only used to construct the "shader" object. During the shader execution beanshell is not used!
sascha
Site Admin
 
Posts: 2792
Joined: Thu May 20, 2004 9:16 am
Location: Austria

Postby dcuny » Mon Feb 26, 2007 4:44 pm

Thanks, that clears things up a lot. :)

Art of Illusion has a GUI for building dynamic shaders, and I wondered how they were able to get decent performance with it. Now I know.
dcuny
 
Posts: 2902
Joined: Fri May 21, 2004 6:07 am

Postby dcuny » Mon Feb 26, 2007 5:54 pm

Sunflow only supports physically plausible lights, and I think JPatch exports Inyo lights as having no falloff. When Janino support is added, I should be able to add custom lights via the pluging system. In the meantime, I'll look into creating a custom light class with no falloff as well as quadratic falloff, so it'll be easier to compare Sunflow and Inyo renders.

Sunflow offers in-camera motion blur with camera movement. I think it also offers in-camera motion blur with moving objects. If that's the case, I'll look into adding support for that as well, to see what the render times look like. Assuming JPatch supports returning sub-frame triangle positions... I don't have the code handy at the moment.
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