 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Since we are on the subject would it be possible to add color mapping
to the fog operation. I have on more than one occassion wished I could
add a gradient color map to a ground fog as opposed to having to use
several layers of fog to achieve the same effect. Extending that to
include image mapping onto fog would be definite bonus.
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ummm.... may I suggest media?
Yes, media is slower. That's because it can handle stuff like this. Fog
can work because it is uniform throughout so it only takes one calculation.
Making it non-uniform means you have to use 'ray-marching' where you sample
it at mutliple places along the way, which of course slows things down
tremendously. (Ground fog is a bit more complicated than constant fog, but
not much more... still only one calculation per ray - no ray marching.)
-Nathan
Ken wrote:
>
> Since we are on the subject would it be possible to add color mapping
> to the fog operation. I have on more than one occassion wished I could
> add a gradient color map to a ground fog as opposed to having to use
> several layers of fog to achieve the same effect. Extending that to
> include image mapping onto fog would be definite bonus.
>
> --
> Ken Tyler
>
> mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp wrote:
>
> Ummm.... may I suggest media?
>
> Yes, media is slower. That's because it can handle stuff like this. Fog
> can work because it is uniform throughout so it only takes one calculation.
> Making it non-uniform means you have to use 'ray-marching' where you sample
> it at mutliple places along the way, which of course slows things down
> tremendously. (Ground fog is a bit more complicated than constant fog, but
> not much more... still only one calculation per ray - no ray marching.)
>
> -Nathan
I am sorry Nathan but I do not like your reply. I wanted you to tell me
that it would be an easy feature change and will render much faster than
media will.
BUT !! Don't lie to me :-)
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 17 Jun 1999 05:40:59 -0700, Ken <tyl### [at] pacbell net> wrote:
>
> Since we are on the subject would it be possible to add color mapping
>to the fog operation. I have on more than one occassion wished I could
>add a gradient color map to a ground fog as opposed to having to use
>several layers of fog to achieve the same effect. Extending that to
>include image mapping onto fog would be definite bonus.
Hmmm... Image mapping onto fog....
Do you want to create something like Batman's "Bat Signal" ? :)
... or maybe show the "Face of God" in a cloud formation (fog) ?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Glen Berry wrote:
> Hmmm... Image mapping onto fog....
> ... or maybe show the "Face of God" in a cloud formation (fog) ?
Mapping my face onto fog is a good idea but not what I originaly
intended :-)
I was actually thinking about spectral entities like ghosts, wraiths,
and the like. A little imagination would certainly come up with many
useful applications for this feature.
To sleep perchance to dream...
--
Ken Tyler
mailto://tylereng@pacbell.net
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Glen Berry wrote:
> >
> > ... or maybe show the "Face of God" in a cloud formation (fog) ?
>
> Mapping my face onto fog is a good idea but not what I originaly
> intended :-)
>
Knew you were a god Ken, but THE "God"? Never! <chuckle>
Signed,
demigod Bob
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote in message <3769F90A.6494A098@pacbell.net>...
>
> I was actually thinking about spectral entities like ghosts, wraiths,
>and the like.
Might this evolve into a "Horror" theme image?
Which reminds me, I gotta go find that inspiration now...
Margus
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The mighty Ken wrote:
> >
> > Since we are on the subject would it be possible to add color mapping
> > to the fog operation. I have on more than one occassion wished I could
> > add a gradient color map to a ground fog as opposed to having to use
> > several layers of fog to achieve the same effect. Extending that to
> > include image mapping onto fog would be definite bonus.
and Nathan Kopp (for it was he) responded:
> Ummm.... may I suggest media?
>
> Yes, media is slower. That's because it can handle stuff like this. Fog
> can work because it is uniform throughout so it only takes one
calculation.
> Making it non-uniform means you have to use 'ray-marching' where you
sample
> it at mutliple places along the way, which of course slows things down
> tremendously. (Ground fog is a bit more complicated than constant fog,
but
> not much more... still only one calculation per ray - no ray marching.)
Well, actually, I can see the possibility of a fog_map [syntactically
equivalent to a color_map except that the index values would probably be
unbounded] without ray-marching, fast, and true to the fog philosophy.
Basically, it would integrate through the color table, doing one calculation
for each separate entry.
EG: fog_map{[-50 color Red] [0 color White] [0 color Clear]}}
would represent a fog that was red from -50 units down, faded to white
between -50 and 0, and suddenly stopped at 0. Fog density is a linear
function of position, and hence the amount of fog color in the pixel can be
found by one (piecewise, with up to n+1 sections if there are n entries in
the map) integration for each primary color. The integral is, of course,
done at coding time, as with the existing fog.
So instead of (as now) having one channel's intensity determined by
dl = - l rho dx [this is for a black fog; for
l/dl = - rho dx any other color work with the difference]
log(l) = - rho x + c
l = K exp(- rho x)
it would be
dl = - l rho(x) dx
l/dl = - (ax+b) dx [a,b determined from fog_map]
log(l) = -(ax^2/2 + bx + c)
l = K exp(-(ax^2 + bx))
-practically no harder to calculate.
If the ray travels a distance D from camera to object, and the camera is
at height H relative to the fog direction and fogmap while the object is at
height h,
we first go through the fog_map from the appropriate end until we find an
interval containing the object, whose color is determined. We then see if
the camera or the end of the map interval comes first.
Whichever does, we determine, for each color component, coefficients a
and b such that
fog.r-original.r == a.r*distance + b.r
fog.b-original.b == a.b*distance + b.b
-etc
on the interval. We then compute
k = exp(-(a*d*d/2 + b*d)) /* proportion of original channel value left
color.r = fog.r*(1-k) + color.r*k
and repeat, interval by interval, until we reach the camera.
I may mave made some minor mistakes here but the idea ought to work.
Turbulation would be somewhat ad hoc, but (eg) moving the end point
ought to work fairly well. Because fog is, well, foggy, the details would
not be too important. There aren't a zillion distinctive things you can do
to fog, so this would cover most of the options as far as you could tell by
eye.
-Robert Dawson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Looks pretty good. Of course, this is limited to the gradient color_map.
The computation and effect would be similar to multiple layers of ground
fog, although the syntax of this is a bit nicer.
-Nathan
Robert Dawson wrote:
> Well, actually, I can see the possibility of a fog_map [syntactically
> equivalent to a color_map except that the index values would probably be
> unbounded] without ray-marching, fast, and true to the fog philosophy.
> Basically, it would integrate through the color table, doing one calculation
> for each separate entry.
>
> EG: fog_map{[-50 color Red] [0 color White] [0 color Clear]}}
>
> would represent a fog that was red from -50 units down, faded to white
> between -50 and 0, and suddenly stopped at 0. Fog density is a linear
> function of position, and hence the amount of fog color in the pixel can be
> found by one (piecewise, with up to n+1 sections if there are n entries in
> the map) integration for each primary color. The integral is, of course,
> done at coding time, as with the existing fog.
>
> So instead of (as now) having one channel's intensity determined by
>
> dl = - l rho dx [this is for a black fog; for
> l/dl = - rho dx any other color work with the difference]
> log(l) = - rho x + c
>
> l = K exp(- rho x)
>
> it would be
>
> dl = - l rho(x) dx
> l/dl = - (ax+b) dx [a,b determined from fog_map]
> log(l) = -(ax^2/2 + bx + c)
>
> l = K exp(-(ax^2 + bx))
>
> -practically no harder to calculate.
>
> If the ray travels a distance D from camera to object, and the camera is
> at height H relative to the fog direction and fogmap while the object is at
> height h,
> we first go through the fog_map from the appropriate end until we find an
> interval containing the object, whose color is determined. We then see if
> the camera or the end of the map interval comes first.
>
> Whichever does, we determine, for each color component, coefficients a
> and b such that
>
> fog.r-original.r == a.r*distance + b.r
> fog.b-original.b == a.b*distance + b.b
> -etc
>
> on the interval. We then compute
>
> k = exp(-(a*d*d/2 + b*d)) /* proportion of original channel value left
>
> color.r = fog.r*(1-k) + color.r*k
>
> and repeat, interval by interval, until we reach the camera.
>
> I may mave made some minor mistakes here but the idea ought to work.
>
> Turbulation would be somewhat ad hoc, but (eg) moving the end point
> ought to work fairly well. Because fog is, well, foggy, the details would
> not be too important. There aren't a zillion distinctive things you can do
> to fog, so this would cover most of the options as far as you could tell by
> eye.
>
> -Robert Dawson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nathan Kopp <Nat### [at] Koppcom> wrote (re a fogmap idea that I'm too busy
[lazy?]
to implement, at least till I have time to work out how to compile POV under
Borland 5)
> Of course, this is limited to the gradient color_map.
Yes, it would be. But it would be cheap & fast.
> The computation and effect would be similar to multiple layers of ground
> fog, although the syntax of this is a bit nicer.
Also, this allows fog layers to have a lower bound, abrupt edges, and
linear rather than exponential gradient - without checking the dox, I think
this would be
hard to do with multiple layers.
-Robert Dawson
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
