Using Soho: Indigo Renderer Support

[kubabuk]

Hey All,

Back on track after short break, just a minor exit portals update, I was following the way Jason added meshlight parameter. So nothing fancy unfortunately. If you want to create a portal edit parameter interface of the geometry and from:

For Rendering>Indigo>Light

add Portal Toggle parameter

Changes of the indigo.ds file:

	parm {
		INDIGO_TOGGLE(i_portal, "Portal", "Light", 0)
	}

and slightly modified the meshlight section in the indigo.py

###

entityParms = {
	'i_meshlight'	:SohoParm('i_meshlight', 'bool', [0], False),
}

entityParms_Portal = {
	'i_portal'	:SohoParm('i_portal', 'bool', [0], False),
}
def outputEntity( obj, now ):
	plist = obj.evaluate( entityParms, now )

	portal_list = obj.evaluate( entityParms_Portal, now )

	if plist['i_meshlight'].Value[0] > 0:
		outputMeshLight( obj, now )

	if portal_list['i_portal'].Value[0] > 0:
		outputPortal( obj, now )
	else:
		outputModel( obj, now )

def outputModel( obj, now ):
	i_entity_start("model")
	i_comment( "outputModel: name: "+obj.getName() )
	outputTransform( obj, now )
	i_property( "mesh_name", i_safename(obj.getName()) )
	i_entity_end("model")

def outputMeshLight( obj, now ):
	i_entity_start("meshlight")
	i_comment( "outputModel: name: "+obj.getName() )
	outputTransform( obj, now )
	plist = obj.evaluate( lightParms, now )
	outputSpectrum( plist )
	outputEfficacyScaling( plist )
	i_property( "mesh_name", i_safename(obj.getName()) )	
	i_entity_end("meshlight")


def outputPortal( obj, now ):
	i_entity_start("exit_portal")
	i_comment( "outputModel: name: "+obj.getName() )
	outputTransform( obj, now )
	i_property( "mesh_name", i_safename(obj.getName()) )	
	i_entity_end("exit_portal")

###

I believe you can merge entityParms_Portal and entityParms and use them in the one plist, but at this point I didn't want to mess up to much.

Feel free to improve it.

cheers

kuba

Edited April 14, 2008 by kubabuk

[Jason]

Thank Kuba, when I get a chance I'll roll this in:)

[Jason]

Updated to v0.4: Indigo v0.4 on the Exchange

0.4 - 15 April 2008,

- Added check for bad shader assignments- or regular Houdini shaders being assigned. These will show up RED in renders.

- Modified run_indigo.py to accept -o arg for output filename. Now "ip" renders to default Indigo destination.

- Added Exit Portal support by way of a property "i_exit_portal" (Thank you Kubabuk on odforce.net!)

- Added IES support to MeshLights (untested)

- Misc parm fixes (Thanks vmuriel on odforce.net!)

- Added Crop Window support. Please note that it works well only with Linear Tonemapping.

Still no partitioning yet, unfortunately.. but enjoy anyway.

[spev]

Hey Chaps

Thought i would have a look at this renderer...have a slight issue or two first If i use the indigo win version under wine on my system (linux fc7 gcc4.1) I get an error saynig

IndigoDriverExcep: Scene must contain at least one light source.

Fatal Error: IndigoDriverExcep: Scene must contain at least one light source.

but i do have an indigo light in the scene...Plwease tell me what I am missing..

Also I tried to install the 32bit linux version and get the error

Fatal Error: Mismatch between the program and library build versions detected.

The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6),

and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).

but I have the following vers of the libraries installed

gtk2.i386 2.10.14-4.fc7 installed

wxGTK.i386 2.8.4-3.fc7 installed

Any help would be gratefully appreciated

Thanks

[kubabuk]

but i do have an indigo light in the scene...Plwease tell me what I am missing..

That's why you need to put indigo light into your scene. In the shape tab you can set Area shape to Skylight to figure out if indigo starts anyway. I haven't tried indigo on linux yet.

You can also try to render one of the test scenes placed in C:\indigo_x64_v1.0.9_2\testscenes (in my case) to see if indigo starts.

kuba

[spev]

I did have an indigo light...just changing it to environment got it to start rendering and then when I changed it back to rectangle it also now rendered.

Ta for the help

quote name='kubabuk' date='Apr 15 2008, 02:02 PM' post='46474']

That's why you need to put indigo light into your scene. In the shape tab you can set Area shape to Skylight to figure out if indigo starts anyway. I haven't tried indigo on linux yet.

You can also try to render one of the test scenes placed in C:\indigo_x64_v1.0.9_2\testscenes (in my case) to see if indigo starts.

kuba

[vmuriel]

Indigo has Z up axis, Houdini is Y up.

That issue affects to the sky position,

see my attachment in Indigo forum:

http://www.indigorenderer.com/joomla/forum...&highlight=

[kubabuk]

