I just had an idea. See what you think. There has been much discussion in this group
regarding media and it's shortcomings, particularly with regard to creating a dusty /
smoky atmosphere. This is what I use it for mainly, but usually give up because a) it
takes so long to render, and b) because it often / usually looks too grainy.
My idea is this. Would it not be effective to use similar code to the way that
constant
fog works ( which seems to just change each pixel by a certain amount towards the
chosen
fog colour ), but *only for those pixels that are in line of sight of a light source*.
So
any obstructions would effectively seem to be casting a shadow *onto* the fog. It
seems to
me that this is how a dusty atmosphere looks when light shines in through a window
etc. Of
course the huge benefit of this approach would be a minimal increase in rendering
time.
You could have a parameter for controlling the intensity of the effect ie how near to
white each pixel becomes, a parameter to control how the effect fades as it moves
further
from the light source. I'm not sure how additional lights would affect things..they
could
each add to the intensity where spotlights cross one another, or they could all be
automatically adjusted so an overall effect is maintained, regardless of the number of
lights used.
Finally, the fog could be affected by, for example, a pigment map in a similar way to
a
density map, so that wherever rgbf 1 occured, the fog was clear. This could then be
animated in the usual way to create many atmospheric conditions. Sort of a simpler
Density.

Have I overlooked something here? My idea seems so simple, but sometimes the simple
ideas
work best. I'm not suggesting getting rid of media, as it excels at fires, clouds etc,
but
in my opinion it's overkill in some instances.

Maybe for the next version?

-----------
Andy

Post a reply to this message

.....*AND*  using a small value for the fade, and a high effect intensity...you have
visible light sources glowing beautifully

---------
Andy

Post a reply to this message

Andrew Cocker wrote:
> 
> I just had an idea. See what you think. There has been much discussion in this group
> regarding media and it's shortcomings, particularly with regard to creating a dusty
/
> smoky atmosphere. This is what I use it for mainly, but usually give up because a)
it
> takes so long to render, and b) because it often / usually looks too grainy.
> My idea is this. Would it not be effective to use similar code to the way that
constant
> fog works ( which seems to just change each pixel by a certain amount towards the
chosen
> fog colour ), but *only for those pixels that are in line of sight of a light
source*. So
> any obstructions would effectively seem to be casting a shadow *onto* the fog. It
seems to
> me that this is how a dusty atmosphere looks when light shines in through a window
etc. Of
> course the huge benefit of this approach would be a minimal increase in rendering
time.
> You could have a parameter for controlling the intensity of the effect ie how near
to
> white each pixel becomes, a parameter to control how the effect fades as it moves
further
> from the light source. I'm not sure how additional lights would affect things..they
could
> each add to the intensity where spotlights cross one another, or they could all be
> automatically adjusted so an overall effect is maintained, regardless of the number
of
> lights used.
> Finally, the fog could be affected by, for example, a pigment map in a similar way
to a
> density map, so that wherever rgbf 1 occured, the fog was clear. This could then be
> animated in the usual way to create many atmospheric conditions. Sort of a simpler
> Density.
> 
> Have I overlooked something here? My idea seems so simple, but sometimes the simple
ideas
> work best. I'm not suggesting getting rid of media, as it excels at fires, clouds
etc, but
> in my opinion it's overkill in some instances.
> 
> Maybe for the next version?
> 
> -----------
> Andy

  This topic and the solutions you have suggested were discussed in
some detail back in January. I believe the thrust of the discussion
centered aorund the use of monte carlo sampling and it's limitions.
I tmight have been Nathan Kopp who mentioned tht he has been trying
different sampling methods to be used with the media feature and has
passed on the concerns of people about the process to Chris Young
the pov team coordinator. I guess you could say there is work in
progress to add more functinality to the media process but I have
no confirming data to support this. I do agree that there are some
sampling methods like that used in the previous atmosphere feature that
could add greater funtionality to the current system and it would be
nice to see some improvements in that area.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

HI Ken,

That was quick! Do you have a permanent internet connection, or free local calls? If
so,

Have you had any luck with your consequtive images/

---------
Andy

Ken wrote in message <36E31469.905C54F4@pacbell.net>...

>  This topic and the solutions you have suggested were discussed in
>some detail back in January. I believe the thrust of the discussion
>centered aorund the use of monte carlo sampling and it's limitions.
>I tmight have been Nathan Kopp who mentioned tht he has been trying
>different sampling methods to be used with the media feature and has
>passed on the concerns of people about the process to Chris Young
>the pov team coordinator. I guess you could say there is work in
>progress to add more functinality to the media process but I have
>no confirming data to support this. I do agree that there are some
>sampling methods like that used in the previous atmosphere feature that
>could add greater funtionality to the current system and it would be
>nice to see some improvements in that area.
>
>--
>Ken Tyler
>
>mailto://tylereng@pacbell.net

Post a reply to this message

Andrew Cocker wrote:
> 
> HI Ken,
> 
> That was quick! Do you have a permanent internet connection, or free local calls? If
so,

