Is it possible to speed up the media calculations where multiple
densities are involved? More precisely, can some type of bounding be
used with finite density patterns such as spherical, cylindrical or
planar? This would be especially beneficial for smoke, fire and steam
modelled with multiple spherical "puffs".

I imagine the process would be something like this (pseudocode):

For a given ray R, media densities D[n] bounded by B[n] and contained
in C, and time parameter t (for the ray equation):

Find_All_Intersections (R, C, t);           // t is an array
for (i=0; i<n; i++)
{ Find_All_Intersections (R, D[n], t1);     // t1 is an array
  if (t1)                                   // Intersection found?
  { I = Find_Overlapping_Intervals (t, t1); // I is an array
    foreach (I) Take_Media_Samples (I);
  }
}

If something like this is already implemented, for example in the blob
pattern, please let me know.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

In article <NTnDOAGSBzHHoh5uC0Ey4azKVFd+@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Is it possible to speed up the media calculations where multiple
> densities are involved? More precisely, can some type of bounding be
> used with finite density patterns such as spherical, cylindrical or
> planar? This would be especially beneficial for smoke, fire and steam
> modelled with multiple spherical "puffs".

I don't think it would be possible with spherical or cylinderical, since 
they are basically bounded onion and wood patterns. Planar would be a 
kind of bounded gradient. For example, with spherical, you would have to 
get the distance from the origin, and only evaluate the spherical 
pattern if the distance is below a certain value. However, the spherical 
pattern just returns the distance from the origin if it is below that 
value, so the "bounding" would be redundant and would actually slow 
things down(you would have to calculate the distance and a conditional 
an additional time).

If you have a slow rendering pattern(like proximity) and you want to 
confine it to a certain area, you might want to try "bounding" it with 
the object pattern. That pattern only uses the inside-outside test, so 
it is pretty fast for most primitives.


> If something like this is already implemented, for example in the blob
> pattern, please let me know.

I didn't really understand the pseudo code you showed, but I don't 
understand the media code very well either.
The blob pattern and pigment are very un-optimized. All of the 
components are tested for each evaluation point. I plan to add a list to 
each component which contains pointers to the components it interacts 
with in order to fix this problem, but I haven't had time yet. It is 
still pretty fast as-is, though.(that is one reason I haven't bothered 
to optimize it)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Peter Popov <pet### [at] usanet> wrote...
> Is it possible to speed up the media calculations where multiple
> densities are involved? More precisely, can some type of bounding be
> used with finite density patterns such as spherical, cylindrical or
> planar? This would be especially beneficial for smoke, fire and steam
> modelled with multiple spherical "puffs".
>

Using multiple media container objects, one for each density, to bound the
media should produce the desired result.  Remember to increase the max trace
level if you try this suggestion.

-Nathan

Post a reply to this message

On Mon, 6 Mar 2000 16:04:08 -0500, "Nathan Kopp" <Nat### [at] Koppcom>
wrote:

>Peter Popov <pet### [at] usanet> wrote...
>> Is it possible to speed up the media calculations where multiple
>> densities are involved? More precisely, can some type of bounding be
>> used with finite density patterns such as spherical, cylindrical or
>> planar? This would be especially beneficial for smoke, fire and steam
>> modelled with multiple spherical "puffs".
>>
>
>Using multiple media container objects, one for each density, to bound the
>media should produce the desired result.  Remember to increase the max trace
>level if you try this suggestion.

This solution is *extremely* slow, especially when a couple of
hundreds or more objects are involved (like in dense smoke). Blobs
turn out to be the best in this case (and speed comparisons prove it)
but the problem with testing every sample against every density
remains.

Take a spherical density. Why test 30 samples against it if the ray
doesn't pass through its bounding volume at all? Intersect the ray
with the bounding object of the density, and if and only if there are
intersections (they will be exactly two) go on with shooting the
samples. The two intersection points will actually be samples of
density 0 so they can be cached and used in the calculations so no
redundant work will be done.

I think this will speed up rendering for any value of samples/pixel
greater than 2.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
[snip]
> Take a spherical density. Why test 30 samples against it if the ray
> doesn't pass through its bounding volume at all? Intersect the ray
> with the bounding object of the density, and if and only if there are
> intersections (they will be exactly two) go on with shooting the
> samples. The two intersection points will actually be samples of
> density 0 so they can be cached and used in the calculations so no
> redundant work will be done.
> 
> I think this will speed up rendering for any value of samples/pixel
> greater than 2.
> 
> Peter Popov
> pet### [at] usanet
> ICQ: 15002700

I think this would _really_ foul up some of my cloud techniques where I
use

	...
	density { spherical colour_map {[0 rgb 1][cloudBase rgb 0]} }
	...
or
	...
	density { spherical frequency -1 colour_map { ... } }
	...

and similar constructs. 

Does nobody else use blend maps in density?

Well, just my thoughts ...
	Mike Andrews.

Post a reply to this message

On Tue, 07 Mar 2000 17:14:39 +0000, Michael Andrews
<M.C### [at] readingacuk> wrote:

>I think this would _really_ foul up some of my cloud techniques

Foul up?


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message

Sorry - colloquial usage meaning roughly 'make not work properly' in
this context.

Peter Popov wrote:
> 
> On Tue, 07 Mar 2000 17:14:39 +0000, Michael Andrews
> <M.C### [at] readingacuk> wrote:
> 
> >I think this would _really_ foul up some of my cloud techniques
> 
> Foul up?
> 
> Peter Popov
> pet### [at] usanet
> ICQ: 15002700

Post a reply to this message

On Wed, 08 Mar 2000 17:07:26 +0000, Michael Andrews
<M.C### [at] readingacuk> wrote:

>Sorry - colloquial usage meaning roughly 'make not work properly' in
>this context.

I guessed so, but I still can't see how this approach would affect
whatever densities you're using. All I am suggesting is to test
samples against the relevant densities only. If a ray does not hit a
density's bounding object then nor will any samples along it,
therefore all tests of this ray with this density are just a waste of
rendering time. The output should not be affected regardless of the
addition of 500 samples contributing zilch. IMHO, that is.


Peter Popov
pet### [at] usanet
ICQ: 15002700

Post a reply to this message