Jump to content


Houdini 12 - First Time


  • Please log in to reply
24 replies to this topic

#13 Mzigaib

Mzigaib

    Initiate

  • Members
  • PipPip
  • 243 posts
  • Joined: 09-June 10
  • Location:Brazil
  • Name:Michel Zigaib

Posted 04 March 2012 - 12:11 AM

Just having a little fun!

View on Vimeo.


Michel M. Zigaib
___________________________________
VFX TD

#14 old school

old school

    Houdini Master

  • Members
  • PipPipPipPip
  • 889 posts
  • Joined: 21-March 03
  • Location:The Great White North

Posted 04 March 2012 - 06:33 AM

View Postkrautsourced, on 03 March 2012 - 03:51 PM, said:

I noticed the same. I checked with Process Hacker and there is a veeeery slight performance difference. Without OpenCL a Billowy Smoke used 40-50% CPU and 3-4% GPU. With OpenCL it was 35-40 CPU and 4-5 GPU. And no noticeable speed increase. Really hope that's a bug somehow... (It's still twice as fast as it was in H11 so that's good of course...)

Some operations are not supported on the GPU. If you are using Pyro, then some of the shaping models rely on Gas Field DOPs and Gas Caluclate DOPs.

If you want to explore the GPU and craft very efficient simulations there, do what I do and start building the simlation using the various pieces from the shelf:

- Create a Smoke Container in the scene from the Fluid Containers shelf.

- Turn any object in the scene to a smoke emitter from the Populate Containers shelf. It would be nice to actually have the Smoke container around the object, if I even have to mention that but some comments I see on this World Wide Web simply amaze me but not us OdForcer's, right?

- Probably best to disable the Resize Container Solver DOP that is placed for you and again resize your container such that it is large enough for your simulation. The GPU I find is more efficient if you don't send in a resizing fluid container although it can handle it. My reasoning is that it doesn't seem to matter too much the size of the container, it's the resolution of the container so might as well max it out from the start. Once on the GPU, and everything remains in place, you are good to go.

- On the Smoke Object DOP, change the Division Method to Max Axis and set your max resolution size. In H12 the default for resolution is in voxel size. Change that to actual max resolution. I find this helps in not blowing past your gpu's memory requirements which you sould definitely do to see where the limits are.

- Delete any fields you don't need.
If you have a standard buoyancy based sim where temperature drives uplift with the Gas Buoyancy DOP, and there is no combustion taking place, go to the Smoke Object DOP and uncheck those fieds you don't need to use.
> Fuel
> Divergence
> Burn
> Pressure
> Rest (well you may want to keep this around for shading)
> Confinement
> Heat
You can toss a great deal of fields in the Pyro Solver DOP's advanced tab to blast fields as well.

