 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
(Rendered in v3.7.1 beta 9, but I assume that v3.7.0 would be identical.)
This is a follow-up to the post, "problem with turbulence in fog" at
http://news.povray.org/povray.general/thread/%3Cweb.5a2502e480800e7e89df8d30%40news.povray.org%3E/
I decided to test POV-Ray's current 'fog' code, with some animation
experiments-- various changes to the fog parameters, to see what's going on when
using its 'turbulence' feature and what limitations it has. This multi-part
animation uses the 'mist.pov' demo file, which is itself just a static scene,
set up with ground fog. I would suggest rendering that scene first, simply to
see what it looks like.
IMO, the fog/turbulence parameters in that file are not what they should be--
perhaps due to some underlying 'fog' or 'turbulence' code-changes over the
years(?) after the mist file was written. This also applies to the other demo
scenes: foglayr.pov, foglyr2.pov, etc.
The main result from all this is that turbulence doesn't show the same effects
in FOG as it does in pigments, media, etc., although its default values appear
to be the same.
From what I can tell, fog/turbulence appears to be a kind of sophisticated
'camera-projection effect', onto object SURFACES-- not actual volumetric fog,
even though it looks very similar to media. This pseudo-3D effect depends on
where the camera is positioned relative to the 'static' fog and scene objects,
and if the camera is inside the fog or outside it. However, turbulence behavior
is strangely affected by the geometry of the objects; the animation examples
show the rather odd behavior of the fog 'conforming' to the particular geometry
its projected onto. (That's my theory from visual results, anyway.) On
reasonably flat surfaces facing the camera, it looks fine; otherwise, not so
fine. This seems to be a subtle flaw.
Fog/turbulence was apparently never designed with animation in mind, as there is
no way to translate it (other than changing the 'sky' vector.) Any movement of
the fog in these animated examples is due to its other parameters-- which are
limited and hard to control.
For most of the examples (except Part 1), I made the following changes to the
mist file, to get a clearer visual result as the fog parameters change. The
scene itself will look quite strange, though:
* no lights
* all pigments are pure black
* finish {ambient 0 emission 0 diffuse 0}
* no normal or reflection for the 'floor' object
* lots of vertical cylinders randomly placed, to see how their appearance is
affected by any 'volumetric' fog effects
THE VIDEO:
PART 1:
This is a decent example of what the fog parameters *should* be in the normal
scene, to actually see the effect of turbulence. (A moving camera definitely
helps! ) I used...
fog{
color Gray70
fog_type 2
fog_alt 0.1
fog_offset 1.4
distance 9.5
turbulence 1.9
turb_depth 0.9 // this parameter is missing from the mist file, and is
// an important one
omega 0.4
lambda 2.0
octaves 6
}
Two other minor changes to the file, only for visual clarity:
* no 'reflection' in the 'floor' object
* sky_sphere { pigment {color .1*MidnightBlue}} // to darken the sky
The only odd thing about this animation result is that some of the turbulent
'volumes' of fog (those that seemingly appear 'above' my particular fog_alt +
fog_offset level) disappear as the camera passes that level-- in fact, above
that demarcation line shows no turbulence effect at all, when the camera is also
above it. My own expectation has always been that this shouldn't be the case,
that the 'upper surface' of the fog should also show some turbulence. Fog isn't
MEDIA of course (AFAIU), but the effect looks odd nevertheless. Perhaps it's a
direct result of the 'projection' idea in some way: When the camera is above the
fog level, any turbulence effect 'outside' the fog disappears.
PART 2:
This uses the fog parameters *as they are* in the mist file, with only a
changing turbulence value. Result: There is *almost* no visual difference that
I can see-- which is apparently not what the mist scene (or the documentation)
would suggest when using turbulence.
PART 3:
This is also a good example of fog parameters, again with only a changing
turbulence value. It does show 'volumetric' changes to the fog-- some areas
thick, some areas thin. What's odd is that the turbulence effect is being
SCALED, and MOVED toward some central point. (I *think* that point is the
scene's origin, <0,0,0>. ) So this is not really a good way to animate the
movement of the fog, as there's no control over it. The squashed/stretched
shapes of the 'bright splotches' on objects are another example of the (flawed?)
'projection' idea. They also look overly-bright, given that the objects are all
black... but that's a minor quibble.
PART 4:
Only the TURB_DEPTH changes. This parameter appears to 'thin out' the fog-- that
is, it causes the many isolated 'high-fog' volumes to shrink and become more
defined (resulting in more clear space between those volumes.) But that behavior
seems to differ (?) somewhat from the docs' description of turb_depth: "...the
fog turbulence may be scaled along the direction of the viewing ray using the
turb_depth amount". IMO, 'scaling' should mean a *size* increase/decrease of the
overall effect and the many turbulent 'volumes' -- unless the scaling refers to
the observed effect. The docs aren't clear about this.
PART 5:
This has TWO changing parameters: fog_offset and turbulence. Also, the
fog_offset and fog_alt values are kind of 'reversed' here, to get a sharp fog
cutoff at a certain height. From what I see, this also causes all the fog to
have the SAME density, with no fade-out in the +y direction. (An alternate test
with an orthographic camera seems to confirm this.) That's a nice discovery--
but the equation in the docs for determining density changes is only for heights
*above* fog_offset-- which is not the case here-- so I'm not sure about it.
BTW, the initial black cutoff in this example is naturally due to the absence of
lights and bright pigments in the scene-- and to the fact that the camera is
positioned higher than the fog. There's no fog above that height to brighten
things up, until fog_offset 'cimbs' to the mid-point of the camera view; then
the fog 'envelopes' the camera. But the 'white splotches' on the background
object (the bridge) look incorrect again; they are not only following the bridge
contours, but the top of the fog layer doesn't reach anywhere near that height.
There *is* intervening fog between camera and object at that point in the
animation, so *something* should appear there, I admit; but those splotchy
shapes look wrong.
Post a reply to this message
Attachments:
Download 'mist_experiments.mp4.mpg' (3884 KB)
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
> PART 5:
>.... There's no fog above that height to brighten
> things up, until fog_offset 'cimbs' to the mid-point of the camera view...
Sorry, that should be "...CLIMBS to the mid-point..."
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
My impression is that the description of the fog turbulence feature in
the docs is written from a developer's perspective, describing the
parameters' effect on the algorithm, rather than their effect on the result.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
>
> From what I can tell, fog/turbulence appears to be a kind of sophisticated
> 'camera-projection effect', onto object SURFACES-- not actual volumetric fog,
> even though it looks very similar to media... However, turbulence behavior
> is strangely affected by the geometry of the objects; the animation examples
> show the rather odd behavior of the fog 'conforming' to the particular geometry
> its projected onto.
If the idea of fog being a 'projection effect' is true, then fog/turbulence
behavior reminds me very much of Rune's old ILLUSION.INC include file (but
possibly more sophisticated.)
AFAIU, POV-Ray uses matrices for all of it behind-the-scenes calculations of
transformations, scalings etc. Rune's file also uses a matrix for his 'illusion'
-- but with NO distortion of the 'projected' image/texture onto complex-shape
scene objects. I'm certainly no expert at matrix math, but my guess is that
fog's matrix calculations are not quite right re: the fog's splotchy shapes
bending/distorting/scaling around object contours (when they should be 'immune'
to that, IMO.)
Of course, all of this is my own supposition, as I don't really know how fog
works; but I can give a mind's-eye example of what I mean: In Part 1 of the
animation, assume that there is a nice-looking isolated 'fog cloud' shape
visible on the underside of the bridge. As the camera moves from left to right,
that cloud also appears to move, and with the proper perspective for it's
apparent position in space. So far, so good. But then a problem arises when the
cloud passes over some other complex geometry in the farther distance, or moves
'off the bridge': That part of the cloud suddenly distorts and scales down,
instead of compensating for the different distances and shapes. (For *really*
distant objects, turbulence as-is may be scaling down so small that a screen
pixel can't show the effect-- blurring the tiny clouds together. But the fog
density probably hides that anyway.) Instead, the cloud should at least retain
its own shape and size, no matter what geometry (or distance of that geometry)
it encounters. That's basically what Rune's Illusion code does.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 08.12.2017 um 22:59 schrieb Kenneth:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
>>
>> From what I can tell, fog/turbulence appears to be a kind of sophisticated
>> 'camera-projection effect', onto object SURFACES-- not actual volumetric fog,
>> even though it looks very similar to media... However, turbulence behavior
>> is strangely affected by the geometry of the objects; the animation examples
>> show the rather odd behavior of the fog 'conforming' to the particular geometry
>> its projected onto.
>
> If the idea of fog being a 'projection effect' is true, then fog/turbulence
> behavior reminds me very much of Rune's old ILLUSION.INC include file (but
> possibly more sophisticated.)
From what little I know of fog turbulence, this has nothing to do with
any intended projection effect; rather, the algorithm /happens/ to make
it appear projection-ish.
In media, a pretty realistic effect is achieved by taking multiple
samples along the entire ray's length, thus effectively evaluates the
"entire" 3D turbulence space.
Using this approach, the "granularity" of the turbulence (i.e the
average distance between dark and bright regions) varies across the
resulting image depending on the depth, in accordance with the usual
perspective: Just like nearby objects are rendered larger in 2D image
space than far-away objects, the granularity of the turbulent media in
front of nearby objects is rendered larger in 2D space than in front of
far-away objects.
Now this multi-sample approach is obviously expensive in terms of render
performance. Fog is designed to be much cheaper (at the cost of
realism), taking only a single turbulence sample along each ray's
length. So in essence a 2D "sheet" of the turbulence space is evaluated.
Now a naive approach would be to make this 2D sheet a plane or spherical
surface at a fixed distance to the camera. However, this would render
the turbulence's "granularity" uniform in 2D image space, contrary to
the expected perspective effect.
To fix this, the 2D sheet of turbulence evaluated by POV-Ray is not
flat, but rather adapts to the depth of the scene: In areas of the image
where objects are close, POV-Ray takes a sample of 3D turbulence space
quite close to the camera, whereas where objects are far away, POV-Ray
takes a sample of 3D turbulence space quite far away. In this manner,
turbulence granularity does somewhat match the expected perspective effect.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> From what little I know of fog turbulence, this has nothing to do with
> any intended projection effect; rather, the algorithm /happens/ to make
> it appear projection-ish. [snip]
>
Your explanation of fog vs. media is completely understandable, as well as the
various paradigms used-- and it has me thinking about an alternate approach to
the problem of fog's object/perspective distortions. It's based on the
'projection' idea, but I need to think about it thoroughly, and about any
possible ramifications...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> Now this multi-sample approach [with true MEDIA] is obviously expensive in
> terms of render performance. Fog is designed to be much cheaper (at the cost
> of realism)...
Just a thought...
The various fog files were written quite a long time ago (I assume, although
there are no origination dates in the files themselves.) Rendering scenes back
then was a slow process.
Modern computers are SO much more powerful and faster now-- so might a re-think
of fog's basic code/paradigm be possible or appropriate? Not as true media of
course, but some type of better-thought-out approach (possibly a bit more
expensive, computation-wise), to mitigate some of fog's current limitations? My
own thoughts go in the 'camera projection' direction-- which would probably
require a good deal more sophistication than Rune's Illusion approach-- but
that's just one naive(?)idea.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 09.12.2017 um 22:40 schrieb Kenneth:
> The various fog files were written quite a long time ago (I assume, although
> there are no origination dates in the files themselves.) Rendering scenes back
> then was a slow process.
>
> Modern computers are SO much more powerful and faster now-- so might a re-think
> of fog's basic code/paradigm be possible or appropriate? Not as true media of
> course, but some type of better-thought-out approach (possibly a bit more
> expensive, computation-wise), to mitigate some of fog's current limitations? My
> own thoughts go in the 'camera projection' direction-- which would probably
> require a good deal more sophistication than Rune's Illusion approach-- but
> that's just one naive(?)idea.
Not sure what you mean by "camera projection" in this context, but right
now I'm rather skeptical.
I'm quite sure a more sophisticated turbulent fog would really need
multiple samples along the ray -- which is pretty much what media does.
So since a lot of thought has already been put into that feature, I
wouldn't be surprised if a revamped fog feature would turn out inferior
to media in quality without providing any benefit in efficiency at all.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
clipka <ano### [at] anonymousorg> wrote:
>
> Not sure what you mean by "camera projection" in this context, but right
> now I'm rather skeptical.
>
This is one of those times when I wish I knew how to write source code (and to
compile such experiments). :-( I have a reasonably(?) clear idea of the
overall idea in my mind's eye... which I keep working on as new problems arise
re: my conception of it. But turning the idea into a workable *solution* is
quite another thing. And my understanding of matrix calculations is presently
sketchy, at best.
I have a tendency to think about maths problems in a kind of 'visual' way. Who
knows, I may resort to a step-by-step visual explanation via Photoshop!
I do see what you're getting at-- having to take multiple ray-samples of the
'fog' to get correct depth/density of the turbulence patches, if I want my
'camera projection' approach to even work-- but I'm trying to work around that
bottleneck, to avoid it...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> This is one of those times when I wish I knew how to write source code (and to
> compile such experiments). :-( I have a reasonably(?) clear idea of the
> overall idea in my mind's eye... which I keep working on as new problems arise
> re: my conception of it. But turning the idea into a workable *solution* is
> quite another thing. And my understanding of matrix calculations is presently
> sketchy, at best.
Most of what can be done in source, can be done in SDL - one way or another,
albeit much more slowly.
Don't shoot for a full implementation, but a "proof of concept"
> I have a tendency to think about maths problems in a kind of 'visual' way. Who
> knows, I may resort to a step-by-step visual explanation via Photoshop!
Lots of time you can use a spreadsheet to lay things out and give you
instantaneous results, and have a few extra calculations to keep a check on the
intermediate and final results.
Think of frames in an animation or different camera views as just another block
of cells using different numbers... Then you can see them all at once!
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
