Jump to content

Houdini to Realflow mesh .bin files


tmdag

Recommended Posts

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

Screen-shot-2010-07-17-at-10.26.39-AM.png

Edited by tmdag
  • Like 2
Link to comment
Share on other sites

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 by graham
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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! :)

Link to comment
Share on other sites

  • 2 years later...
Guest xionmark

Yes, pretty please Mark! smile.gif

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

Link to comment
Share on other sites

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 by Mamvel
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...