As you add featuers back to your simulation, like collisions (in case you removed collision and collisionvel in the Pyro Solver's delete fields parm) to your liking. Remember you are trying to get things as efficient as possible so will require some hand-tuning.

- Jump to Smoke Solver DOP's advanced tab and enable GPU. The first frame should take quite long as the fields are copied to the gpu. After that, your sim should move very fast.


To add shaping features beyond what you get from the Smoke Solver, be careful. Many features are not supported on the GPU. Here's a brief run-down on what I have found to be common issues.

Collisions
- Watch deforming collision geometry with RBD's. If you insist on using the old H11 method of wiring in RBD objects in your pyro simulation, don't. This will force the collision field to be copied to your gpu every sim substep. That is why there is the Collide With tool in the Populate Containers shelf.
Run your RBD simulation first and cache to disk. Then using the Collide With tool, select your RBD objects and voila, you have a static collision field in your simulation. Don't forget to add those fields in case you removed them.

Gas Calculate DOP not GPU Friendly
- All those hacky tricks in H11 to rework and add new fields to do basic things is no longer required in Houdini. That is why H12 builds Volumes in SOPs and uses the new Source Volume DOP to fetch SOP Volumes and maps them in to the simulation.
There is a new DOP to do much of what the Gas Calculate does and is GPU friendly. This is the Gas Linear Combination DOP. Use this instead. Actually all those neato H11 files that use Gas Calculate can be ported to use the Gas Linear Combination DOP.
You can use this to boost vel by setting the Destination to "vel" and Source 1 to "vel" then you can changet the Combine Operation to Multiply and then change the Coefficient to 2 and you have doubled your velocity. You can use a second and third field to behave as custom masks to only work on your Destination field directly.
I use the Gas Linear Combination DOP to do a lot of resahping directly.

Wire the Gas Linear Combination in to a Merge DOP (as you can chain several in turn) and wire the Merge DOP in to the second from the left GREEN input ( the Velocity Adjustment input if you use MMB on the green input tab).

This also goes for the Gas Field VOP. Not supported on the GPU.

All the shaping models in Pyro rely on Gas Field DOPs and Gas Calcualte DOPs (which in most cases "could" be ported over to Gas Linear Combination DOPs but I don't know as I haven't tried).


By doing all of the above, I can take my lame arse GeForce GTX 260 sim up to a 480^3 simulation and runs at about 1 fps using a couple Gas Linear Combinations in line with a simple source and collision geometry. Very impressive stuff but you really need to line up your ducks. Nice thing though is if you do this, the gpu won't blow out as you run the sim. If it can get to the second frame, it will make it to the last frame.


Some notes:
- When you cache the results to disk, the sim will slow down considerably as the volume data needs to be copied off the gpu and on to your hard drive via Houdini. The viewport update is very fast because the gpu draws directly to the viewport. Yes we do support NVidia's Maximus (well if you drink NVidia's KoolAid you'd think that the only software that supports Maximus is Maya and custom fluid tools developed at a University  :rolleyes:  ).

- Actually any time you querry the sim data with any clever expressions or whatever you try, it will cause data to move off and most likely back on to the gpu. See if you can cache any of that cleverness in to fields and then use the Gas Linear Combination to work that data in to the simulation.
For those of you that like influencing sims directly with particls using the Gas Particle to Field DOP. Nope. Use the Source from Particles Tool in the Populate Fluids shelf and in DOPs, using the Source Volume DOP, directly inject the result in to a named field. If it is expansion, it will be driven in to the divergence field. There are presets on the Source Volume DOP that help you quickly set up these presets using the Initialize menu option at the top. Do the same for the Source Volume SOP creating the fields if you didn't use the shelf tool to do all of this for you.

Either do this or sim on the CPU which is also quite fast.



There is a lot more about the GPU and fluid simulations but that should get you thinking in the right way. Come to think of it, if you apply these steps to any simpulation, gpu or cpu, it will help you get efficient sims.
There's at least one school like the old school!

#15 old school

old school

    Houdini Master

  • Members
  • PipPipPipPip
  • 889 posts
  • Joined: 21-March 03
  • Location:The Great White North

Posted 04 March 2012 - 07:01 AM

To answer what is the first thing I tried in H12, it varies based on what new feature was added internally (yes it is awesome working at Side Effects!).

Obviously last summer it was Pyro 2 as Coen was adding features and when Jeff L. added Project Non-Divergence Multigrid, well I had a big grin with the speed improvements. This makes Pyro my first test in Houdini 12.

When the new Geometry Library was finally comitted to the H12 baseline, a big internal milestone btw, I first fired up Houdini and it was up in 3 seconds. It didn't crash (most likely because the new viewport wasn't committed yet...). I immediately added a sphere, cranked it up to 200 divisions which it willingly did in a second, copied it a few times then tried sculpting one of the spheres. Added each primitive in to a group creating hundreds of thousands of groups in a few seconds which would have crippled H11. No issues. Very impressed at that point.
In H12 many SOPs still need to be optimized for maximum performance and full multi-threading - if you find any SOPs that need performance improvements, let us know through Support. Not all SOPs will make sense to thread btw but you never know what can be done. Yes this means that there is still performance gains to be had, hopefully as the viewport performance features get added.

When the new Cloth solver was added, within a half hour of playing with it, I realized that we were dealing with a unified solver and that Cloth was just one facet of this solver. I pushed it a bit to do a point based, then edge, then surface and I was very impressed. I then created 50 sheets of cloth stacked and dropped on a box. It actually worked right through it all. No dreaded solver lock-ups in H11. Phew.
Speed was up there but the interface was somewhat complicated. In the last month (Jan-Feb), the Cloth Object and Cloth Solver saw a complete simplification of the parms and introduced a mix of Weak and Strong bend models. I was very impressed as to how you could easily define the cloth properties by mixing in varying amounts of weak and strong bend models! Btw these things sometimes don't show up in the journals but taking large swaths through Houdini with simple exercises keeps you on your toes. That's how I discovered it on the day. :)

