I have known about sunflow for quite a few years, and one night got the idea that my XSI luxrender exporter might easily be cannibalised to export a new ascii scene file format for sunflow.

Sunflow is written in Java and seems to have been developmentally dormant since 2007. The extensible oo Java core would’ve been interesting if I’d had the gumption to learn Java and read the source, but due to relapses of Internets Disease and Taurean couch-potatoism I lost interest and moved on. (I think revisiting Shadow Of The Colossus in hard mode had something to do with it too)

Take a look at sunflow’s feature list here.

Here are pictures from the development of the plugin:
(Most recent renders first)

And the first pixels rendered with the exporter:

details

I wrote the exporter mainly to see what the built-in hair primitve was like, and if I could easily export ICE strand particles to it. Its object instancing was also a motivation; it’s so easy to create thousands of particle instances in interesting arrangements using ICE.

Sunflow’s speed was pretty much on par with luxrender, but sunflow has a gnarly progressive-render mode (-ipr cmdline flag) which is a real bonus for rapidly tuning shaders, composition and lighting. I wonder what it’d be like if my exporter was written in C and hooked into XSI’s custom renderer mechanism, set to be in live IPR mode.

Like luxrender, the most mature 3d exporter is available for Blender. Yay for FLOSS.

There’s also cool stuff available for users of Processing¹to export to sunflow here.

Miga’s XSI sunflow exporter

Michael Gangolf wrote a sunflow exporter for XSI years ago.
It can be found here.

1. Processing: let me take this oportunity to soapbox that “Processing” is an annoyingly generic name for an application to search for on teh googles.

A budding audio-visual artist, he’s already experimenting with plugging tv cables into the wrong ports and ‘improving’ the colour balance. Buttons of any sort, attached to any appliance, are a constant source of entertainment.

We spent the day riding diesel trains along the south coast, eating fish and chips, playing in sand and travelling through a sunny countryside.

I hope the chooks don’t get cocky enough to jump the planter and gobble up all of our salad leaves!

1. summer solstice holiday: otherwise known in the Southen Hemisphere as Beermas, Festivus or Boxing Day Cricket Test Holiday

I made a renderer of sorts using ICE.
I was preparing some compounds to do world-to-screenspace stuff in ICE when I thought I’d give this a try. I wanted to see if I could use a screenspace grid of particles, set to fit in the camera fustrum, to shoot rays and gather info from geometry in the scene in a view-centric way.

It was so easy that I extended the idea to see if I could render an image, through ICE, from data gathered from the scene like a raytrace renderer would.
It’s not a raytracer implemented in ICE maths: it uses the factory Raycast node to do all the geo-ray interesections.  I was more interested in seeing if I could use the raycast pointlocators to do some classic 3d shading stuff.

My approach was to generate a grid of points in the space of the camera’s view, shoot rays out against the geometry in the scene, store some basic render-state variables to the cloud, and then use the state variables to colour the points as if they were fully shaded samples.

1 - making a screen-space cloud grid

I used a Model > Get > Primitive > Point Cloud > Grid to make a grid of points.
Some trig on the camera’s fov, and a matrix mult by the camera’s global transform then transformed the grid into the perspective-space of the camera.
I added controls for dealing with grid subdivisions and camera aspect to keep the grid fitting the frustum perfectly, and a control for defining the depth from the camera of the screen-space cloud.

2 - using the grid to raycast into the scene

Now that I had the world-space points fitting to the camera, I could cast rays against a geometry group to gather data and store variables.
I stored the intersected location (world-space, stored as gatherP) and the geometry normal at the intersection (world-space, stored as gatherN). I could then show the particles projected onto the scene.
I made a switch so that it wasn’t necessary to have the points projected out onto the scene for the system to work; I could also leave them at the camera-driven screen plane.
Having gatherP stored, it was then easy to make the first bit of shading. Simple depth from camera: (the points here are sitting on the screen plane)

Following naturally was camera-space normals as a function of gatherN and the camera’s orientation:

I made controls for making sure that particles’ Scales and Sizes (with the Rectangle particle Shape) were updated as a function of cloud grid subdivisions, camera fov, camera aspect and depth from camera. The particles appear to retain their size when viewing through the camera, no matter what their depths are from camera. Good ol’ Tan.

3 - colouring the particles (shading)

3.1 - lighting

