Houdini to Realflow mesh .bin files

[tmdag]

Hi,

I'm posting little python otl that exports binary realflow mesh .bin files from Houdini. What for?

Houdini have much better control over fluid mesh creation then Realflow so I use it a lot. Problem was when you work with Maya/3dmax/xsi/lightwave artists, it's hard to pass them those meshes (if company don't have it's own file format).

So I have created this little python script to export bin files (and You have mesh bin importer for free for almost every 3d package from NextLimit).

Of course there is nice python .obj importer but it seems to be quite slow ( I must say that my script is not so fast when it comes to export hi detailed meshes but still should be faster then obj maya importer).

I'm digging throw HDA now and I'll update this exporter by totally compiled version or inlinecpp() functions with compiled dlls.

I needed this exporter quite quickly and still there is no 'render' button implemented (need little help with that also). To export files, use 'on the fly' function and press PLAY

http://tmdag.com/blog/?p=638

Edited September 22, 2010 by tmdag

[Ungoliant]

Great Man, your tool its our salvation

[graham]

If you are having some performance problems I definitely see places you should be able to get some pretty decent speed increases, particularly when exporting heavy meshes.

First of all, using hou.Geometry.iterPoints()/Prims() is going to be slower to iterate over large amounts of geometry than just hou.Geometry.points()/prims(). The iter methods are faster when you want random access, but points/prims is faster for straight up looping. Probably not super noticeable but every little bit helps.

Also, the way you are reading attribute values isn't very optimal. Calling hou.Point.attribValue("Cd") for example, will be slow because each time you call it Houdini has to find the "Cd" attribute and then get the value. If outside your loop you did the following it would eliminate a bunch of work Houdini needs to do. Also, you are calling the function 3 times for each point to get each component. It would be more efficient to just unpack from the value tuple to the variables or directly to your struck.pack().

p_attr = geo.findPointAttrib("P")
for point in geo.points():
    pos = point.attribValue(p_attr)
    binfile.write(struct.pack('f', pos[2]))
    binfile.write(struct.pack('f', pos[1]))
    binfile.write(struct.pack('f', pos[0]))

However, that's still not the best way to do things. Take a look at hou.Geometry.point[prim]FloatAttribValues. This will dump all the attribute values to a single tuple much faster than calling individual attribValue functions. It's a little more work to do this than normal since you are packing the values in a bit different order but it should still provide you speed improvements. Depending on your file format as well there are point[prim]FloatAttribValuesAsString which can be a bit faster than regular FloatAttribValues.

positions = geo.pointFloatAttribValues("P")
for idx in range(0, len(positions), 3):
    binfile.write(struct.pack("f", positions[idx+2]
    binfile.write(struct.pack("f", positions[idx+1]
    binfile.write(struct.pack("f", positions[idx]

These simple tweaks should hopefully give you a noticeable performance improvement, particularly with larger meshes.

Edited September 22, 2010 by graham

[shareu]

Thanks for your otls~^^

I was waiting for you RFmesh exproter otl version

[tmdag]

Wow, Big thanks graham!

I'll update in a sec

[Guest xionmark]

I'll be including a mesh writer with the new version of my plugins, they are faster being C++ based.

It looks like it will still be a while until there's a solid standard for moving data between 3D packages, so for now there's lots of hacks ... unbelievable for an industry that spends so much money on tech.

[symek]

I'll be including a mesh writer with the new version of my plugins, they are faster being C++ based.

It looks like it will still be a while until there's a solid standard for moving data between 3D packages, so for now there's lots of hacks ... unbelievable for an industry that spends so much money on tech.

Yes, pretty please Mark!

[Mamvel]

Sorry for necrophilia

tmdag, on your link there is nothing. Can you re upload, please

[Mamvel]

anybody ,please, give me little python otl

[Guest xionmark]

Yes, pretty please Mark!

Do you guys really need to have the exporter output RF mesh files? For some reason I thought FBX/Alembic, etc. formats were fairly standard now.

--Mark

[Mamvel]

in help written, that

FBX format specification generally does not support animated objects with a changing number of points or changing connectivity, such as Houdini’s particle systems or fluids. It is only possible to export these types of objects by breaking them up into individual triangles (although still within one FBX object node).

can you explain about

breaking them up into individual triangles

, please, what that means? I not understand.

I imported obj sequence to XSI, without motion vectors. And it is so stupid importer by T. Costa, which fills the entire memory, to me not need that.

Edited October 7, 2012 by Mamvel

[Guest xionmark]

Doesn't Max & XSI support Alembic now?

[symek]

Do you guys really need to have the exporter output RF mesh files? For some reason I thought FBX/Alembic, etc. formats were fairly standard now.

--Mark

Hey Mark,

thanks for asking. From my experience *.bin files stand as a last resort in exchanging issues, simply because RF format is so well established among other softwares. Is it valid in days of Alembic? Not sure how much effort it takes to keep it around for a while, but Alembic still needs a year or so to became a real standard.

Thanks for your efforts, you're man!

cheers,

skk.

[Guest xionmark]

thanks for asking. From my experience *.bin files stand as a last resort in exchanging issues, simply because RF format is so well established among other softwares. Is it valid in days of Alembic? Not sure how much effort it takes to keep it around for a while, but Alembic still needs a year or so to became a real standard.

Hmmm ... OK.

When I was at Asylum a few years ago I wrote the RWC file exporter but it ended up not being used that much (I think that's the case, not really sure honestly).

Well, I'll take a look at it over the next days or so and post how long it will take, shouldn't be terribly difficult since I've got most of the code written for RF mesh files and the H12 updates are (mostly) complete.

Take care,

Mark

[Mamvel]

Why you ignoring me? What i did badly for you? I'm still here, but you act as if I am a ghost... Why? Maybe because i'm so sad sack? And my questions are very stupid? Maybe because i'm talking with a terrible accent?

[Guest xionmark]

Why you ignoring me? What i did badly for you? I'm still here, but you act as if I am a ghost... Why? Maybe because i'm so sad sack? And my questions are very stupid? Maybe because i'm talking with a terrible accent?

We aren't ignoring you, we're trying to figure out if exporting real flow mesh files from Houdini is worth the time to write the code as opposed to using a file format that is already available.

--Mark

[Guest xionmark]

OK, so I took a quick look at the RF RWC export code and it should be pretty easy to build the RF mesh exporter.

I'll have it done by end of week and maybe sooner if I get a little extra time today/tomorrow.

--Mark

[Pazuzu]

Thank you Mark!!!

[Mamvel]

Ah... sorry, and thanks!

[Mamvel]

Guys, you know, RF plugin can exporting the mesh with random number of vertices. But that plugin, which i could get, installed, but no worked on houdini 12.1.97.

Maybe anyone can give plugin for this version?