Using Soho: Indigo Renderer Support

[kubabuk]

Oh one thing,

Do you think the units describing dimension of the rectangle light are the same as houdini's. I don't know how to check this at the moment (I did it only by eye) but the grid with the dimensions 0.25x0.5 is different size than the light of the same dimensions. I might be wrong thou, I will take a close look at it this evening.

[kubabuk]

A few light tests done in indigo... manually splitting objects into partitions is a little bit cumbersome, but can live with it for now.

[Jason]

Oh one thing,

Do you think the units describing dimension of the rectangle light are the same as houdini's. I don't know how to check this at the moment (I did it only by eye) but the grid with the dimensions 0.25x0.5 is different size than the light of the same dimensions. I might be wrong thou, I will take a close look at it this evening.

Hmm, it seems to right according to the Indigo Manual PDF. For safety's sake, I could still wrap it in a soho.houdiniUnitLength() function, but I think it's correct. Please let me know what you find!

width

Width in x direction.

type: real scalar

units: meters

Quite honestly I don't know what it's meant to look like because the rectanglelight entity only supports and "pos" positional element, no rotations, etc. So I don't know how you're meant to orient the rectangle as no orientation information gets passed to the IGS.

This is the example from the Manual:

<rectanglelight>
 <pos>0.0 0 1.9</pos>
 <width>0.2</width>
 <height>0.2</height>
 <spectrum>
  <peak>
   <peak_min>300</peak_min>
   <peak_width>550</peak_width>
   <base_value>0</base_value>
   <peak_value>200</peak_value>
  </peak>
 </spectrum>
 <efficiacy_scale>
  <power_drawn>100</power_drawn>
  <overall_luminous_efficiacy>17.5</overall_luminous_efficiacy>
 </efficiacy_scale>
</rectanglelight>

[Jason]

A few light tests done in indigo... manually splitting objects into partitions is a little bit cumbersome, but can live with it for now.

Ah yes, the partitioning thing is what I'll look at next then.

Perhaps Houdini might one day sport a tool to Split Objects by selection, groups, connectivity - and to Combine object too. Maybe by version 13 or something... I can dare to dream.

[kubabuk]

Quite honestly I don't know what it's meant to look like because the rectanglelight entity only supports and "pos" positional element, no rotations, etc. So I don't know how you're meant to orient the rectangle as no orientation information gets passed to the IGS.

Yes you're right, in that case you shouldn't bother about that. Funny, I can bet the last time I rendered camera pointing the rectangular shape light I could see the light in the render, right now no light at all.

Also don't know if this only is an issue on my machine but once I create indigo light, I can't see its graphical representation in 3d viewport, the same happens with camera but it looks more like some houdini problems.

[kubabuk]

I did some tests with render region (manually modifying igs file, for now) very handy when doing quick tests on your scene, bare in mind it works properly with linear tone mapping method only. Would be great if you could include that in the next update, When it comes to portals, before I'll try to add them I am afraid have to study soho more...

Btw. Meshlights works just perfect!

kuba

[kubabuk]

There is a potential problem with materials and a floating bundle chooser, which puts only the name of the medium's name in the required field. Indigo requires to have /shop/material_name - otherwise it produces an error.

Also I am getting an error if there are any non-indigo materials in the scene.

kuba

[vmuriel]

Yes, meshlights are fine.

I am testing Indigo4Houdini ( Houdigo ) in Linux environment, one tip for this

platform: Comment camera aperture staff in indigo.py

	# aperture stuff
#	i_entity_start('aperture_shape' )
#	i_entity_start(plist['i_aperture_shape'].Value[0])
#	if plist['i_aperture_shape'].Value[0] == "image":
#		i_property_in_entity("path",plist['i_aperture_shape_image_path'].Value[0])
#	elif plist['i_aperture_shape'].Value[0] == "generated":
#		i_property_in_entity( "start_angle",plist['i_aperture_shape_generated_start_angle'].Value[0])
#		i_property_in_entity( "blade_offset",plist['i_aperture_shape_generated_blade_offset'].Value[0])
#		i_property_in_entity( "blade_curvature_radius",plist['i_aperture_shape_generated_blade_curvature_radius'].Value[0])
#		i_property_in_entity( "num_blades",plist['i_aperture_shape_generated_num_blades'].Value[0])
#	i_entity_end(plist['i_aperture_shape'].Value[0])
#	i_entity_end('aperture_shape' )