Classic Lambert illumination.

I brought in a null’s transform to pose as a lightsource and to make a light direction (L) vector for gatherP. The dot product between gatherN and L creates the illumination model (Lambert).

Using another Raycast setup, I generated a raytraced shadow from the lightsource (using the lightsource null). Multiplying the light colour and adding ambience completes the basic model.

3.2 - ambient occlusion

Using gatherP and gatherN, I used Raycast in a loop to do some ambient occlusion (multiplying the ambient colour before adding to the other lighting). It’s pretty slow but it totally shows the idea.

Here’s a Vimeo of it all in action

(can’t see video? click through..)

download

I’ve made a model (.emdl) for download that contains all the ICE trees and shows the system updating. There is a DisplayInfo property on the pointcloud that has some controls expressioned into the ICE trees.

This whole thing was a brief throwdown of an idea, so the ICE trees are only roughly commented, and the maths is pretty loose, but it shows how it works. Probably the most complicated stuff in there are the few matrix-mults I had to use to transform vectors into the camera’s perspective and global transforms.

1. look through the camera iceShadingRenderer.Camera.
2. important: the system does not update in playback mode. Play with it parked on a single frame.
3. the ray_group contains the geometries to trace against (but I had some update trouble when I added or removed objects: I had to create new geometry access nodes and re-hook them up each time).
4. move the lightICE null around to see the lighting update.
5. ambient occlusion samples are controlled on the DisplayInfo PPG on the particle cloud.
   

download iceShadingRenderer.zip

(121kb, made with XSI7.01)

please let me know if there’s a problem with the download.

Particles have a repulsive force, and try to align themselves to their neigbours’ rotation.

download alignmentPatterns.zip

(141kb, XSI .emdl format, made with XSI7.01)

Some flame fractals as hightfields:

For a while I was interested in making a curve geometry macro:

Some disk-packing tests (I remember making a grid-based partition scheme for speeding up neighbourhood tests, yet the second image took 21 hours to pack, before reaching the bailout! Ridiculous! povRAY sdl is very slow) :

Parameterised packing:

Isosurfaces. From memory, I think these are scaled and rotated voronoi structures:

Each lightgroup is written to a buffer that the GUI allows you to balance seperately while lux is rendering.

’skylight’ lightgroup:

‘golem¹’ lightgroup:

combined:

luxrender lightgroup GUI:

1. golem: the one from Jewish folklore, not Lord of the Rings

Most of these renders took hours to converge. The render times takes me right back to the old days of raytracing before maths coprocessers. It’s nice to know that my box is spending all its spare cycles computing deluxe, multiple-bounce radiosity for hours on end while I’m at work.

Unused cycles are a travesty.

Here are some results of the exporter at various stages of development. (Most recent renders first)

the first pixels rendered from my exporter:

the exporter

I started with a hack-job of a script to write luxrender scene files just to see what luxrender was like. I’ve since re-written the exporter twice because the results have been so promising.

I am unlikely to release the plugin any time soon. I have many more lux features to support before I release it, but one day, I’d love for other people to have a go with it. Even then, people would have to understand that it’s written in python.  And that it’s slow.  And that it slowly eats spare cycles for breakfast.

OMNOMNOM.

luXSI

For those that wish to play with XSI and luxrender right now, Michael Gangolf wrote the original XSI-to-luxrender exporter, luXSI, available here. His exporter is written in C and is a billion times faster than mine.

I came across povRay v1.0 on a coverdisk for UK PC Format magazine in 1993.  (And subsequently, via local dialup BBS, its powerful sourcecode ancestor DKBTrace)

.. I still have the magazine right here in my book shelf.

These renders are from about the year 2000. (That doesn’t sound quite as futuristic as it used to, eh?)

I can’t guarentee that potatoshop wasn’t used to post-process these renders.

The goldfish image is a frame from a looping animation that I exported from XSI to povRay with a VBscript I wrote.  Maybe I should rehash the povRay exporter in python? For teh lulz?

The anisotropic-shaded Utah teapot was rendered with a crazy povRay patch called povMan that supported a very limited subset of Renderman SL.

Gilles Tran’s povRay renderings and story telling were a massive inspiration during my povRay years.  He also co-authored the very first image to be raytraced while orbiting the earth in the International Space Station!

Read about the first image to be raytraced in space here.