Howdy,

I'm working on some procedural fluid stuff, and need to be able to do some calculations on matrix fields in DOPs. But it seems that the GAS Field VOP doesn't support them. Is that a bug?

I've attached a small example. Basically it uses the Gas Analysis DOP to take the jacobian of the velocity, then uses a Gas Field VOP to put the determinant of the jacobian into density (just as a test of course). The Matrix Field visualization shows the Gas Analysis node is working, but a printf on the “jacobian” parameter in the Field VOP shows it to always be all zeros, which is strange, since it's default parameter value is the identity matrix. It's like Houdini is trying to set the parameter to the field, but setting all zero's instead of the actual values.

Or is there something I'm missing here?

Thanks

If you're looking at a particle-based solution that's still volumetric (i.e. not sprite-based), you might want to spend some time dissecting the Smoke:Heavy tool that comes with the FX Tools shelf you can download from SESI, if you haven't already. Basically it copies metaballs onto particles, then renders them with the “Metaballs as Volume” (vm_metavolume) parameter set to true (under the Render/Geometry tabs).

The tricky/clever thing with this approach is that you still need some sort of noise that travels with the smoke to get convincing detail. So that's one of the reasons the tool requires you to write out the metaball geo to disk as well: the volume shader can then read the metaballs in and loop through all metaballs affecting a given point, and use each metaball's local space to generate a noise value. The result is noise that “sticks” and combines as the metaballs move around.

It's very straightforward to plug your own particle system into this setup and shader. Very quickly: add a Smoke:Heavy node, then Allow Editing of Contents. Go into the smokerender Geo Obj below that, and swap out the POP network in there (popnet1) with your own.

There's obviously tons to be done with a DOP fluids sim and stuff to get convincing smoke, but it's worth having a look at this approach if you're trying something Afterburn / particle-ish.

It looks like any iterable triple works, meaning either a tuple like:

prim.voxel((i,j,k))

a list

prim.voxel()

or a hou.Vector3

idx = hou.Vector3(i,j,k)
prim.voxel(idx)

mmlxx
jeff, that's a flexible way, thank you and everybody

Jeff's suggestion is indeed really nice from a flexibility standpoint. The only subtlety I would point out is that, by default, any forces you apply in your smoke sim will be scaled by the density at a given point. That's what it means that the “Density Force Mask” is set to “*” in the SmokeSolver node. So while you can absolutely scale the density post-sim if you're just trying to fix the render appearance of the smoke, if you really want your various forces to be affected by the dissipation you need to to do it in the sim somehow. You don't always need that, of course, but sometimes you might.

Well, one simple way to do dissipation is just to scale density down by a small amount every frame.

So, in a typical “AutoDopNetwork” setup, just add a GasCalculate node and attach it to the last input of the SmokeSolver (the “post-solve” input). Set the source and destination fields both to density, then add a scale factor in the “Source Pre-Mult” parameter. You'll want this pretty close to 1, like .95 or something, but can play with it to taste.

If you look at the “cool_gas” node within the SmokeSolver as suggested above, you'll see it's doing the same thing, in that case just to temperature.

Hope that helps.

There's a good bit of discussion of caustics and a couple of examples here:
http://forums.odforce.net/index.php?showtopic=6211 [forums.odforce.net]

probbins
I was able to clean up your first example by changing the Surface parameters. In particular “stepsizex” and “radius scale” and “surface distance”

Yeah, I've been able to get rid of most of the artifacts by tweaking the parameters; I guess my point is you shouldn't have to, IMHO. There's really no way that two points spaced one unit apart should give rise to that weird surface in the middle in that test file. And if you fix the artifacts with parameters for one frame, they show up at another position or in another part of the animation. And then you're changing parameters not based on the appearance,tightness, etc. of the surface, but whether or not they cause artifacts. If I want the “liquid man” model in question to be big and gloopy looking, I'm kind of out of luck without artifacts. Things like increasing particle count, changing stepsize, and whatnot can dramatically change the overall look of the surface.

/rant

In this case I was able to use Connectivity/Partition, Measure, ForEach and AttribPromote to remove groups of connected primitives below an arbitrary overall surface area, which generally worked fine, because there's really only one big connected surface you care about. If there were lots of little drops that probably wouldn't work. Also, some of the artifacts are not disconnected from the overall surface, but in this case they weren't too objectionable.

Anyway, while I agree that you can work around the artifacts, I would still rather not have to.

Edit: Oof, this whole post comes off way more rant-y than I meant. So, I should add, Houdini's always the bees' knees and I've gotten a ton out of your tutorials, Peter, thanks.

Allegro
This is a known issue which is being worked on.

Aside from having a higher density mesh on your surface/more particles… there's not really anything you can do.

You could manually delete those polygons on given frames as well.

Any update on this? This test file has the same artifacts in 9.5. I was looking at Robert Magee's liquid metal tutorial from 3DWorld again, and these artifacts from the particleFluidSurface node make things a bit messy. It's a shame because otherwise the surface looks really good in a blobby/ goopy metal sort of way.

zarroun
If you don't mind, I do have a question about how Houdini understands this. I saw that you entered a Distribution Attribute name in the SourceSOP. Is that what's in the end driving the emissions? I'm surprised that the birth probability is at default.

From the help for the Source POP:

Distribution Attribute
When Emission type is “Prim center (attribute)”, “Edges (attribute)”, or “Surfaces (attribute)”, the attribute to use as the probability of emitting a particle.

Birth Probability
Number of particles to emit per source point.