yup, it's true I thought Jason fixed that in the recent release but, haven't checked that one yet.

looks like the values are swaped

i_propertyV("sundir", (plist["skylight_sundir"].Value[0],plist["skylight_sundir"].Value[2],plist["skylight_sundir"].Value[1] ) ) #swap y&z for z-up coords

I can hardly recall, after playing with the axes remember I had at some point sun shining form the bottom. Assuming the geometry is also rotated to fit indigo's layout, maybe sun is rotated the other direction... well not sure about it...

The other thing is that you are not allowed to use negative numbers on vertical axis in indigo, so there is not easy way to flip the sun. In this situation you need to probably transform all of the geometry to mach sun position...

Let's wait for Jason to see what's his point about it.... :coffee1:

Edited April 21, 2008 by kubabuk

[vmuriel]

A not definitive fast fix is

line 283 in indigo.py

---> objMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident))

change:

---> objMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident)) * hou.hmath.buildRotate(90, 0, 0)

Now, rotate the camera

line 151 in indigo.py

---> camMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident))

change:

---> camMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident)) * hou.hmath.buildRotate(90, 0, 0)

[Jason]

A not definitive fast fix is

line 283 in indigo.py

---> objMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident))

change:

---> objMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident)) * hou.hmath.buildRotate(90, 0, 0)

Now, rotate the camera

line 151 in indigo.py

---> camMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident))

change:

---> camMatrix = hou.Matrix4(obj.getDefaultedFloat('space:world', now, _ident)) * hou.hmath.buildRotate(90, 0, 0)

If we do this, I guess we'd have to set the x,z,y order in the sundir parm to x,y,z?

[Jason]

Updated to v0.5 on the Exchange: http://www.sidefx.com/exchange/info.php?fi...p;versionid=495

0.5 - 21 April 2008,

Added partitioning to split up geometry based on shop_materialpath attribute values - meaning that you

can assign SHOPs to individual polygons and SOHO will split the object into seperate indigo objects on

the fly.

Added vmuriels fix for rotating the camera and universe to a z-up representation.

I'll go about explaining the partitioning code tomorrow

[kubabuk]

Big Thank You, Jason!

[vmuriel]

Changes for Parse error while parsing integer from '640.0' error with Indigo Linux native version:

lines 382 - 388

rendererCameraParms = {
	'cropl'	:SohoParm('cropl', 'real', [0], False),
	'cropr'	:SohoParm('cropr', 'real', [1], False),
	'cropb'	:SohoParm('cropb', 'real', [0], False),
	'cropt'	:SohoParm('cropt', 'real', [1], False),
	'res'	:SohoParm('res', 'real', [(640,480)], False),
}

changes:

rendererCameraParms = {
	'cropl'	:SohoParm('cropl', 'int', [0], False),
	'cropr'	:SohoParm('cropr', 'int', [1], False),
	'cropb'	:SohoParm('cropb', 'int', [0], False),
	'cropt'	:SohoParm('cropt', 'int', [1], False),
	'res'	:SohoParm('res', 'int', [(640,480)], False),
}

--------------------------------------

lines 436 and 438

		i_property_in_entity( "y1", (1.0-cam_plist['cropt'].Value[0]) * res[1] )
		i_property_in_entity( "y2", (1.0-cam_plist['cropb'].Value[0]) * res[1] )

changes:

		i_property_in_entity( "y1", (1-cam_plist['cropt'].Value[0]) * res[1] )
		i_property_in_entity( "y2", (1-cam_plist['cropb'].Value[0]) * res[1] )

[vmuriel]

Partitioning works like a charm !

[Jason]

Partitioning works like a charm !

Thanks for the 'res' fix:) But are you sure about the cropl/r/t/b being int types?

Btw. I really appreciate the testing and fixes you guys are providing!

[Jason]

So:

Partitioning

What is partitioning? Renderers support a lot of features and attributes on various degrees of granularity; some are only applicable to the entire per-render session (such as "resolution" and "output filename") and some are applicable at the per-object level (such as "transform"). At the per-primitive level this list get smaller - usually the only common denominator is point attributes, such as "normal" - which is really a standard geometric attribute. Some renderers, like Mantra for instance, can support varying the shader binding (shader assignment and unique parameters) per primitive. However this list is smaller than we'd all really prefer - we'd all prefer to be able to specify all available attributes all the way down to primitive if we want to, and it's pain to remember which renderer supports what attributes at what level of granularity, not to mention very inconvenient workflow-wise if we're rendering with multiple renderers. Partitioning is SOHO's solution to allowing the the geometry to be split into entities compatible with any candidate renderer.

In Indigo's case, it cannot define assign shaders to individual primitives in a single object, so we want to "partition" the geometry into separate objects on the fly and assign unique shaders to each partitioned piece of geometry. The task here is to split an object's geometry up based on every unique value of the attribute "shop_materialpath" - the attribute which contains the path to the SHOP.

