jason_slab Posted June 3, 2010 Share Posted June 3, 2010 (edited) It's always a trade-off to do this in SOPs or in Mantra. Generally water is made to be reflective and refractive. That means raytracing. Mantra in it's current form would be forced to build the entire mesh in these instances in one go before the render started. The Particle Fluid Surface SOP is currently multi-threaded in latest latest builds of H10.0 so you could build an Asset and wrap it up in to an otl on disk and then write a simple script. Run the otl at the command line and feed it a sequence of bgeo's to generate the high res meshes as optimally as possible. I also wish for more Mantra procedurals partnered with equivalent SOPs and the Particle Fluid Surfacer is one candidate for sure. so are you say that using a delayed load render would result in the same memory usage as a procedural? i know after some tests that delayed loads on particles surfaces use less memory than rendering straight out of houdini. EDIT: just to point out, the memory usage difference is minimal. jason Edited June 3, 2010 by jason_slab Quote Link to comment Share on other sites More sharing options...
old school Posted June 3, 2010 Share Posted June 3, 2010 (edited) so are you say that using a delayed load render would result in the same memory usage as a procedural? i know after some tests that delayed loads on particles surfaces use less memory than rendering straight out of houdini. EDIT: just to point out, the memory usage difference is minimal. Yes it should be pretty much the same memory consumption. Mantra utilizes the same underlying c++ functions as SOPs. If the procedural uses built-in functions then it should be very close. Mantra is coupled pretty closely to Houdini in that way. I wonder if the extra memory consumption was due to the viewport. Did you do this via hython/hscript or in Houdini? Other 3rd party tools like RealFlow for Maya/Max/Soft/c4d etc have to do some of the steps as a post process that Houdini does for us via SOPs and ROPs just because. At the end of the day geometry is just geometry. Where and when it gets built and what is most efficient and what fits best in to a given pipeline should always be given a quick test now and again. Edited June 3, 2010 by old school Quote Link to comment Share on other sites More sharing options...
jason_slab Posted June 3, 2010 Share Posted June 3, 2010 hey i'm guessing the extra memory comes in when using houdini, which i am doing... i'm just really trying to find the most efficient way, at the moment I'm using roughly 14 gigs to generate surfaces.. jason Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.