SOHO - modify geometry?

[Stalkerx777]

Hi guys! So here is the problem. I need to compute some data and store it as primitive attributes.The simplest solution would be to put digital asset in each geometry object, but i want this to be done at IFD export time. So in the end, every geometry object should have this data in IFD.

I started with writing IFDHook function ("pre_geometry"), where i get access to geometry, and compute my stuff. But after some research, i figure out, that there is no way to modify SohoGeometry, it has read only access.

SohoGeometry.save(), emits original houdini geometry into stdout stream.

Then, in IFDgeo.py in method saveRetained() there is a call to objectWragler, and there is a NOTE:

"Call the object wranglers 'retainGeometry', skip inbuilt soho code if it returns True. Note. It's the responsibility of object wrangler to emit IFD correctly."

So, i can write my wrangler, and emit data to IFD by myself, but I think it is not a very good idea to implement such a thing in python. There should be a performance hit.

Any help on this? Maybe i do something wrong, and there are more elegant solutions.... !?

Best regards.

Alex

[nord3d]

Hi!

May be I misunderstand something, but why it can't be done just like this:

[lukeiamyourfather]

I think it would be best to do this in SOP land based on the render flag per network (add whatever nodes downstream automatically). Save the scene as an alternate when being submitted to the render farm so if the scene is foo_v034.hip you could save the altered version as foo_v034_render.hip or depending on the queue manager just submit a temporary file with the altered SOP networks and leave the original as is. I think Deadline works this way, actually sending a scene file for the job instead of using the live one on the network. That way there's no craziness for creating the IFD and the SOP networks for artists don't get cluttered with stuff in every network. There are probably a thousand ways to address the problem but that's where I'd start.

Edited November 12, 2012 by lukeiamyourfather

[petz]

i guess the most straightforward and somplest way to modify geometry at rendertime would be a program procedural if you don´t want to do it in sops. you just need to write a small standalone program adding your attributes to bgeos comming from stdout.

hth.

petz

[Stalkerx777]

Thx for replys, but i wouldn't start this thread if i need SOP based solution. I need a couple of attributes to be computed on every geometry object, for shading purposes .There could be hundreds of objects.So i'd like to do this in IFD generation time.

In Renderman, there is RiFilter..... witch is good for such type of tasks. In mantra there is Python Filters, but it seems they can only modify render properties, and can't access geometry...

Anyway, i'll keep my research...

Edited November 12, 2012 by Stalkerx777

[symek]

There could be hundreds of objects.So i'd like to do this in IFD generation time.

Mind the cost of that process. Soho isn't any good at heavy tasks. Processing of hundreds of objects may take a while. Petz suggestion sounds promising to me too, although you could try some dirty work in Soho, like pre-processing networks triggered very early by soho to add attributes you wish. We do this here often, but this is possible because renderfarm takes a copy of a hip file, which may be modified (embedding hdas is another example).

In Renderman, there is RiFilter..... witch is good for such type of tasks. In mantra there is Python Filters, but it seems they can only modify render properties, and can't access geometry...

Don't let me start on this. Currently IFD is such a pita, and perhaps the biggest drawback of Mantra. Needs rewrite.

[Stalkerx777]

i guess the most straightforward and somplest way to modify geometry at rendertime would be a program procedural if you don´t want to do it in sops. you just need to write a small standalone program adding your attributes to bgeos comming from stdout.

Hm, sounds like a solution. So i can write procedural ( not even standalone program ) witch will do all the stuff....

although you could try some dirty work in Soho, like pre-processing networks triggered very early by soho to add attributes you wish.......

Szymon, could you explain a little bit on this? What can i do in soho to add attributes? Hooks didn't work for changing geometry. Only objectWrangler...... and that is pain in the ass......

[petz]

Hm, sounds like a solution. So i can write procedural ( not even standalone program ) witch will do all the stuff....

well, actually you could write a procedural but that´s not what i meant. program procedural is a geometry shader that runs an external program before mantra reads the ifd. so, the only thing you need to write is a callable program running by the shader which will add your attributes to incomming geometry at rendertime.

petz

[lukeiamyourfather]

...and there are more elegant solutions.... !?

Thx for replys, but i wouldn't start this thread if i need SOP based solution...

Well, you did ask. I guess we have differing opinions on what is elegant.

[symek]

Szymon, could you explain a little bit on this? What can i do in soho to add attributes? Hooks didn't work for changing geometry. Only objectWrangler...... and that is pain in the ass......

Well, I didn't mean anything magic, just use whatever means to alter geometry at soho run-time. Gdp itself is read-only, but that's not soho specificity, across whole Houdini, gdp is read-only whenever its owned by Sops, but not if they are stand-alone (sourced from disk or merged from sops). So monkey patching I meant, like changing saveRetained() so that instead of SohoGeometry.save(stdout), you first copy gdp, then you can freely alter it and and emit to stdout. Not very elegant but automatic .