fluidVoxelInfo worldspace mapping to voxel index?

[neko]

fluidVoxelInfo should be able to take the worldspace positions of particles, and find the corresponding voxel indices in a fluid texture. I can't make this work, however. I am continually getting OOB errors, no matter what worldspace positions I pass to this command.

I thought
$vector pos = particle.position;
fluidVoxelInfo -os false -v $pos.x $pos.y $pos.z oceanWakeFoamTexture;

would work, but it seems that the x coordinate returned is always wrong, usually around -5000. The y coordinate is correct.

The allowed range of the voxel indices should be 0->resolution-1, right? The wake and foam textures are supposed to be 3D, and you should be able to directly map a particle position to a voxel as long as the particle is within the fluid texture box shown in the viewport. This is how I understand it, but maybe I'm missing something.

[duncanbrinsmead]

You are doing the right thing, however the correct output range of the coordinates is based on the resolution of your fluid, and is an integer, not a float. Also you should check the bounds for particles that are outside the fluid volume.
Try the following:
$vector pos = particle.position;
int $indices[] = fluidVoxelInfo -cb -os false -v $pos.x $pos.y $pos.z oceanWakeFoamTexture1;
if( size($indices) > 0 ){
setFluidAttr -ad -at "temperature"
-xi $indices[0] -yi $indices[1] -zi $indices[2]
-fv .5 oceanWakeFoamTexture1;
}

Duncan

[neko]

The problem is currently not in the output range, but in the input range. If I import, say, High Seas, and create an emitter in the center of the ocean, only particles near the emitter will actually map to valid voxels.

The fluidVoxelInfo will return nothing, because it thinks that the particles are outside the fluid volume. ( -cb on )

int $indices[] = fluidVoxelInfo -cb -os false -v $pos.x 0 $pos.z oceanWakeFoamTexture1;

That only returns a non-zero length array very close to the emitter. The particles are clearly within the ocean, wake, and wake foam fluid bounding boxes. I've even zeroed the y coordinate to double check. The wake and foam fluids are not scaled, but the High Seas ocean is (by default in the example.) It seems that fluidVoxelInfo sees a scaled down version of the foam texture.

I can place an example .mb (or .ma if you prefer) on my website that shows this behaviour.

I know that a lot of this post was redundant, but I'm trying to catch any errors by typing out as much as I can. Somewhat like reading a paper out loud.

Thanks for your help so far.

[neko]

http://www.cs.virginia.edu/~csz9v/maya/emitters.mbhttp://www.cs.virginia.edu/~csz9v/maya/emitters.mb contains HighSeas from the example Fluids, an emitter, and a simple expression on the particles.

The expression adds heat into the wake foam texture if the indices array is non-zero ( a valid return from fluidVoxelInfo )

The per-particle radius is 1 if the particle is in-bounds, and 0.1 if out-of-bounds. You'll see that only young particles, close the emitter, have a radius of one, and are actually mapping from worldspace to texture space correctly.

http://www.cs.virginia.edu/~csz9v/maya/emitters\_scaled.mb has an updated expression, in which the worldspace coordinates are scaled by .01. This appears to map correctly to texture space coordinates, regardless of the actual resolution of the wake texture. Why do you have to scale the worldspace coordinates?

[neko]

Well, since I can correctly map voxels now, (a lbeit without knowledge of why I have to scale the worldspace coords ), I went ahead and tried to add a churning foam effect to the wake of this waterjet propelled boat.

This results were less than I had hoped, but what pretty much what I expected. Adding heat at a specific point in the texture is much like adding a colored dye to watch the direction of flow. I get a drifting puddle like shape, rather than a strip of 'churn' in the rear.

I know that this is what you've said to expect in other posts, and I'm trying to find ways to constrain this puddle to a more rectangular shape. The churn needs to last the entire length of the animation, much like a jet contrail.

Perhaps I should be trying a different approach altogether? I really just want to have a lasting strip of foam behind the boat at this point, which should lessen the number of particles I'll use for spray later.

I've tried setting the velocity at the point I added the heat to -x, and setting the velocity grid to a gradient at -x.

Here's a quick example, with a higher alpha gain, and particles to indicate when the heat is actually being added. Particles start from the middle of the ship, and emit heat as long as they have large radii. As soon as you see the particles drop to dots, they no longer emit heat or velocity.

edited link.
http://www.cs.virginia.edu/~csz9v/maya/test\_vel\_neg\_x.jpg

[duncanbrinsmead]

I checked this out. Your problem is that the units are in meters. A variety of elements in Maya( especially dynamics ) behave badly when the units are not in the default cm. I would always work in cm and translate any calculations you have simply assuming cm to be meters. I've logged a bug on this particular problem.

Duncan

[neko]

Well, yet another reason we can't work in our preferred meters. Oh well. Thanks for clarifying this.

[joojaa]

Ok whats the problem here the prefs are the only place where they say anything about units. As long as you thinks its meters all is fine! So just think of each default unit as meters is tha same thing as changing the default uints to meters except it avoids all nasty problems!

As long as everyone know this its fine (ok when you import stuff you need to scale them down oh well on extra trannsform does the trick)

But why they choose to have such an option in the first place (if its not usable) is beyond me. Just dump it out alltogether and claim it to be unitless instead...

[neko]

We build things as precisely as possible, due to the nature of the business we're in. Stuff can't just look good, it needs to look accurate. This means everything is built in meters to begin with, and our motion data also comes in this form. It's just one less thing I want to deal with.

[joojaa]

Being an eingeneer i can uderstand this. BUt the point is if you feed meter data in a centimeter unit scale animation in the intent that it is meter then your animation andd stuff is as precice as it would be in the meter realm! Its no different maya thinks its working in cm because may thinks it should. You on the otherhand KNOW its meters instead. All your scripts should work as is in any case. No loss of quality. Only forces need to be remapped thats all there is to it!

The rest is from the users point of view exactly the same (the worl doesent change even if the units are named gumbalff for what the user cares. 1 unit is 1 unit no matter what you call them, maya doesnt understand the difference)! Wich is more important, maya working than units being meter in your prefs?

It sounds silly but its true that a 1 unit ball and lignting at cesrtain unit places look the same even scale is set to 1 m or 1 cm. As accurately (theres only a few things it might affect).

[kastef]

This is wicked Duncan and Neko, Thanks!!!

It didn't work right off the mark so I thought I would post what I used to get it working with and integer instead of a vector value.

///////////

int $pos[3] = particleShape1.position;
int $indices[] = fluidVoxelInfo -cb -os false -v $pos[0] $pos[1] $pos[2] fluidShape1;
if( size($indices) > 0 )
{
setFluidAttr -ad -at "density" -xi $indices[0] -yi $indices[1] -zi $indices[2] -fv 0.5 -fr 0.4 fluid1;
}

///////////

I'm trying to figure out if there is a way to soften the fluid that is filled with the desired fluid attribute. For example if you can fill one voxel with a density attribute of .5 and the neighbor voxels with an attribute of .1

The way it stands now is that I get a very dotty emission of fluids from the particles. Which makes sense but I was hoping somebody might have a solution.