Error With Factoring Color Into I3d

[aracid]

hey all

busy trying to factor color on per metaball into the standard i3d shader

it, looks ok, but when i set the step size down, the colors intensity is influenced.

this is how i factored the color into the shader

fclr += opac * ((colorPP   * diffuseColor ) + (globalIncan*incandecence));
fclr += tau * lclr;

this is my result with high step size, around .08

this is my result with low step size, around .03

ive used mattrib to read the data off the particles,

but how how should color be factored into the fog shader to avoid this intensity increase when changing the step size?

animation test 001

thanks in advance

aracid

[lisux]

I think that your color compositing code is not bad, it depends what do you want of course.

The problem is that your incandescence parameter is additive, you are adding color not multiplying color. If you use multiple your diffuse component by you incandescen, it is say use the incandesce it will work like a filter. Maybe this is what you want.

The difference is that when you use greater step sizes you get less information about your volume, so you add less incandesce color. Nvertheless when you use smaller step size more incandesce color is added because you sample more volume.

Maybe one solution is to use the globalIncandesce parameter to control it.

I am curious, the incandesce and colorPP are particle attributes that yo uare saving in your 3d textures?

Hope this helps

[aracid]

I am curious, the incandesce and colorPP are particle attributes that yo uare saving in your 3d textures?

Hope this helps

22830[/snapback]

hey lisux

yes i am writing this data out to the i3d file.

thanks for the reply and the info :-)

i found a problem in my code and fixed the problem by clamping the mattrib function that fetches the data off the colorPP.

     
incandecence = clamp (color_function (fname, "incandecence", ps, filter, fwidth), {0,0,0}, {1,1,1});
densityoffPP = clamp (dfunction (fname, "densityPP", ps, filter, fwidth),0,1);
colorPP = clamp (color_function (fname, "colorPP", ps, filter, fwidth),{0,0,0},{1,1,1});
opac = density * clamp(dfunction(fname, channel    , ps,filter , fwidth), 0, 1) * densityoffPP;
externalClr = colorPP * diffuseColor;
fclr += (tau * lclr * externalClr) + ((globalIncan*incandecence) * opac);

thanks once again

aracid

[AndrewVK]

Maybe i am wrong but...

All attributes taken by "mattrib" becomes premultiplied by density.

So...if "color" = {0.5,0,0} and "density" = 20

you will get "color" = {10,0,0}

[aracid]

Maybe i am wrong but...

All attributes taken by "mattrib" becomes premultiplied by density.

So...if "color" = {0.5,0,0} and "density" = 20

you will get "color" = {10,0,0}

22836[/snapback]

hey andrew,

thanks for the info, its an interesting point,

is that by default ?

i havent factored density into my colorpp, however i also have a densitypp.

all the best

aracid

[AndrewVK]

Yes...it happens by default.

So You need to:

1. Take density

2. Take color

3. divide color by density (unpremultiply)

4. clamp density to 1

5. clamp color to 1

[lisux]

Yes...it happens by default.

So You need to:

1. Take density

2. Take color

3. divide color by density (unpremultiply)

4. clamp density to 1

5. clamp color to 1

22841[/snapback]

Hey Andrew, are you sure that all the attributes taked by mattrib are premultiplied by density?

I say it because mattrib and mdensity are complitely different calls.

normally you use mattrib with the point of the metaball with the great density, and after you can multiply by the density, but in the docs don't appear anything about premultiplied values in the mattrib section.

I use clamp functions in my i3d shaders too, one of the reasons is that mattrib with vector values something return wierd values.

[AndrewVK]

Yes i`m sure.

Test this simple i3dgen:

#pragma hint    clr hidden

image3d
yesiamsure( string  color_name = "Cd";
                  export  vector  clr = 0;
          )
{
  clr = mattrib(color_name,P);
  density = mdensity(P);
  if (clr.r > 1 || clr.g > 1 || clr.b > 1 ) printf("Cd = %g\n",clr);
  density = clamp(density, 0, 1);
}

[aracid]

aaaagggg, those pictures bring back memories of late confused nights .... deamons out!!

thanks guys for all the help

[lisux]

Yes i`m sure.

Test this simple i3dgen:

#pragma hint    clr hidden

image3d
yesiamsure( string  color_name = "Cd";
                  export  vector  clr = 0;
          )
{
  clr = mattrib(color_name,P);
  density = mdensity(P);
  if (clr.r > 1 || clr.g > 1 || clr.b > 1 ) printf("Cd = %g\n",clr);
  density = clamp(density, 0, 1);
}

22865[/snapback]

I have to test it Andrew, thanks for the info.

Anyway i think that 3d textures are good for blobby like shapes, like clouds or high dense gases, the effect iahven't been able to simulate correctly with 3d textures are fire or fine detailed smoke like cigars smoke, when you need fine detail i think that 3d textures are not the best tool

Even more, you need high resolution textures to get good results at PAL resolution.

I want to try, when i have time , point clouds.

[AndrewVK]

Of course PClouds have some advantage over i3d when deal with dynamic phenomena.

Reused cache...irregular sampling...no need to worry about texture sizes...

even special sop to generate fine PCloud from metabolls (scatter_meta from proto_install.exe)

etc...etc...etc

But!

There is no fast methods to calculate selfshadowing (like "integrate3d" for i3d)

I have posted RFE on some useful functions for PClouds which may help...

i hope someday it will be implemented.

Of course You can use pure raymarcher right now for this, using "sphere based" search engine

but it will increase time of calculation...

espetially if u want to narrow search region to cone manually for better result.

Fortunately fire does not require selfshadowing

So there is a sense to try because it works