For Linux the last Indigo version is 1.0.1 (64 bits), I think it dont support camera aperture staff.

Animations

Jason, I have replaced os.system by os.popen in run_indigo.py for make animations.

This way force to Houdini to wait for Indigo in each frame.

Is easy to add a render param to indigo rop called filename (for example)

and pass it as argument to run_indigo.py file.

Later use it, with -o indigo switch, for save your frame render in that file.

Edited April 4, 2008 by vmuriel

[Jason]

For Linux the last Indigo version is 1.0.1 (64 bits), I think it dont support camera aperture staff.

Ah yes - I'm going to have to have a closer look at the "skipdefaults" idea where, if you have read a parm and its set to default values that it'll skip ever writing the parm into the IGS stream. So this means that if you don't add the extended aperture parms and modify their values, they won't appear in the IGS. This should make IGS files lighter and support optional blocks.

<bitch>

One thing I find disturbing about Indigo's XML reading strategy is that it chokes on unsupported entities... which is meant to be one of the gigantic benefits of XML. It should ignore unknown/recognized entities. Currently its quite fussy version-to-version about what entities and attributes appear, making support a bit of a pain. Also, it should internally fill out missing attributes - for example, if you specify an RGB Spectrum element and don't supply a gamma it complains bitterly when it should just populate it with the default value it mentions in the Manual.

</bitch>

Animations

Jason, I have replaced os.system by os.popen in run_indigo.py for make animations.

This way force to Houdini to wait for Indigo in each frame.

Is easy to add a render param to indigo rop called filename (for example)

and pass it as argument to run_indigo.py file.

Later use it, with -o indigo switch, for save your frame render in that file.

Cool, yeah - could you paste the modifications into a codebox so I can see what you did?

My secret hope is that Indigo will one day be able to be piped to, and that the output filename becomes a parameter in the IGS... then we can get rid of most of this crap.

And thank you and Kuba for mucking with this:) Its cool to see it being used!

[Jason]

There is a potential problem with materials and a floating bundle chooser, which puts only the name of the medium's name in the required field. Indigo requires to have /shop/material_name - otherwise it produces an error.

Also I am getting an error if there are any non-indigo materials in the scene.

I'll look into these, thanks Kubabuk!

[Jason]

I did some tests with render region (manually modifying igs file, for now) very handy when doing quick tests on your scene, bare in mind it works properly with linear tone mapping method only. Would be great if you could include that in the next update, When it comes to portals, before I'll try to add them I am afraid have to study soho more...

Render regions would be easy indeed, I'll add them toot-sweet!

[kubabuk]

Render regions would be easy indeed, I'll add them toot-sweet!

Can't wait for the update! I'm so excited about Indigo. I have switched from Maxwell recently, which indeed has some nice features, but on the other hand seems to be so difficult to work with, it is simply much less flexible then indigo.

Jason, quick question, probably not only me will have some questions about this soho bindings, should I post all of my newbie questions here or maybe we could create another sticky thread, if you don't mind?

My first issue with soho is that, I can't see a new parameter I created in the indigo.ds file. After editing that file should I call it somehow in houdini. As far as I understand you create some custom parameters in indigo.ds, apply to any object in houdini, and send them using indigo.py to soho which does the rest of the job and creates exprted file. Correct me if I am wrong?

thanks

kuba

[kubabuk]

Ok I solved it, the edited file wasn't sourced, - to many copies of the same asset on my machine

[kubabuk]

Ok I messed up something I added the new parameter to Indigo.ds file

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

Then I started modifying mesh light and obviously something went wrong, now the mesh light is overritten by the standard diffuse material... Can't figure out where the problem is...

