vex pyro modifier

[itriix]

**** FIXED ****

Hi everyone, i'm having some weird issue with the VEX Pyro shader that never used to occur before recently. Say I create some smoke, apply the VEX Pyro shader, then create a FIELD MODIFIER... Say I check "range mapping", and leave everything at defaults (which means values of 0 are 0 and values of 1 are 1)... essentially meaning, NOTHING should happen. After that, I go to Smoke tab, and apply my Modifier to the Density Field Modifier... It EATS away the smoke! This makes no sense.

After playing with it for a while, if instead i make the interpolation graph go from 1 at position 0, down to 0 at position 1, IT gives the result that SHOULD be seen in the top example. So, it seems as though, somewhere, the VEX Pyro shader, Custom Field Modifier's Interpolation graph got reversed? Would anyone else be able to verify the steps I just did, or point out something really stupid that i'm doing here. This seems very crazy to me.

Recap:

default VEX Pyro shader applied to smoke.

if I render, I get "smoke A"

create a Field Modifier, Activate it, name it "My Mod"

Base Field = density

check "Range Mapping" with Field and Target Range left at defaults of Min 0 and Max 1

Then leave the interpolation graph as it's default (a linear progression, from values of 0 at position 0 UP to values of 1 at position of 1 - > going from left to right)....

apply "My Mod" to the Smoke Density Field Modifier Pulldown.

Then render it, THE SMOKE IS EATEN AWAY!

Then do the same thing as above except reverse the interpolation grap. A linear progression going from left to right as values of 1 at position 0 down to values of 0 at position 1....

apply,

render

The smoke is NORMAL (as if no real modifier had been applied, which is what you would expect from a DEFAULT MODIFIER with default setup... but this one is REVERSED interpolation instead though.

Thanks for your help everybody

Jonathan

Edited March 16, 2010 by itriix

[Mario Marengo]

I don't have time to create a test case right now, but if you haven't seen this behaviour before, then it's probably caused by the field values being fed to the modifier -- i.e: the field that you're applying the range re-mapping to.

AFAIK, the shader hasn't changed since the H10.0 release, so unless there's been some big change to some vex function (like fit(), but I don't think there has), the shader shouldn't suddenly behave differently. Can you post a simple setup that shows the bug?

[itriix]

Hey Mario,

Here is a .hip file. It occurs even with a default pyro simulation... when I create a custom field modifier and apply it.

In the scene, just run the sim out for a few frames. Then in the Vex Pyro shader, in the Smoke tab, render with no modifiers to density (turn off My Mod). This will give you default smoke without mods. And then, turn on My Mod in the density Modifier pulldown, render, this will give you an "eaten up version" of the smoke. Funny thing is, if you then go to the Modifiers tab, and look at "My Mod"... it's set to all Defaults. With a linear interpolation going from 0 to 1 as it should be, which would mean (no modification)... Then lastly, reverse the interpolation and render. (have the My Mod interpolation graph go from, 1 down to 0) and then you will get the "non modified version" that you should get values going from 0 to 1, not 1 to 0...

If i did something randomly stupid in here, sorry! Sometimes, it's easy to get cracked out but i'm really sure, that i'm doing this right.

Cheers,

Jonathan

(ps, one more thing i noticed, if i do a render of a non-modified smoke, and then do a render of the modified smoke (reverse) in this case, to try and get the exact same NON-Modified smoke look, the two smokes look a bit different, not sure what is up with that either... i think i may have noticed that before, but just never worried about it really)

[itriix]

=) and as always, i forgot to include the hip in the last post... guess they still haven't fixed the upload ability in the edit post function on here still!

Cheers,

Jonathan

pyro_error_test_mario.hip

[Mario Marengo]

I only spent a couple of minutes on this, so I might have missed something, but I don't see anything wrong going on. I think the problem you're seeing is due to a misunderstanding of how the mods behave.

All mods act as multipliers to the thing they "modify". So that, if there is some float-valued parameter (let's call it 'P') with a "Mod" attached (say 'M'), and this mod is set to something other than "None", then the result will be P * M.

In the case of the "density field" parameter you have the same thing -- the parameter itself, which selects the field that will be interpreted as "density", and an associated modifier which, when set to something other than "None", will scale the chosen density field.

Now, if the selected density field is left at default (i.e: "density") and the modifier that's applied to it is a default modifier (which also defaults to the field "density" and a range mapping that returns the identity), you end up with density = density², which will crunch all the mid values, making parts of it "disappear" (this was the case in your test hipfile).

So, some illustrative combinations and their effects:

1. Field: density, Mod: none. Result = density

2. Field: IdentityMod, Mod: none. Result = density.

3. Field: density, Mod: IdentityMod. Result = density*density

(example images rendered at frame 80)

I'm also attaching your hip file with *default* shader settings showing these combinations (what you've been calling "default" is nothing like the default: it has all kinds of curves for the range mapping -- to see the defaults, plunk down a Vex Pyro shader).

pyro_error_test_mario2.hip

Hope that helps.

Cheers!

[itriix]

You're explanation cleared up everything. I was misunderstanding how the Mods work.

Thanks so much,

Jonathan