Jump to content
aracid

Error With Factoring Color Into I3d

Recommended Posts

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

post-585-1132821198_thumb.jpg

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

post-585-1132821211_thumb.jpg

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 :blink:

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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}

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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);
}

post-136-1132914996_thumb.jpg

Share this post


Link to post
Share on other sites

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

thanks guys for all the help :)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×