Thanks for the thorough reply, Johner.

Due to the nature of the shots I am working on, it doesn't look like the collision shapes will get any simpler. I do enjoy that the Pyro solver can use a straight volume field for collisions. I would love to see a similar simple/quick treatment applied to POPs.

I can stick w/ old POPs for now, and can't wait to see if there are more speed improvements on this collision model ( bypassing of the sdf rebuild? )


thanks again!
-j

Hi Guys,

Thanks for taking the time to reply. I realize my first question was a bit misguided. Circus, I have used the static obj/proxy vol trick in the past with some good successes.

After going through your file, I realize I should have just asked, how can I make POP collisions faster. I have attached an updated file with 3 different sim setups.

1) DOPs collisions with the static object.
2) DOPs collisions hacking a vop sdf collider
3) POPs collisions using a sdf collider

While I can't get the #2 to work properly (DOP POPs seems to have a lot more to think about when it comes to resetting a particles velocity) you'll notice that it is almost 20x faster then #1 (this time difference grows exponentially with an increase in the SDF resolution).

Looking through the performance monitor. For #1, It seems the biggest slow down is the collisions on the particle integrator.

I guess my question is, how can I get #2 to work. That is, read in my own SDF, ignore the POP DOP particle collisions (slow), and have a stable sim? Is there a DOP node that helps achieve my goal, can I achieve it in VOPs, or is it all under the hood.

thanks!
-j

Hi Guys,

While I get my head around the new Pop Dop workflow (yes, just updating to it now…) I am wondering what the best way is to handle simple collisions.

I have taken a stab at using the Static Object DOP which seems to work in most cases.

However, I have some really high geo to collide against, and I would like to collide directly against an sdf of the geo. When using the Static Object, there is a very slow caching stage I'd like to avoid.

My next thought was to try using the Gas Collision Detect node directly. However, I have no clue how to get this to work. Or if it is even the right idea…

I have attached a file with my current setup. Any pointers and guidance you guys have on using these heavy colliders in POP Dops is much appreciated!

cheers,
-j

That looks like it was the issue.

I have updated the expression with the one you provided, and all looks good!

thanks!
-j

Hi Guys,

I am trying out a simple RBD constraint setup in H14, but seem to be at a loss.

In the attached file, I have followed the generic setup for creating a shattered wall, and then using the ‘Glue Adjacent’ tool to constrain them together. When the file is played back, the pieces move a certain distance, then the constraints freeze the pieces in space.

Any tips on how to get a more normal behavior from this?

thanks!
-j

Thanks, twod!

It was indeed an out of date Intel Driver.

I have updated my Intel to 10.18.10.3958, and all is hunky-dory now.

Thanks for the reply Edward. No dice sadly.

I even tried emptying the shelf file entirely, and that had no effect…

Hi Guys,

I have downloaded a copy of H14.0.201.13 and can't get it to work on my Windows machine.

So far my steps have been
1) Open Houdini
2) Try to create a box (or anything at obj level)
3) Houdini instantly crashes with the following error.

I am on Windows 8, 64 bit.

Any thoughts what it could be?

thanks!
-j

file//CUsers/snow/Documents/houdini14.0/toolbar/default.shelf:1: parser error : Extra content at the end of the document

^
USe larger font: 00000000590A174D
6136: Fatal error: Segmentation fault

Hey Guys,

We're playing around with a new idea to switch centimeter models to meters.

At the moment, models are ingested from upstream in centimeters, converted to meters for Houdini Sims, and then published back out as centimeters to lighting.

In the hopes to best automate this process, it would be neat to have a tool that scales all necessary attributes from cm->m->cm seamlessly. At times you may add a rest attribute, or perhaps velocity to your geo.

I have whipped up a concept of this idea in the attached scene file using a Python SOP to edit a Wrangle node snippet. It's super basic, but adds each incoming attribute to the wrangle node, and multiplies it by 0.01.

My question is, can this be considered a stable approach? I notice that the python/wrangle node do not update in a few situations. One either in Manual cook mode, or if a lower level node is not displayed.

I wonder, are there any cases where this may become a stumbling block for the artists? Or does the python node manage too cook at all the right times?

thanks!

http://houdinitoolbox.com/houdini.php?asset=38 [houdinitoolbox.com]

Check out Graham's toolbox. He has a method to run an init script no matter what type of node is dropped down.

Hey Dave,

I haven't checked the rgb format, but will icp convert it for you?

-j

So I couldn't find anything called “vm_rendergroups”, but there is a “vm_geometrygroup” which is quite promising.

It doesn't look like the parameter takes wildcards. Explicitly setting the name works a treat though!

-j

I'm not sure this has ever happened to me. But if I google “vm_rendergroups”, the only item returned is this forum group.

Recursive much?

It would be interesting to hear what your trying to do and whats stopping you from pulling the data you do want into another geometry node to render.

Not much really, as that's what we have ended up doing. I was thinking it'd be great to do this with a Delayed Load. Have the same geo that I bring into Houdini, also be ready to pipe straight to the render, with visibility attributes set. As you say, splitting it up works well otherwise.

Thanks for the pointer Wolfwood, I'll take a look!

-j

The Visibility SOP would actually be perfect for our needs! Unfortunately, it only works for OGL, and not Mantra.

Unless of course if I am doing it wrong….

Hey Guys,

I could have sworn there was a point attribute to hide Geometry from rendering in Mantra. Does this exist, or am I just crazy….


thanks!
-j

Has anyone played much with the instanceFile point attrib? It's looking pretty sweet.

anybody wants to add settings on top of that list?
anybody using PBR ?

I've found PBR can add fantastic results, but is very slow for volumetrics. Traditionally, we use 3 Spotlights set to Red, Green, Blue, and then balance these in Comp.

Volume step size should always be the same size as the Volume divisions. Any higher, and you just waste these extra steps. Recently, I've learned that Shading quality of 2 or more will really add a high level of detail to your fire sims.

Would love to hear what else there is!

-j

Huh, with out seeing that picture, I would say why are you splashes in the same geo as the surface.

With seeing the picture, I now say, why don't I render them together?!

I agree that this is a memory management scenario. I've never had much luck brute forcing these scenarios in the past. Remember you're not making 2 different renders, just multiple pieces of geo in the same render to load one at a time. Splitting things up is lame, but I am always keen to learn of new techniques I have missed!

Looks good, hope to see it rendered one day!

-j

Hi Ceegee,

I feel your pain. Rendering such a large Object (both in space, and complexity) can be a nightmare.

Make sure there are no attributes on there you don't want. Just P, possibly N, and v. Consider breaking the Grid into several different grids so that Mantra only has to load one at a time.

Most importantly though, I'd recommend using Displacement maps. Most approaches I've seen in the past (including my own) Generate a low res grid, then apply the high detail at render time.

Good luck, and curious to hear how you solve it!
-j