This thread might be worth reading - “Volume Attributes” and fluid fields [sidefx.com]. where Jeff Lait says …

The way to do this now is by object merging your desired fields into the object to render. Instead of having one volume primitive with several attributes (say, density, temperature) you have one volume primitive per attribute. The name primitive attribute marks the role of each of your volume primitives. By default, the primitives exported from DOPs will have appropriate names attached to them.

Then, in mantra, you merrily add a “temperature” parameter to your shader. This will be overridden on a per sample basis with the incoming temperature field.

I'm using this method to get extra volume attributes into my shaders. The more round about way is to compile them into I3D's, which I resort to when the volumes get large. BTW where he says “name primitive attribute”, read the primitive attribute named “name”.

addendum: where he says object merge, read SOP merge.

-Drew

This is something I've been playing with briefly over here, though sadly haven't the greatest amount of time to put it together.
Do any of you guys have a test scene of these setups we could have a poke through?


cheers,
-j

drew
I'm using this method to get extra volume attributes into my shaders. The more round about way is to compile them into I3D's, which I resort to when the volumes get large. BTW where he says “name primitive attribute”, read the primitive attribute named “name”.

Thanks Drew.
I'm trying this out but I can't get it to work (I can ObjectMerge from the *simulation* no problem, yes, but not from a non-simulated plain-vanilla IsoOffset-generated volume).

Here's what I'm doing:

Inside object Foo:
*/ One SOP chain (let's call it “initDensity”) defines the smoke density (ends with an IsoOffset SOP) and outputs a single volume primitive. I want Mantra to interpret this as my density.

*/ Another SOP chain (“initRest”) is a bounding box that surrounds the smoke density. This is converted into 3 separate volumes (IsoOffset*3) to represent the three components of my rest position (rest). They are Merge'd together into this chain's 3-volume-primitive output.

Now, if I ObjectMerge “initRest”, toggle on “Create Primitive Groups”, and give it a group prefix of “rest”, the SOP info tells me I now have 3 primitives in group “rest0”. And similarly for “initDensity”, I end up with 1 primitive in group “density0”.
Even if I change my shader params to match the “density0” and “rest0” group names I still get Mantra interpreting all 4 volumes as density.
Alternatively, if I add a GroupSOP to the ends of each chain and give them the group names “density” and “rest” respectively and ObjectMerge those (which already have group names assigned) with “Create Primitive Groups” toggled OFF… still no love.

I've tried several combinations of the above but I've got nothing so far.
Here's the little test file I posted over at odForce. It has a single object called “Sphere” which is set up as I describe above. The goal is to get the vector attribute “rest” over to the built-in “Billowy Smoke” shader *without* going through the simulation (i.e: skipping DOPs; just a plain volume with attributes). Could you or Jeff Lait edit it to show me how this ObjectMerge thing is done?

(BTW: I'm testing this in H9.1.139)

TIA.

P.S: Hey Jacob, the attached hip file shows all the stuff being talked about in this thread. I've commented it a bit for the odforce post [forums.odforce.net]. Hope it helps.

Hey Mario,

Just reading this briefly and not testing anything… are you making groups or attributes? Mantra isn't going to pick up groups of course, only attributes…

Like I said, I haven't read this in depth so likely missing something said earlier.

Cheers,

PeteR B

Yeah, thats the problem, Mario. Don't bother with primitive groups; what Mantra wants is each primitive to have an attribute called “name”, with the value set to the name your shop parameter.

So: if you shader has a vector parm called “rest”, your three Volumes need a “name” string attr called “rest.x”, “rest.y”, “rest.z”.

jason_iversen
Yeah, thats the problem, Mario. Don't bother with primitive groups; what Mantra wants is each primitive to have an attribute called “name”, with the value set to the name your shop parameter.

So: if you shader has a vector parm called “rest”, your three Volumes need a “name” string attr called “rest.x”, “rest.y”, “rest.z”.

Oh… My…. God!

Yup, that works.

I couldn't possibly imagine a more obtuse and unintuitive way to do this.

Yeah, I think it's very kludgey too. It seems as if Volumes need an intrinsic name and perhaps type (Fog, SDF,Velocity) alongside their already-existing visualization mode.

This is nuts. Is this actually documented somewhere and I just haven't looked hard enough?

Just a quick question so I understand this correctly…

Would the string attribute be called “name”?

if so, how do you specify in the attribcreate SOP the channels “rest.x” “rest.y” “rest.z”?

———————————

Edit: I think I got it now. Had to reread Jason's post a couple of times.

make 3 extra volumes. In the first one, add an attribcreate sop, set to string, called “name”, with the value “rest.x”
In the second one, the value is “rest.y”
etc etc.

In the shader, there is a vector parameter called “rest”.

Is this it? Is there more that I am missing?

shikung444
Is this it? Is there more that I am missing?

Nope. That's it. You got it

I've just discovered a BUG with this in 9.1.151:

It seems as if there is a bug preventing this from working in Displacement shaders. ie, Mantra is not sending in “name”'d Volume samples to the displacement shader as it does with the Surface shader.

You're right, there is a bug in micropolygon volumes with displacements and attributes… It should be fixed in 9.1.160.

However, if you render your scene with raytracing you should see what it is supposed to look like - which probably still isn't what you might expect. The issue is that displacements are defined differently for volumes - the displacement is performed on the lookup position, resulting in a reversed appearance to the displacement (ie. in your case, the volume will appear translated left rather than right). To achieve smooth displacements, you need to define the displacement field in the empty regions outside the volume, too - so that the volume can be displaced into those areas.

Andrew

Ohhh - that does explain a lot; thanks for the info and the fix, Andrew. I'm guessing that the concept of pushing the micropolygon results in too artifacts to be a usable approach? I am trying to push the densities around based on a vectorfield - and I'm wondering if I'm going to be able to get the effect I want… without having a routine to convert my “push”-field into a “pull”-field (even though the there is not a perfect conversion between these types of fields). Do you have any ideas about this?

Thanks,
Jason