So (I think) the choice of using a particular primitive to emit from in the first place is driven by the Distribution Attribute, the number of particles to generate once that point/prim is chosen is based on the BirthProbability.

Also, how does the scatter understand the gray scale values? Does the emission then depend on the number of points on the surface that the scatter created?

By unselecting “Scatter Based on Primitive Area” you can use an alternate attribute to drive the scatter. By cranking up the “AttributeBias” to 1 you make sure points only get scattered according to that attribute.

Then you end up with a whole ton of points scattered based on your emit attribute. Since the Source POP uses “Points (random)” to birth particles from, it's more likely to emit from areas where points were scattered more heavily. So the end result is pretty much the same as using the Distribution Attribute, but you never have to promote the attribute to prims or anything.

I'll post the results once I'm done with the effect. Thank you again for helping me out.

You're very welcome, look forward to seeing the results.

Yeah, the “Embed Object in Fluid” is not what you want. That tool causes the object's points to be advected along with the fluid sim, which is why it's being deformed.

You should just be able to select the object and use the “Static Object” tool under the Rigid Bodies shelf, and it will be wired into an existing fluid sim AutoDopNetwork as a collision object for the fluid.

There's a few different ways to do this. Basically you paint a custom attribute, then use that to drive the probability of a particle being birthed, either by first sending that through a Scatter SOP to generate source points, or using the attribute directly in the Source POP.

I put a couple together in the attached example.

In general in DOPs, you need to make sure the parameter you're setting is set to “Set Always” if it's changing over time. However, if your smoke source is an RBD Static Object, which is a digitial asset, the various physical parameters just feed into a contained PhysicalParameters DOP, and that node is set to “Set to Initial” as setting the parameters, and there's no way to change it at the top level.

So, either right-click on the StaticObject, choose “Allow editing of contents” and go in and change the Temperature param on the PhysicalParameters to “Set Always”.

Or (better, IMO), just append a new PhysicalParameters DOP after the static object and set all your values there, including an animated temperature set to “Set Always”.

Make sense? Attached is a quick example.

For whatever it's worth, here is a version of Andrew's file with a simplified CHOPs network. It does the same thing; it's just a bit simpler. Of course, Andrew's approach has the advantage that you could scale the x,y,z components of the jiggle independently if you wanted.

I also moved the painting into the animation object itself. That speeds things up a bit, as in Edward's file.

Hmm, trying this in ApprenticeHD, the Shell ROP inside the Wedge HDA errors out with “Operator unavailable in Non-Commerical Edition”.

Looking at the journals, that was supposed to have been fixed in 9.5.141, but it's not working for me in 9.5.163. If I just put down an empty Shell ROP and hit Render I get the same error.

There's some discussion of this error and other photon stuff at:

http://forums.odforce.net/index.php?showtopic=6211 [forums.odforce.net]

jason_iversen
The points are “consolidated” (shared) and so the normals are interpolated. Houdini does not support vertex normals - only point normals - and so you have to unshare the points.

What you need to do is to follow this with a Facet SOP or Fuse SOP and “Unique Points”. Unforunately the Platonic Solids SOP doesn't have this built in to it's network you do must do this yourself. If you want to use the shelf tools, select all the edges and run an EdgeCusp.

Another non-SOP possibility is at the Object level, go to the Render tab, then under that the Geometry tab, and un-select “Automatically Compute Normals”. In this case Mantra uses the Primitive normals, I believe, so you'll get the “faceted” look without changing your geometry.

But with Jason's method the object will look correct under Smooth Shading from within Houdini as well.

patar
is there a way to select an edge procedurally?
or convert from a primitive to edges or point to edges procedurally ?

I've had some success using Simon's GroupEdges SOP available from here:
http://www.fourthwall.ndo.co.uk/HT_HDK_GroupEdges.html [fourthwall.ndo.co.uk]

I've been noticing some artifacts when creating a surface with the ParticleFluidSurface node, and finally just did a simple test to isolate them. There seems to be some weirdness in the implicit field that it's generating, where you can often end up with stray polygons where two particles are just outside their respective areas of influence.

In this screen shot, the top surface is from the PFS node, the bottom just two metaballs Copy SOP'd to the same points and ConvertMeta'd. I don't see why that strange mass in them middle is there in the PFS example. I'm seeing the same symptom in the results of fluid sims.

Any ideas? I'm including the test file as well. This is with 9.0.768, BTW.

Thanks

I've been messing around with the PBR renderer, trying some multi-bounce photon-mapped renders, mostly with success. I did a test of interior illumination with an area light outside the window, attached below. The global photon map included 100,000 photons and 10 bounces. I'm not using a caustic map. The result is pretty nice, but the chrome sphere has some strangeness.

Rendering a closeup, it looks like the renderer is using only the photon map for the direct lighting on the surfaces being reflected. For diffuse reflections that's what you want, but for pure specular reflections, shouldn't it still be doing the full direct lighting calculation? Is there a setting for this that I am missing?

Thanks

Thanks for the reply Mark.

Whoops, looks like it's actually an issue with the built-in compositing within mplay. I've been testing my shader by loading a background image into mplay then rendering on top of that. When there's a background loaded, the colors from the shader don't show up if the alpha is zero.

Same thing happens with your example. A regular render into mplay works fine, but then load a background and the image disappears. Strangely that still seems to be the case even if you then unload the background. You have to restart mplay to get it working again. This is with 9.0.760 on OpenSUSE 10.2-64 by the way.

Anyway, obviously this is only a problem for testing, and I can easily work around it by testing with a real composite within Houdini.

Thanks again