Hi,


I'm writing my own exporter for a renderer using SOHO.

I realized that by default SOHO translates all kinds of Houdini instances “properly” (ie. giving me the geometry every time it's needed, be it simple or per-point instancing).

However my problem is that SOHO gives me a full geometry each time, and since the renderer I'm writing for fully supports instances, I don't need geometry copies from SOHO each time (only the original geometry name and a transformation for the various instances).

Is there a flag or parameter that can change SOHO behaviour to the way I require (or is it something I have to achieve through some trickery)?


imre

tusimi
Hi,


I'm writing my own exporter for a renderer using SOHO.

I realized that by default SOHO translates all kinds of Houdini instances “properly” (ie. giving me the geometry every time it's needed, be it simple or per-point instancing).

However my problem is that SOHO gives me a full geometry each time, and since the renderer I'm writing for fully supports instances, I don't need geometry copies from SOHO each time (only the original geometry name and a transformation for the various instances).

Is there a flag or parameter that can change SOHO behaviour to the way I require (or is it something I have to achieve through some trickery)?


imre

If you look at the IFD soho files, you'll see that IFDgeo.py checks to see whether the geometry retrieved with the “object:soppath” has already been output, and thus only generates one copy of the instanced geometry.

RIB does something similar.

What renderer are you targetting?

Thanks for the hint – so far I've checked the mi exporter only, and that doesn't behave that way (I just started checking the IFD exporter, but it's a bit more complex).

The comfortable part of the SOHO behaviour is that it handles per-point instancing and per-particle instancing by default (apart from the non-instancing issue).

For me, the ideal solution would be similar to ‘single-primitive’ (e.g. sphere, etc.) export, where I get a transform matrix for each primitive. Can I achieve that somehow? (Or is it something that I can read from the IFD files, too?)

Oh, I'm working on an Arnold exporter, btw.

Oh okay, I got it, I think

tusimi
Oh okay, I got it, I think

Cool. Looking forward to seeing some results…

It's “almost ready” and works like a charm so far, (knock-on-wood) (motion blur, shading networks, image planes, etc – no proper instancing yet, though )

Houdini is great, you can create lots of geometry for Arnold to render. Looking forward to do some extreme demolitions.

Oh, btw, another question: my code is now pure python, but speed-wise it's not the best.

I managed to use the array.array python object to create C-like arrays, so I can pass data to Arnold pretty fast – but my problem is that I still have to use a python for-loop to iterate through each primitive to get the various geometry data.

What I'm looking for is a way to retrieve attributes (P, N, uv, and custom – per-point and per-vertex attributes) as arrays of some kind.

The ideal solution would be to query from SOHO with one call (say, get _all_ the per-vertex N attributes), and pass this data with one call to Arnold. But all the examples I saw so far did this with a python-loop, which can be slow for excessive geometry.

Is this possible? (Or, alternatively, I could write C++ code. But I don't know how to access soho geometry data from C++ – and I'm talking about ‘soho-partitioned’ geometry.)

tusimi
It's “almost ready” and works like a charm so far, (knock-on-wood)

Is it going to be public?

What I'm looking for is a way to retrieve attributes (P, N, uv, and custom – per-point and per-vertex attributes) as arrays of some kind.

Checkout:
hou.Geometry.pointFloatAttribValues(), hou.Geometry.primFloatAttribValues() and even faster hou.Geometry.pointFloatAttribValuesAsString() hou.Geometry.primFloatAttribValuesAsString

SYmek
Is it going to be public?

I would like it to be (my company is not against it, either – and anyhow, I worked on this in about 99% in my spare time), but the Arnold guys like to keep a tight lid on things, so it's practically up to them. If it were up to me it would be on github already – but it is not.

But there's always hope I guess.

What I'm looking for is a way to retrieve attributes (P, N, uv, and custom – per-point and per-vertex attributes) as arrays of some kind.

Checkout:
hou.Geometry.pointFloatAttribValues(), hou.Geometry.primFloatAttribValues() and even faster hou.Geometry.pointFloatAttribValuesAsString() hou.Geometry.primFloatAttribValuesAsString

Thanks, but what I'm looking for is a solution where I can access geometry that is previously partitioned by soho. The case here is that I use the sohog.partition() function (I think that's the one) to take a single /obj node and take it apart to spheres/cylinders AND polymeshes. Then I export all the spheres/cylinders as separate objects and all poly data as a single object.

What I don't know if this partitioning of geometry results in any reindexing of geometry components (say, poly vertex indices, etc), in that case I couldn't use the hou.Geometry calls.

Is it valid to use the calls you mentioned on such a geometry (result from a soho partition operation)?


imre

Btw I tried the functions you mentioned and they work, thanks a lot! Now it's literally 100x faster (which is not surprising btw, but it's good to achieve this without writing any compiled code).

(Based on my own experience as well as what I read in the other soho scripts I think it's safe to assume that geometry partitioning doesn't change point/vertex numbering.)

Could you help me out with one more thing – is there a similar way of accessing per-vertex attributes?


(p.s. I don't mean to be too dense, it's just one has to gather almost everything about soho by reading the python sources, and that can be a bit daunting sometimes )

tusimi
Btw I tried the functions you mentioned and they work, thanks a lot!

Great!

Could you help me out with one more thing – is there a similar way of accessing per-vertex attributes?

Afaik there is no vertex version of these serializing functions, perhaps because at least in H11 they would have to be heavily repacked.

In fact, I used to have the same problem writing Python module for i/o bgeo. I had to go through all polygons and iterate over vertices. Watch out for H12 though, things are changing.

Anyway, take a look on inlinecpp python module, which is very convenient (at lest on Linux) way to extend HOM:
http://www.sidefx.com/docs/houdini11.1/hom/extendingwithcpp [sidefx.com]

hth,
skk.

tusimi
It's “almost ready” and works like a charm so far, (knock-on-wood) (motion blur, shading networks, image planes, etc – no proper instancing yet, though )

Hi Imre,

Interesting thread, how do you manage to make your own shading network context in Python? Or is this bit in C++?

tusimi
Could you help me out with one more thing – is there a similar way of accessing per-vertex attributes?

i had the same problem some time ago and the fastest method i found in h11 without using the hdk is something like the following:
prims = geo.prims()
vertexAttrib = geo.findVertexAttrib(“value”)
valList =

hth.
petz

kikou

tusimi
It's “almost ready” and works like a charm so far, (knock-on-wood) (motion blur, shading networks, image planes, etc – no proper instancing yet, though )

Interesting thread, how do you manage to make your own shading network context in Python? Or is this bit in C++?

For the time being I'm storing arnold networks in a ‘Material Shader Builder’ node (vopmaterial node?), alongside with the ‘regular’ mantra nodes (you can only build from dedicated arnold nodes though, obviously). I wrote an ‘arnds’ command that builds an otl that has all available shaders within it – this is similar to the mids and rmands commands that comes with H that does the same for those renderers.

But basically I was going along the path of least resistance–I didn't spend much time (==none) to figure out if I can create an own context (or rather, an own node that can hold by own types of nodes).

Everything's in python for now. I'm staying away from C++ for as long as I can (with the aforementioned geometry functions that are able to pass mass data directly to arnold, my chances for this are _much_ better ).

As far as my experience goes with translators (this is the third I'm involved in), the most critical bottleneck you usually have is the translation of the actual mass of geometry data. So having these functions is a goodie-goodie.

SYmek
Afaik there is no vertex version of these serializing functions, perhaps because at least in H11 they would have to be heavily repacked.

In fact, I used to have the same problem writing Python module for i/o bgeo. I had to go through all polygons and iterate over vertices. Watch out for H12 though, things are changing.

Anyway, take a look on inlinecpp python module, which is very convenient (at lest on Linux) way to extend HOM:
http://www.sidefx.com/docs/houdini11.1/hom/extendingwithcpp [sidefx.com]
skk.

The reason why I don't use inlinecpp is that I didn't find any mechanism to compile-to/reuse my .so/.dll directly. It's great that it takes care of everything for you – if you have a compiler installed (which just won't happen for tens of artists with windows boxes).


@petzibaerr: Thanks, I'll have a look… Perhaps a list comprehension will be faster than a regular loop (generator functions are surprisingly fast – or, faster than I expected).

This is very interesting. I am on the arnold beta too. Marcos will surely like to hear that you have ported arnold to houdini and I guess he will gladly make this a “arnold customer open source” project

He already heard about it (one of the first things was me asking him about open-sourcing it–our studio is based on arnold now, too, which turned out to be a very solid foundation). I think he didn't like the completely open-source idea (except for customers )

They have another version in the works (being built at/by another studio, I think). Well, at the end it might even be the rare case of having an oversupply of houdini-to-arnold translators (And that's always a _good_ thing, btw)