"Kenneth" <kdw### [at] gmailcom> 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

It's not fog, but I see plenty of turbulence:

https://vimeo.com/241007433


How cool is THAT?!

Post a reply to this message