Hi everybody.
Correct me if i'm wrong but there seems to be no voxel attribute or something which would play the role of a primitive attribute and which would allow us to define “volume attributes” on a per-voxel or rather per-voxel-center basis ( except of course density, which, so to speak “defines” the volume) like color or anything else and which would be interpolated on the whole volume.
Of course I can play with the color if i render my metaballs as volumes but this is because each metaball is considered like a separate volume.
Right?

For the moment, it's not that big of a problem: when i write “simple” volume shaders, i can use either world/object coordinates or metaballs to mimic this kind of attributes interpolation if i want to “texture” my volume.

But with fluid simulations, you have a lot of fields interacting , i may be wrong but there seems to be no other option but to render only one of this fields ( either just density or just fuel) or to make them overlap.
( but i don't think overlapping would solve the pb). What i would like to be able to do ( not because it's me but because it's more than useful and that other apps seem to do so), is to use for example the temperature field ( connected to a color ramp) to change the color of my density field in rendering or even in the viewport ( like Maya fluids). I can do that by transfering attributes from volumes to particles which i could turn into metaball but it's not the same…

Is it possible?
That would be really cool. If this doesn't exist already: what do you guys think of the idea?

-d

That would be great. I've been thinking about per voxel attributes for a while.

Sounds good to me.

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.

This is, for example, how the per voxel motion blur picks up the velocity attribute from simulations.

Thanks.
That's a little bit what i had in mind but i thought the two volumes would overlap, so i didn't even try.
Very clear explanation, thanks.

I will try it.
when you say “the way to do it now”, you're refering to a certain release?

-d

Thanks heaps for this Jeff, this allows me to work around a problem I've been having with the Volume Sample From File VOP and op references (fixed in 9.1 apparently).

-Drew

It works like a charm. Thanks again!
But i'm very surprised about the volume motion blur.
I thought first that it wasn't implemented yet ( but it turns out it is now, i didn't finish reading this post oops!)

http://www.sidefx.com/index.php?option=com_forum&Itemid=172&page=viewtopic&t=9363 [sidefx.com]
This doesn't seem to be the same technique that the one described in this post. I may be wrong.
So the workflow is just importing a velocity field ( i guess it has to be turned into smoke for visualisation) with a Dop Import, merge it with the other and this is automatically read by Mantra ( vel.x, vel.y and vel.z), right?
( of course turning on geometry blur and motion blur)

-d

Yes, you just have to objectmerge or dopimport the velocity field and merge it with the density field. vel.x, vel.y, and vel.z will be bundled up in the vector vel which Mantra recognizes for velocity fields.

Note you do not have to use Smoke Visualization. Instead of specifying smoke/vel/Visualization, directly specify smoke/vel. This will bring in the field as a volume primitive regardless of visualization settings. This is useful as you likely are playing around with visualization when testing the sim and don't want to worry about setting it back to smoke for the actual real sim.

Last question: is it possible, and if not, wouldn't it be extremely useful to be able to color the volumes NON-uniformly in the viewport to preview textures/gradients on volumes?
I saw that with the primitive SOP volumes have a “Rainbow” display mode that make it look technically possible.
( i ask that cos I'm setting up some visualisation tools to pre-visualize textured volumes through isosurfaces/sprites ( with the ability to use multiple input fields) but it's not the same…

Such a visualization would be very useful. There is no current built-in way of doing that, sadly. The closest would be to use the HDK to write your own visualization using the GR_RenderHooks, but that is not for the faint of heart.

RFE: 28340

- Jeff

Jeff, while we're talking about volumes and shaders, is there currently a way to compute the gradient of a volume in a shader that doesn't involve first writing the volume out to file and using the Volume Gradient from File VOP ? I notice that the volume shaders aren't using a normal vector for shading at the moment, instead they are just using the y-axis (eg the illuminance construct in billowy smoke).

-Drew

IIRC, I think if you access N in a shader you'll get the gradient of the density field. (As for calculating gradients of any of the other Volumes, I'm not sure.)

I thought that as well but N is coming in as {0,0,0}. Maybe it's a bug ? I'm using 9.0.768.

update: nix the above, I was doing something else wrong in the shader I'm building…

-Drew

On further investigation I think I have found a bug. I've submitted it to support and I'll post an update here if I get more info (even it is only to prove that I'm sadly mistaken :-)).

-Drew

It was a bug, normals are broken at the moment (N == 0 a lot of the time). I'm told it's fixed in 9.1.

-Drew