> Have you had any luck with your consequtive images/
> 
> ---------
> Andy


 I get about 140 hrs. per month fixed rate internet access through my
phone company and a fixed monthly rate for all phone calls to the
dialup connection in my calling area. My phone bill with internet
access and normal phone usage, i.e. no long distance calls, runs less
than $40 a month US. That's less than most US families pay with no
internet connection but have two teenagers in their house.

 As far as the other project I have had no success making it work. Either
I am too dense or there is something wrong with the exapmles given me so
far. I can get the include file method to work but can't seem to figure
out how to use successive images to create height fields as I am tring
to do.
  The HF statement want's a syntax of:

height_field {"tga "xxx.tga"  stuff }

 I can't figure out how to use the code provided to satisfy it's need
for the - tga "xxx.tga" - part of the syntax. If you have any suggestions
I am willing to listen to your advice.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

Ken wrote in message <36E### [at] pacbellnet>...
>
> I get about 140 hrs. per month fixed rate internet access through my
>phone company and a fixed monthly rate for all phone calls to the
>dialup connection in my calling area. My phone bill with internet
>access and normal phone usage, i.e. no long distance calls, runs less
>than $40 a month US. That's less than most US families pay with no
>internet connection but have two teenagers in their house.
>


Damn..why don't we get that over here? I have a free internet connection, but British
Telecom charge lots and lots


> As far as the other project I have had no success making it work. Either
>I am too dense or there is something wrong with the exapmles given me so
>far. I can get the include file method to work but can't seem to figure
>out how to use successive images to create height fields as I am tring
>to do.
>  The HF statement want's a syntax of:
>
>height_field {"tga "xxx.tga"  stuff }
>
> I can't figure out how to use the code provided to satisfy it's need
>for the - tga "xxx.tga" - part of the syntax. If you have any suggestions
>I am willing to listen to your advice.
>

Presumably you'll have tried

height_field { tga INCF stuff }

from my solution. I'll have a go myself and get back to you shortly if I come up with
a
solution.

Post a reply to this message

The same guy who came up with the photon mapping idea wrote a paper
decribing how to extend it to work with participating media too.  I
don't know if Nathan has this paper, but it would be neat if it could be
worked into POV sometime down the road.

It can handle caustics in media and even diffuse <-> volume light
transfer!  :)

-Mike
 
>   This topic and the solutions you have suggested were discussed in
> some detail back in January. I believe the thrust of the discussion
> centered aorund the use of monte carlo sampling and it's limitions.
> I tmight have been Nathan Kopp who mentioned tht he has been trying
> different sampling methods to be used with the media feature and has
> passed on the concerns of people about the process to Chris Young
> the pov team coordinator. I guess you could say there is work in
> progress to add more functinality to the media process but I have
> no confirming data to support this. I do agree that there are some
> sampling methods like that used in the previous atmosphere feature that
> could add greater funtionality to the current system and it would be
> nice to see some improvements in that area.
> 
> --
> Ken Tyler
> 
> mailto://tylereng@pacbell.net

Post a reply to this message

I read the paper (very nice images in it).  But you'll notice that, unlike
the original work that Jensen did on photon maps (which ran on a low-end
linux box), the atmospheric stuff was rendered on an 8 (or was it 16?)
processor graphics workstation with many, many megabytes of memory.

I do plan to implement it, but it's not top priority right now.  First,
I want to work on finishing photon mapping for caustics, then make it
work with radiosity.  Also, I want to have a closer look at media to
try to get back the adaptive sampling method before introducing volume
photons.

-Nathan

Mike wrote:
> 
> The same guy who came up with the photon mapping idea wrote a paper
> decribing how to extend it to work with participating media too.  I
> don't know if Nathan has this paper, but it would be neat if it could be
> worked into POV sometime down the road.
> 
> It can handle caustics in media and even diffuse <-> volume light
> transfer!  :)
>

Post a reply to this message

PoDs Saturday reply to that Consecutive frames thread is all you really
need to make that work. Just put FileName in place of the "*.tga". Don't
use quotes.


Ken wrote:
> 
>  As far as the other project I have had no success making it work. Either
> I am too dense or there is something wrong with the exapmles given me so
> far. I can get the include file method to work but can't seem to figure
> out how to use successive images to create height fields as I am tring
> to do.
>   The HF statement want's a syntax of:
> 
> height_field {"tga "xxx.tga"  stuff }
> 
>  I can't figure out how to use the code provided to satisfy it's need
> for the - tga "xxx.tga" - part of the syntax. If you have any suggestions
> I am willing to listen to your advice.
> 
> --
> Ken Tyler
> 
-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/POVring.htm
 mailto:inv### [at] aolcom?PoV

Post a reply to this message

Bob Hughes wrote:
> 
> PoDs Saturday reply to that Consecutive frames thread is all you really
> need to make that work. Just put FileName in place of the "*.tga". Don't
> use quotes.
> 

It was the quotes that was hanging me up. Got it going a while ago with
Andrews help.

-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message