Jump to content
gramx

Per-Frame Alembic export

Recommended Posts

Thanks for your feedback Gram.

 

i don't know how alembic work exactly but

- it really shine to spot / optimise / avoid redundancy of information,

- this is why the intend philosophie of .abc is to be a ONE mesh file

- .abc sequence is imo a hack and a bypass of this initial philosophie but it also work

 

For size comparision try this

- convert your sequence in .vrmesh make the sum of the size of each file

- convert your sequence as a ONE mesh .abc in Ogawa

- compare both size if you tell me that the sum of vrmesh is lighter than the .abc i would be surprise

 

For the speed that couldn't be more logic, you give to vray what it excpect to render without the need of any extra operation !

 

That's good to know that this workflow work in "reality" :) thanks !

Edited by sebkaine

Share this post


Link to post
Share on other sites

150 frame Ogawa single .abc      =  14.5 gig

150 frames vrmesh sequence     =    6.5 gig

150 frames bgeo sequence         =  15 gig

 

This is a meshed fluid so the topology changes every frame. The vrmesh must have some extra compression.

 

G

Share this post


Link to post
Share on other sites

very interesting gram , this could mean that .abc really suck for mesh with per frame topology change.

what is also interesting is that i doesn't do any better than .bgeo

 

for each export you don't have apply a smooth subdiv operation on the mesh ?

this could lead me to think that for big FLIP export , choosing the native renderer format is the most efficient choice ?

 

i wouldn't think that .abc would do that bad ... especially in ogawa ...

 

it could be interesting to test how .bin handle this.

you just have to subscribe for a trial

http://www.realflow.com/try/

 

then download the Max Plugin + Houdini Plugin no need for realflow.

you have a .bin exporter node in houdini 

and a .bin reader node in max

 

if you have the time to check i would be curious to see how it handle things compare to .abc

 

as a side node .bin is a pretty locked format you can't add custom var like in .abc

http://support.nextlimit.com/display/rfrk/The+Channel+Concept

Edited by sebkaine

Share this post


Link to post
Share on other sites

The convert vdb mesh I am exporting has 2.5million polys, so no need to subdivide it any further.

 

It looks like there isn't any compression going on in the alembic output.

 

I think your right that the native renderer format is the most efficient choice for a changing topology mesh. I am going to switch over to .vrmesh from now on. When I get time I will test with just particles to see if that also works.

Share this post


Link to post
Share on other sites

.bin is not only a particle format you can also export a mesh. That's the mesh exporter that would be interesting to compare.

 

in max you also have frost that could be worth a try

http://www.thinkboxsoftware.com/frost/

 

you would only export particles and mesh in max. i have never use it but it's also an option that could worth a try ... i have heard good thing about it.

Share this post


Link to post
Share on other sites

Not sure if it's mentioned somewhere in here, but you can set up ply2vrmesh in the GEOio table. I think you have to spool to $TEMP first because ply2vrmesh doesn't work with stdin natively, and then start you can start loading and saving .vrmesh format directly within Houdini.  If you need more help on the syntax, I can help you out further a little later.

  • Like 2

Share this post


Link to post
Share on other sites

I would be very interested by a detail description of the process Jason. Writing .vrmesh directly from houdini would be a killing features.

 

Thanks ! :)

Edited by sebkaine

Share this post


Link to post
Share on other sites

Yes, I second that! It would save having to convert all the files again after exporting :)

Share this post


Link to post
Share on other sites

ROP output driver SOP : myalembic.$F4.abc

and read it back with an alembic SOP 

  • Like 1

Share this post


Link to post
Share on other sites

.sc format looks good for compressing bgeo files

 

I originally tried exporting myalembic.$F4.abc from the alembic ROP driver, but this didn't work. Just tried it with a standard ROP output driver and it does work! :)

 

Cheers

 

Graham

Share this post


Link to post
Share on other sites

seq.$F4.bgeo.sc is the new H14 way.

 

Guys i didn't get what is this one ?

 

You can load this as a vrmesh directly ? What's the point of .bgeo.sc instead of .bgeo ?

Gram have you suceed to write directly .vrmesh outside of houdini without the conversion step ?

 

Thanks ! :)

Edited by sebkaine

Share this post


Link to post
Share on other sites

No, I can't write vrmesh's directly from Houdini yet.

bgeo.sc is a faster compression format and replaces bgeo.gz

these can't be converted by ply2vrmesh

Edited by gramx

Share this post


Link to post
Share on other sites

Thanks Gram ! so the working workflow is still

- outpout to .bhclassic

- then convert directly .bhclassic to .vrmesh  ?

Share this post


Link to post
Share on other sites

Yes, that's correct!

 

I'm still hoping Jason will post his setup to output directly from Houdini though.

 

G

  • Like 1

Share this post


Link to post
Share on other sites

Hi Graham, i did an script to do exactly that in my last work, we had to render in maya and the houdini caches was super crazy size, and this script write a abc per frame, you can create a self button you only need copy/paste the python code and thats all.
https://dl.dropboxusercontent.com/u/30398202/alembic_shelf_ivanpulido.rar

 

send me an email, for the password.

ivanpulido7@yahoo.es

Cheers.
Ivan

Share this post


Link to post
Share on other sites

Hi Ivan

 

Thanks for your post, it appears that you can write per frame. abc files with a standard ROP output driver, instead of the alembic ROP.  output: "myalembic.$F4.abc"

I have tested this and it seems to work for now! I will email you if I run into any difficulties.

 

Thanks

 

Graham

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×