As for FLIP, since November of last year it seemed that every day brought in a new FLIP solver improvement and seeing it improve in speed, look and flexibility of features made every day a treat to update and check out. FLIP added varying density I think in November and variable viscosity added in the last month before the release. Again sweet stuff to try out and play with in combination with SOP Solver DOP to rework the particle attributes.

----

I guess the days of beta with locked-off features and UI are now long gone. This is why docs will take some time to catch up to the release so patience in this area and let's see if we (notice I said "we" and not "them") can answer questions on the forums and get that in to the docs.

Edited by old school, 05 March 2012 - 02:09 PM.

There's at least one school like the old school!

#16 jim c

jim c

    Illusionist

  • Members
  • PipPipPip
  • 385 posts
  • Joined: 01-November 08
  • Name:Jim Crafton

Posted 04 March 2012 - 10:32 AM

I went and tried a PBR experiment. One of things that people have complained about here (and in other forums) is the supposed slowness in speed with Mantra. Usually the test is a simple piece of geometry, like a couple of glass sphere's or something like that.
So I decided I'd try PBR with a test scene I'd put together in Modo for a sculpt I'm working on (http://learning3dfro...2/monsters.html).
After replicating the scene in Houdini, and using the Mantra Surface shaders, I rendered it with PBR at 640X360 (don't have the HD aprrentice version yet)
The scene has around 300K polys, volumetric light (using an Atmosphere object and vex lit fog), DOF turned on, and 3 spot lights.
PBR sampling was set at 8X8 as well as 4X4 (I believe this is the equivalent of Modo's anti-aliasing sample settings, but I'm not sure).

Mac Pro 3.1 12GB RAM  8 X 3Ghz cpu

With Modo 601, the render took about
4x AA 45 seconds
8x AA 61 seconds
modo-601-8xaa.jpg


Mantra
4X4 sampling 31 seconds
8X8 sampling 85 seconds
h12-mantra-8x8.jpg



I have no idea if I could have tweaked things further in mantra to improve stuff, but I was impressed with the speedup! I would be very curious to see how this holds up with larger image renders.

Edited by jim c, 04 March 2012 - 10:34 AM.


#17 edward

edward

    Grand Master

  • Members
  • PipPipPipPipPip
  • 3,325 posts
  • Joined: 10-September 02
  • Name:e.d.w.a.r.d. .

Posted 04 March 2012 - 11:24 AM

View Postjim c, on 04 March 2012 - 10:32 AM, said:

After replicating the scene in Houdini, and using the Mantra Surface shaders, I rendered it with PBR at 640X360 (don't have the HD aprrentice version yet)

Interesting, try motion blur too.
don't panic!

#18 Mzigaib

Mzigaib

    Initiate

  • Members
  • PipPip
  • 243 posts
  • Joined: 09-June 10
  • Location:Brazil
  • Name:Michel Zigaib

Posted 04 March 2012 - 02:21 PM

Anyone having problems with showing custom attributes on the viewport? I am having some crashes when I try to display some custom vector attributes.

Ps: already update my video card driver.
Michel M. Zigaib
___________________________________
VFX TD

#19 zglynn

zglynn

    Peon

  • Members
  • Pip
  • 59 posts
  • Joined: 12-June 09
  • Name:zach glynn

Posted 04 March 2012 - 09:00 PM

View Postold school, on 04 March 2012 - 06:33 AM, said:

Some operations are not supported on the GPU. If you are using Pyro, then some of the shaping models rely on Gas Field DOPs and Gas Caluclate DOPs.

If you want to explore the GPU and craft very efficient simulations there, do what I do and start building the simlation using the various pieces from the shelf:

- Create a Smoke Container in the scene from the Fluid Containers shelf.

- Turn any object in the scene to a smoke emitter from the Populate Containers shelf. It would be nice to actually have the Smoke container around the object, if I even have to mention that but some comments I see on this World Wide Web simply amaze me but not us OdForcer's, right?

- Probably best to disable the Resize Container Solver DOP that is placed for you and again resize your container such that it is large enough for your simulation. The GPU I find is more efficient if you don't send in a resizing fluid container although it can handle it. My reasoning is that it doesn't seem to matter too much the size of the container, it's the resolution of the container so might as well max it out from the start. Once on the GPU, and everything remains in place, you are good to go.

- On the Smoke Object DOP, change the Division Method to Max Axis and set your max resolution size. In H12 the default for resolution is in voxel size. Change that to actual max resolution. I find this helps in not blowing past your gpu's memory requirements which you sould definitely do to see where the limits are.

- Delete any fields you don't need.
If you have a standard buoyancy based sim where temperature drives uplift with the Gas Buoyancy DOP, and there is no combustion taking place, go to the Smoke Object DOP and uncheck those fieds you don't need to use.
> Fuel
> Divergence
> Burn
> Pressure
> Rest (well you may want to keep this around for shading)
> Confinement
> Heat
You can toss a great deal of fields in the Pyro Solver DOP's advanced tab to blast fields as well.

As you add featuers back to your simulation, like collisions (in case you removed collision and collisionvel in the Pyro Solver's delete fields parm) to your liking. Remember you are trying to get things as efficient as possible so will require some hand-tuning.

- Jump to Smoke Solver DOP's advanced tab and enable GPU. The first frame should take quite long as the fields are copied to the gpu. After that, your sim should move very fast.


To add shaping features beyond what you get from the Smoke Solver, be careful. Many features are not supported on the GPU. Here's a brief run-down on what I have found to be common issues.

Collisions
- Watch deforming collision geometry with RBD's. If you insist on using the old H11 method of wiring in RBD objects in your pyro simulation, don't. This will force the collision field to be copied to your gpu every sim substep. That is why there is the Collide With tool in the Populate Containers shelf.
Run your RBD simulation first and cache to disk. Then using the Collide With tool, select your RBD objects and voila, you have a static collision field in your simulation. Don't forget to add those fields in case you removed them.

Gas Calculate DOP not GPU Friendly
- All those hacky tricks in H11 to rework and add new fields to do basic things is no longer required in Houdini. That is why H12 builds Volumes in SOPs and uses the new Source Volume DOP to fetch SOP Volumes and maps them in to the simulation.
There is a new DOP to do much of what the Gas Calculate does and is GPU friendly. This is the Gas Linear Combination DOP. Use this instead. Actually all those neato H11 files that use Gas Calculate can be ported to use the Gas Linear Combination DOP.
You can use this to boost vel by setting the Destination to "vel" and Source 1 to "vel" then you can changet the Combine Operation to Multiply and then change the Coefficient to 2 and you have doubled your velocity. You can use a second and third field to behave as custom masks to only work on your Destination field directly.
I use the Gas Linear Combination DOP to do a lot of resahping directly.

Wire the Gas Linear Combination in to a Merge DOP (as you can chain several in turn) and wire the Merge DOP in to the second from the left GREEN input ( the Velocity Adjustment input if you use MMB on the green input tab).

This also goes for the Gas Field VOP. Not supported on the GPU.

All the shaping models in Pyro rely on Gas Field DOPs and Gas Calcualte DOPs (which in most cases "could" be ported over to Gas Linear Combination DOPs but I don't know as I haven't tried).


By doing all of the above, I can take my lame arse GeForce GTX 260 sim up to a 480^3 simulation and runs at about 1 fps using a couple Gas Linear Combinations in line with a simple source and collision geometry. Very impressive stuff but you really need to line up your ducks. Nice thing though is if you do this, the gpu won't blow out as you run the sim. If it can get to the second frame, it will make it to the last frame.


Some notes:
- When you cache the results to disk, the sim will slow down considerably as the volume data needs to be copied off the gpu and on to your hard drive via Houdini. The viewport update is very fast because the gpu draws directly to the viewport. Yes we do support NVidia's Maximus (well if you drink NVidia's KoolAid you'd think that the only software that supports Maximus is Maya and custom fluid tools developed at a University  :rolleyes:  ).

- Actually any time you querry the sim data with any clever expressions or whatever you try, it will cause data to move off and most likely back on to the gpu. See if you can cache any of that cleverness in to fields and then use the Gas Linear Combination to work that data in to the simulation.
For those of you that like influencing sims directly with particls using the Gas Particle to Field DOP. Nope. Use the Source from Particles Tool in the Populate Fluids shelf and in DOPs, using the Source Volume DOP, directly inject the result in to a named field. If it is expansion, it will be driven in to the divergence field. There are presets on the Source Volume DOP that help you quickly set up these presets using the Initialize menu option at the top. Do the same for the Source Volume SOP creating the fields if you didn't use the shelf tool to do all of this for you.

Either do this or sim on the CPU which is also quite fast.



There is a lot more about the GPU and fluid simulations but that should get you thinking in the right way. Come to think of it, if you apply these steps to any simpulation, gpu or cpu, it will help you get efficient sims.

Thanks old school! That really helps, there is some really great info there. Can't wait to try some stuff out. I'll post my results.

Zach

#20 magneto

magneto

    Grand Master

  • Members
  • PipPipPipPipPip
  • 1,295 posts
  • Joined: 04-October 11
  • Location:Canada
  • Name:Ryan K

Posted 06 March 2012 - 06:33 PM

@oldschool, you mean Maya fuilds are written at a university? I always thought they were gimmicky but never used it personally just saw demos :)

#21 asnowcappedromance

asnowcappedromance

    Initiate

  • Members
  • PipPip
  • 158 posts
  • Joined: 18-October 09
  • Location:Vancouver, B.C.
  • Name:Manuel Tausch

Posted 06 March 2012 - 07:00 PM

Jeff, thanks for all that info. How do I know which dop node is gpu friendly and which not ?
Also, how would you do something like noise and turbulence in a way that opencl likes?
Seeding vorticles is like the worst I find and slows everything terribly down, Gas Turbulence DOP on the other hand seems to be liked quite well!

thanks,

Manu

Manuel Tausch
senior FX TD - Rhythm & Hues

#22 vi_rus

vi_rus

    Initiate

  • Members
  • PipPip
  • 111 posts
  • Joined: 05-June 09
  • Location:Moscow, Russia
  • Name:Sergei Bolisov

Posted 08 March 2012 - 03:18 PM

Wow... Jeff, thanks a lot for your message! But I tried to do what you said and didn't get any dramatic speed increase. Maximum 2-3 times faster then CPU. If I set size to 300^3 then I receive errors from openCL. I have GeForce GTX 275. File is in attachment. Thanks in advance.

View Postold school, on 04 March 2012 - 06:33 AM, said:

- Create a Smoke Container in the scene from the Fluid Containers shelf.

- Turn any object in the scene to a smoke emitter from the Populate Containers shelf. It would be nice to actually have the Smoke container around the object, if I even have to mention that but some comments I see on this World Wide Web simply amaze me but not us OdForcer's, right?

- Probably best to disable the Resize Container Solver DOP that is placed for you and again resize your container such that it is large enough for your simulation. The GPU I find is more efficient if you don't send in a resizing fluid container although it can handle it. My reasoning is that it doesn't seem to matter too much the size of the container, it's the resolution of the container so might as well max it out from the start. Once on the GPU, and everything remains in place, you are good to go.

- On the Smoke Object DOP, change the Division Method to Max Axis and set your max resolution size. In H12 the default for resolution is in voxel size. Change that to actual max resolution. I find this helps in not blowing past your gpu's memory requirements which you sould definitely do to see where the limits are.

- Delete any fields you don't need.
If you have a standard buoyancy based sim where temperature drives uplift with the Gas Buoyancy DOP, and there is no combustion taking place, go to the Smoke Object DOP and uncheck those fieds you don't need to use.
> Fuel
> Divergence
> Burn
> Pressure
> Rest (well you may want to keep this around for shading)
> Confinement
> Heat
You can toss a great deal of fields in the Pyro Solver DOP's advanced tab to blast fields as well.

As you add featuers back to your simulation, like collisions (in case you removed collision and collisionvel in the Pyro Solver's delete fields parm) to your liking. Remember you are trying to get things as efficient as possible so will require some hand-tuning.

- Jump to Smoke Solver DOP's advanced tab and enable GPU. The first frame should take quite long as the fields are copied to the gpu. After that, your sim should move very fast.

Attached Files


Posted Image
Posted Image
Looking for a job

#23 vi_rus

vi_rus

    Initiate

  • Members
  • PipPip
  • 111 posts
  • Joined: 05-June 09
  • Location:Moscow, Russia
  • Name:Sergei Bolisov

Posted 15 March 2012 - 08:28 AM

http://www.sidefx.co...5234&highlight=
Posted Image
Posted Image
Looking for a job

#24 Vardan Petrosyan

Vardan Petrosyan

    Peon

  • Members
  • Pip
  • 24 posts
  • Joined: 07-December 11
  • Location:USA
  • Name:Vardan Petrosyan

Posted 22 March 2012 - 07:38 PM

Hi everyone I've installed houdini 12.0.571 and when I try to drag a material to an object I get this error (see the picture), does anyone have the same problem?
Untitled-1.jpg

P.S. I get this kind of error all the time doing different things following the basic sidefx tutorials

Edited by Vardan Petrosyan, 22 March 2012 - 07:39 PM.





0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users