entityParms = {
	'i_portal'	:SohoParm('i_portal', 'bool', [0], False),
}
def outputEntity( obj, now ):
	plist = obj.evaluate( entityParms, now )
	if plist['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 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")

[vmuriel]

#!/usr/bin/python
import sys
import os


# Indigo 
#
os.chdir( "/home/vito/renders/indigo_v1.0.1/" )
indigoexec = "/home/vito/renders/indigo_v1.0.1/indigo_console"


# Temp path
#
tempdir = os.environ.get('HOME')+"/temp/"
tempfile = tempdir + "temp.igs"Filepath


# redirect out
#
old_stdout = sys.stdout
sys.stdout = open(tempfile,"w")

for line in sys.stdin:
	print line.strip()

sys.stdout.flush()


# restore standard output
#
sys.stdout = old_stdout


# concat out png
#
if len(sys.argv) > 1:
    tempfile = tempfile + " -o " +sys.argv[1]


# exec Indigo and wait
#
os.popen( indigoexec + " " + tempfile )

Very hardcoded to my workstation, but the idea is there.

I have deleted first argument ingido path.

Added new param to indigo rop

myFilename = /home/vito/renders/indigo_v1.0.1/renders/frame.$F4.png

Modify Command

Command = python $HOME/houdini9.1/scripts/python/run_indigo.py `chsop("myFilename")`

Edited April 5, 2008 by vmuriel

[vmuriel]

No more indigo.py modifications, Indigo 1.0.9 for Linux is here

http://www.indigorenderer.com/joomla/forum...opic.php?t=3942

[Jason]

Can't wait for the update! I'm so excited about Indigo. I have switched from Maxwell recently, which indeed has some nice features, but on the other hand seems to be so difficult to work with, it is simply much less flexible then indigo.

I did this change at home - and was surprised to see that if I made my crop region smaller, there was more energy in the scene! I've never rendered with crops with Indigo before; is this an artifact of something I'm unaware of - like the reinhard tone mapping, or is it a bug in Indigo?

The attached images are identical except for the crop region changed. Any ideas?

EDIT

Yup, it was the Reinhard tonemapping. It is steady with Linear tonemapping, but I'm still trying to figure out decent values for some of these settings... for instance, if I use a Background Light with RGB spectrum of 1,1,1 along with "Linear Tonemapping", the Linear Scale must be set to 2000000 to look decent!

[Jason]

No more indigo.py modifications, Indigo 1.0.9 for Linux is here

http://www.indigorenderer.com/joomla/forum...opic.php?t=3942

Aw, this doesnt run at work (Suse 9.3, gcc3.3)

Thanks for the code snippets, I'll work them in over the next few days:)

[Jason]

Jason, quick question, probably not only me will have some questions about this soho bindings, should I post all of my newbie questions here or maybe we could create another sticky thread, if you don't mind?

Thats a good idea, lets post standalone questions in a new thread

My first issue with soho is that, I can't see a new parameter I created in the indigo.ds file. After editing that file should I call it somehow in houdini. As far as I understand you create some custom parameters in indigo.ds, apply to any object in houdini, and send them using indigo.py to soho which does the rest of the job and creates exprted file. Correct me if I am wrong?

You have to restart Houdini in order see your new parameters appear in the Edit Rendering Parameters dialog, I'm afraid. I don't even think the hscript command "dsreload" will reload the SOHOparameters.ds, but I could be wrong about that; I haven't tried it.

If you've added your new parm to the default_output and are expecting your parameter to be created by default the next time you make a ROP, it'll only work if you haven't made a single change to the OTL indigo.otl. I've found that the instant you modify the OTL, the Create Script in the ROP has the "opproperty ..." line in it replaced by a hardcoded list of parms in the form of an "opspareds" command (See this earlier post) which is incredibly annoying, forcing you to crack the damn thing open again with "hotl -x"/"hotl -C" just to restore the previous behaviour.

Cheers,

Jason

[vmuriel]

Changes in indigo.py for Indigo version 1.0.9_2 (linux x64)

Original:

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

'super_sample_factor' :SohoParm('i_super_sample_factor', 'real', [2], False)

'num_threads' :SohoParm('i_num_threads', 'real', [1], False)

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

change real by int

new:

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

'super_sample_factor' :SohoParm('i_super_sample_factor', 'int', [2], False)

'num_threads' :SohoParm('i_num_threads', 'int', [1], False)

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