> I thought of this when I was planning to make a scene that used some of
> those super-slow media clouds.  First, I thought I'd render the scene with
> just the sky and no other objects (using the same camera that the final
> image would use).  Then, using a macro I created, I'd paste that image map
> on a plane lined up witht he camera in the far background for all subsequent
> renders.  But then what would happen to reflections (the scene had glass in
> it)?  So I thought I'd render the rest of the sky using a spherical camera
> and map it to the sky_sphere (like you suggest).  Then, I'd have a
> high-resolution image map directly in front of the camera and a nice
> sky-sphere to handle reflections.
>

That's precisely the type of usage I had in mind when I did it (other than doing
QTVR type stuff).  Bump mapping and displacement are other uses.  Looking at an
object from the outside that has one of these images applied to it using a
spherical mapping is the same thing as an environment map, so you can do cheap
reflections with it too.

-Mike

Post a reply to this message

Mike <pov### [at] aolcom> wrote:
: The second one uses evenly
: ditributed samples when sample_method is 2 and will use the jitter
: amount to stagger the depth of the samples.  0 is none and 1 will move
: them around up to the distance to the next sample.

  I think that a better way to do this is not jittering the samples but
using the same method as with halos: Antialiasing. When 2 samples differ
too much from each other, a third sample is taken from the middle of them.
  This will:
  a) Make a lot smoother and better looking media
  b) Render a lot faster.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On Sat, 18 Sep 1999 00:56:39 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:

>I've figured out a modification to the Windows version of POV-Ray that can
>result in a 1%-5% across-the-board speed increase, depending on how much is
>running in the background.  If none of the other patches that have been
>added have modified any of the pvengine.* files, integrating the
>modifications should take less than a minute (if they have been modified, it
>might take as much as five minutes).  Should I send you the source?

By all means.  

If it's a modification to some official version of pvengine.c, I can
do the necessary merge here.  I've made a couple pvengine changes
myself.

Post a reply to this message

>If it's a modification to some official version of pvengine.c, I can
>do the necessary merge here.  I've made a couple pvengine changes
>myself.


Such as...? What can changes to pvengine.c do that other patches don't do? I
notice that for most patches you modify parse.c (or something like that, I
don't know exact file names).

Post a reply to this message

> What can changes to pvengine.c do that other patches don't do? I
> notice that for most patches you modify parse.c (or something like that, I
> don't know exact file names).

pvengine.c is related to the windows specific code, so it handles things like
the display and interface.  It's really big and complicated. :)

The reason most patches require modifications to parse.c (and frame.h and
tokenize.c) is that the parser reads in the data for different keywords in the
scene file.  Adding a new keyword means you have to add it to the files
associated with the parser.

-Mike

Post a reply to this message

Mike wrote:

>  The second one uses evenly
> ditributed samples when sample_method is 2 and will use the jitter
> amount to stagger the depth of the samples.  0 is none and 1 will move
> them around up to the distance to the next sample.
> 
> -Mike

 What can one expect from using the jitter option rendering time wise ? Will
jitter = 0 render faster in most cases ? I don't understand !

-- 
Ken Tyler

See my 1000+ Povray and 3D Rendering and Raytracing Links at:
http://home.pacbell.net/tylereng/index.html

Post a reply to this message

On Sun, 19 Sep 1999 22:19:46 -0400, TonyB wrote:
>
>>If it's a modification to some official version of pvengine.c, I can
>>do the necessary merge here.  I've made a couple pvengine changes
>>myself.
>
>
>Such as...? What can changes to pvengine.c do that other patches don't do? I
>notice that for most patches you modify parse.c (or something like that, I
>don't know exact file names).

Specifically, kludging it to accept newer editors with different version 
numbers.  But that's not something we should talk about; children might 
be present. :)

Post a reply to this message

>  What can one expect from using the jitter option rendering time wise ? Will
> jitter = 0 render faster in most cases ? I don't understand !

Jitter won't affect the rendering time at all (except for the extra calculation
time for FRAND(), which is basically noise).  I could probably speed things up
just a wee bit if I were to remove the jitter from the calculation if it's set
to 0, but I wasn't really thinking about that at the time.

The real point of having jitter is that it will produce results similiar to the
old method.  When I get supersampling working down the road it should also aid
in producing smoother and more accurate results.

-Mike

Post a reply to this message

Hey I don't think I got that one with my superpatch sources.  That would be a
very handy thing to have!

-Mike


> Specifically, kludging it to accept newer editors with different version
> numbers.  But that's not something we should talk about; children might
> be present. :)

Post a reply to this message

On Mon, 20 Sep 1999 10:10:30 -0500, Mike wrote:
>Hey I don't think I got that one with my superpatch sources.  That would be a
>very handy thing to have!

Yes you did.  I was just confused.  It's actually pvedit.c.

Post a reply to this message