It was all nice and convenient before when we had only a single shader per mesh, and only one "model" which applies the object-level attributes to that mesh. This one-to-one behaviour was quite neat. Now if we choose to partition on shop_materialpath, we might end up partitioning into many meshes, all of which should inherit the same "model" attributes. The idea here is that as we're outputting the meshes for each object/model, we partitioning them with the handy-dandy SOHO function, in brutally trimmed code:

	soppath = obj.getDefaultedString("object:soppath", now, [""])[0]   #get soppath for an object
	geo = SohoGeometry(soppath, now)	# grab geometry
	parts = geo.partition('geo:partattrib', "shop_materialpath")   #partition the geo on unique "shop_materialpath" values
	for part in parts:   #loop through all partitions
		name = i_safename("%s%s-mesh"%(obj.getName(),part))  # generate a unique name for this mesh now that it might be several chunks
		writeGeometry( parts[part],  part )  # write the geometry, using shader binding info

So looking at this snippet, you'll notice that the sohogeo.partition() function returns a hash on unique keys for shop_materialpath along with a handle to the geometry belonging to the that unique key. Very easy, really. In the Indigo code there is some more checking for valid shader bindings and so on.

There are more ways to split geometry up - by primitive group and by a "list", which is quite general mechanism where the user can define how to split up geometry. If you look at OGL.py, you'll see that OpenGL cannot support NURBS, Open- or Closed Polygons in the same object, so the geometry is quickly analyzed and a list is built. The geometry is then conveniently partitioned based on this list. Of course you could analyze the geometry and export it yourself carefully but the partitioning code allows you to abstract it one level further and you can rely on SOHO to do the hard work of partitioning for you.

In a high-end render like Mantra there might be quite a few potential partitions per object. Attributes like "displacement bound", "back-face culling" and such are all really per-object attributes which you can now assign to primitives individually (by way of a Properties SHOP assigned by a Material SOP) and SOHO will partition based on all these permutations. The entire intent here is to allow the artist to assign attributes anywhere they might see fit and instead do the hard work upon translation.

Please scan through $HFS/houdini/soho/soho.doc for a brief explanation and look at OGL.py, Indigo.py and such to try to grok the beast further.

Take care,

Jason

[vmuriel]

Thanks for the 'res' fix:) But are you sure about the cropl/r/t/b being int types?

Sure, parse error with real type.

Btw. I really appreciate the testing and fixes you guys are providing!

Thanks to you for your work and partitioning explanation.

[Jason]

Hey all,

Are there any features that you'd like to support in Indigo next? I realize there are a couple of holes currently, but was wondering if people were waiting for anything in particular?

[kubabuk]

Hey all,

Are there any features that you'd like to support in Indigo next? I realize there are a couple of holes currently, but was wondering if people were waiting for anything in particular?

Well, yes...

Basically Indigo allows you to load another igs file during the render time. What would be very handy is:

1. ability of generating geometry with materials assigned to it to the separate igs file

2 load it back to the main scene as a proxy object.

The main reason is to create ready made objects you can put in your scene and do not bother about tweaking any settings. The other advantage is saving on memory in the main file. It other words it is nothing new just a straightforward copy of vray proxy object concept.

The other thing which comes to my mind is a instancing. I know Indigo has this feature, but no idea how to use it yet.

Anyway my 2 cents, looking forward for others' suggestions...

cheers all

kuba

[kubabuk]

Greets all,

Added export checkbox for igi files in the output tab - I was using it recently a little bit with "violet". Btw, it's a shame you can not specify a path for igi files and exrs. All of them are saved in indigo/renders folder.

Added a couple of existing lines from the files to help tracking the line placement, to keep things clear.

indigo.ds file:

 parm {
	INDIGO_TOGGLE(i_save_igi, "Save Indigo Image (.igi) file", "Output", 0)
	}



/*
 *  Define parameter lists
 */	

			parmtag	{ spare_parmlist "override_resolution i_super_sample_factor i_image_save_period i_picture i_halt_time i_samples_per_pixel i_pixel_filter i_bidirectional i_auto_choose_num_threads i_num_threads i_max_change  i_save_untonemapped_exr i_save_tonemapped_exr i_save_igi i_disablecrop i_metropolis i_logging i_strata_width i_white_balance i_tonemapping_method i_tonemapping_linear_scale i_tonemapping_reinhard_prescale i_tonemapping_reinhard_postscale i_tonemapping_reinhard_burn" }

indigo.py file:

rendererParms = {
'save_igi'	:SohoParm('i_save_igi', 'bool', [0], False),
}


	# output all renderer_settings globals
	i_propertyBool('save_igi',		 plist['i_save_igi'].Value[0])

Jason can we change the output names of saved exrs? Can you control the padding, or is this weird numbering id done internally by indigo? This naming is a pain when it comes to load a sequence.

cheers,

kuba