InputField bounds

[hdarren]

@Chad

Otherwise when the PRT Ember samples the SIM Ember Spacious it will grab black for the color. Likewise, when the color is advected in the simulation, the red apple skin turns black when it leaves the SIM Ember Tight field.

I’m finding it difficult to visualize the problem. Can you post a simple animation showing where the undefined values are coming into play?

@Chad

Shouldn’t color (and everything else) be density weighted? So if you are advecting and blend 2 voxels together, you shouldn’t be blending the colors, but the colors weighted by the density, right?

That would make the most sense in a situation like this I think, but once again I don’t really get the setup. What exactly is being blended?

[hdarren]

I think I understand the issue now. As the color is advected, the linear interpolation that is reconstructing the discretized grid is bringing in black colors around the edges. I’m not sure if the Density can be used to control that (it might, I think I get the intuition behind it). I think I understand that you would want the lerp reconstruction to avoid using data that is undefined (ie. Density == 0) and re-weight the other defined values appropriately.

When you render the particles in Krakatoa, are you seeing black edges? I would expect them to not be that big of a deal since the same lerping errors would make the Density quite low in these same regions and therefore practically invisible.

Another option you could try in this case is to advect around the original position instead of the quantities. For example, you could advect around a channel initialized like InputChannel:Position -> Output:MyChannelName and then in your PRT Ember you could use the Output:MyChannelName as the position that is fed into the InputField that is sampling your high-res apple. This would prevent the lerp from blending with undefined regions because every part of the field would have a well-defined value. This technique fails when you have some sort of animated addition of Density like a smoke emitting object.

[hdarren]

@Chad

I just don’t know if we need Density to be doing anything else in the simulation. Does it affect how much a force is converted to velocity?

Density doesn’t mean anything at all to the Sim Ember object, though your idea about forces has some merit in certain situations. Only the PRT Ember object relies on Density to determine where to seed particles.

EDIT:

@Chad

They render as darker red. I supposed the density is being lerped the same way, so the blackest particles are the faintest, but the ones that are 80% original red and 20% black still end up darker and only 20% faded off.

I guess this means we need to look into ways of preventing that blurring around the edges. In this case here, you could always divide the Color by the Density value (where its not 0 anyways) since we know the density should be 1 and the only reason it isn’t is due to reconstruction errors.

[hdarren]

The current solver (FFT Solver) only modifies the Velocity field to be divergence free. We expect to provide more sophisticated solvers that utilize other field values when creating a Velocity field, but those are not expect in the immediate future. Candidates for other solvers include:

[]Occlusion geometry[/]
[]Density variation[/]
[]Temperature[/]

Please suggest more that come to mind.