In article <kfK3OIjBjxu=lEMtvnZip=3GMUqx@4ax.com>, Peter Popov 
<pet### [at] usanet> wrote:

> Significant reduction of render times can be achieved if complex media
> statements are replaced with precomputed density patterns. My current
> project involves the usage of 200 scattering media statements in a
> single blob container. It takes more than nine hours to render at
> 640x480. If it were a single df3 media, render times could be
> dramatically decreased (by an order of ten to a hundred, depending on
> the scene)

Have you tried the blob pattern/pigments? Those may help...my original 
idea was that they would be good density patterns for media.


> No, because the falloff (for spotlights) would still be circular and
> not polygonal.

Hmm, shouldn't an area light work with projected_through to get that?


> >> : leave original textures when CSGing
> >> 
> >> When performing a CGS difference or intersection, any object with a
> >> non-specified texture is assumed to have a black pigment and ambient
> >> 0. I think a more reasonable behaviour would be to ignore its texture
> >> and use the texture of whatever object the intersection point is in.
> >> Of course this could lead to "coincident interiors" problems but I
> >> think with proper CGSing they can be avoided.
> >
> >Actually, I am pretty sure it uses the default texture, which you can 
> >set with the #default keyword. 
> 
> I guess so, but it still poses the same problem.

> If more then one objects enclose the point, use the texture of that
> one which appears first (or last) in the CSG.




> I didn't mean the user should specify the seed, rather that the seed
> should be constant for each pixel (for example X+Y). This would
> eliminate the "flying pixels" static.

Hmm, that might work...


> I've raised the question of simulating wave properties (wavelength,
> phase and polarization) a couple of times myself but it was
> overlooked. Your idea is certainly more versatile and I see good uses
> for it already.

I actually have a very early version done already. It doesn't work with 
photons(I have to figure out how to get the evaluation point in the 
right part of the code before that will work), and there might be some 
other oddities I haven't found yet, but the straight mapping works. I 
haven't added spherical and cylinderical mappings yet, so it doesn't 
have depth dependant effects yet.

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

Post a reply to this message