Day One
I downloaded the Windows 32bit version of Indigo and installed it.
I'm a little familiar with how the soho code for the pipelines distributed with Houdini are layed out - it's basically:
* IFD.py - the starting point
* IFDframe.py - all the entities which are written out per frame
* IFDgeo.py - called by IFDframe generally - defines the geometry output
* IFDapi.py - ad hoc functions imported into every module
* wranglers/HoudiniLightIFD.py - functions called to define how lights get exported in IFD
My tactic is always to hack up a working pipeline to a point, and then rebuild it in the name of optimization.
I copied $HIH/soho/IFD.py to a new directory and changed it's name to indigo.py. I axed a lot of 2nd half of the code specific to Mantra - just commenting some general points. I surgically removed any other mantra-specific references.
In Houdini, used the Type Manager on the Mantra ROP to duplicate the HDA and changed the name and label to Indigo. Create an Indigo node and in the Type Properties change the name of the soho_program to point at my indigo.py instead of IFD.py. Also changed the program from "mantra" to "indigo" and such.
Hitting Render now, I am using my indigo.py script; I import hou put in some hou.ui.displayMessage()'s to see what I'm doing.
The crux of what SOHO is meant to do is it will catch anything printed to stdout and redirect it into a file. This file is then gets submitted to the the program of your choice. SOHO also assist you with a couple of other things: it determines which objects are to be output into your scene and builds a nice list so you're not responsible for re-doing this for every exporter you write - and with crazy subnets and so on, it's not an easy task. It also has a mechanism for quickly querying larges batches of parameters in the hierarchical Rendering Properties way.
Now I examine the Indigo doc pdf and load up all their test scenes (.igs) and examine the format. Its XML and seems simple enough: define a "camera", define lights of various kinds, define "material"s, define "mesh" instances and "model" which instantiate those defined by "mesh" entities. All good - nothing too confusing.
So I begin by wanting to set up the simplest scene: a triangle mesh of a box.
From the original IFD.py I see how to loop over objects and get the camera and stuff and set up quick procedures for outputting a simple camera and mesh and model definition. Unlike the IFD pipeline, I just put all the my code into the one indigo.py file until I get to a point that I might want to split it out.
I set what I can (inspecting my output .igs file) and when I'm happy I have what looks like a valid
XML file, I launch Indigo against it. It complains about all these missing entities one by one and so I substituted some hardcoded prints in there temporarily just to squeeze through Indigo's parser and start a render. It turns out that although there are defaults for many of the entities/tags, Indigo needs them defined anyway (which seems to contradict having a default in the first place, doesn't it?). This bit takes a time, hammering the output into parsable shape.
Finally, success!
Something renders... a bit of the sky! Perfect. And all I could expect given the crappy cut'n'pasted entities from various examples.
What have I learned about Indigo now:
- Triangle meshes only - no quads, polys. Boo!
- No motion-blur blocks or anything in any example or documentation.
- Needs an exhaustively set up Camera.
- Can instance geometry.
- XML format - might get large on big geo
- Can reference external .3ds, .obj and .ply geometry.
- Can read/write EXR files - goody!