I added some stuff to the superpatch sources and upload a binary to
http://members.xoom.com/POVRAY/minipatch.zip.  Currently xoom is down,
but it should be available later once they get their heads out
of...anyway, here's the new stuff:

camera {
spherical_camera
h_angle int
v_angle int
}

and

media {
sample_method 1 or 2
jitter float
}

The first one is self-explanitory, I think.  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

Post a reply to this message

On Fri, 17 Sep 1999 07:22:49 -0500, Mike wrote:
>I added some stuff to the superpatch sources and upload a binary to
>http://members.xoom.com/POVRAY/minipatch.zip.  Currently xoom is down,
>but it should be available later once they get their heads out
>of...anyway, here's the new stuff:

Can I have your sources?

Post a reply to this message

Can you get this out into a new version of the SuperPatch any time soon? You
have been mentioning a lot of stuff, and lots of people have come up with
little patches lately, yet you haven't put out any new versions recently.
Please give us a progress report at least. You know we sit on the edges of
our seats about this constanly. =)

PS: I'm glad you liked the cake. I'll be sending you the sources soon.
Should I include the texture for the floor? (It's a bit large, and I'm sure
you can come up with a better one).

Post a reply to this message

On Fri, 17 Sep 1999 10:42:25 -0400, TonyB wrote:
>Can you get this out into a new version of the SuperPatch any time soon? You
>have been mentioning a lot of stuff, and lots of people have come up with
>little patches lately, yet you haven't put out any new versions recently.
>Please give us a progress report at least. You know we sit on the edges of
>our seats about this constanly. =)

Um.  No progress recently.  There are a lot of little patches I need to track
down and integrate.  So far, I definitely have isoblobs and photons and a 
few other little things, but I had those a month ago.  I'd definitely like to 
add this media one, and fix a smattering of bugs I've posted in .bugreports.  
No idea when I'll find time to do that, though.

>PS: I'm glad you liked the cake. I'll be sending you the sources soon.
>Should I include the texture for the floor? (It's a bit large, and I'm sure
>you can come up with a better one).

I'm not so sure.  It was a very nice texture.  I assume it's an image map?

Post a reply to this message

>Um.  No progress recently.  There are a lot of little patches I need to
track
>down and integrate.

Oh, I see. Yes, I've noticed.

>So far, I definitely have isoblobs and photons and a
>few other little things, but I had those a month ago.

So why didn't you put it out?

>I'd definitely like to
>add this media one, and fix a smattering of bugs I've posted in
.bugreports.

Yes, the media must be added, the bugs must be fixed.

>No idea when I'll find time to do that, though.

=(


>I'm not so sure.  It was a very nice texture.  I assume it's an image map?

Yes. I'll include it for you then, I forget where I got it from, or else I
would have given you the link.

Post a reply to this message

Mike wrote:
> 
> I added some stuff to the superpatch sources and upload a binary to
> http://members.xoom.com/POVRAY/minipatch.zip.  Currently xoom is down,
> but it should be available later once they get their heads out
> of...anyway, here's the new stuff:
> -Mike

Sounds great and I look forward to giving it a try. Now if xoom will just get
their heads out of... well hopefully it will be available soon.

-- 
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

First off, xoom was down before, so they did actually have their heads up
their...well anyway, turns out I wasn't seeing sunshine either, as I messed
up the link when I posted it.  I couldn't test it because they weren't
responding this morning.  :(

Try http://members.xoom.com/POVRAY3/minipatch.zip

Sorry for the inconvenience.

Mike wrote:

> I added some stuff to the superpatch sources and upload a binary to
> http://members.xoom.com/POVRAY/minipatch.zip.  Currently xoom is down,
> but it should be available later once they get their heads out
> of...anyway, here's the new stuff:
>
> camera {
> spherical_camera
> h_angle int
> v_angle int
> }
>
> and
>
> media {
> sample_method 1 or 2
> jitter float
> }
>
> The first one is self-explanitory, I think.  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

Post a reply to this message

> Can I have your sources?

I sent you an email asking about which ones you wanted, but I wasn't sure
if you got it,  so I just posted all the changed files to
binaries.programming.  I need to remember to include them next time...

-Mike

Post a reply to this message

Mike wrote:
> 
> First off, xoom was down before, so they did actually have their heads up
> their...well anyway, turns out I wasn't seeing sunshine either, as I messed
> up the link when I posted it.  I couldn't test it because they weren't
> responding this morning.  :(
> 
> Try http://members.xoom.com/POVRAY3/minipatch.zip
> 
> Sorry for the inconvenience.

Will you be leaving this on xoom for a while ? I will link to the direct
file if you intend to leave it up.

Thanks,

-- 
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

> Will you be leaving this on xoom for a while ? I will link to the direct
> file if you intend to leave it up.

Yeah, it'll probably be there along as I use the xoom thing, which is probably
too long.  I wish I has a decent place to put stuff.  If I ever move my stuff
I'll let you know.

-Mike

Post a reply to this message

Try this instead of the two spheres in the minipatch example scene. Is the
blue part supposed to happen? If so, why?

#declare S = 5;

box
{
 1,-1 hollow
 pigment {rgbf 1}
 interior
 {
  media
  {
   emission 1/9
   sample_method 2 samples 2,3
   intervals 3 jitter 0
   density
   {
    agate
    color_map
    {
     [0.0 Black]
     [1.0 rgb <1,.75,0>]
    }
    scale S
   }
  }
 }
 scale S
}

Post a reply to this message

Ron Parker wrote in message <37e2656d@news.povray.org>...
>Um.  No progress recently.  There are a lot of little patches I need to
track
>down and integrate.  So far, I definitely have isoblobs and photons and a
>few other little things, but I had those a month ago.  I'd definitely like
to
>add this media one, and fix a smattering of bugs I've posted in
.bugreports.
>No idea when I'll find time to do that, though.


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?

Mark

Post a reply to this message

>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. Should I send you the source?


You don't ask questions like that, you just send it in... ;)

Post a reply to this message

Coincident surfaces.  Change S to 4.9999. :)

-Mike

Post a reply to this message

OK. Cool. Thanks.

I've been playing around with this thing. It is stupendous. I love it. For
some medias it doesn't make any difference, but for others, my goodness! I'm
changing to sample_method 2 for good. =) I've tested the old vollumetric
light scenes posted about 2 months ago. They rendered much faster and nicer
with way lower settings. I also tested my old flame. It is rendering just
like it used to, except the settings are 1/10 of what they were! This is how
media should have been introduced. Oh, BTW, I would prefer the keyword
"method" instead of "sample_method". Just a thought.

Anyway, thanks Mike!

Post a reply to this message

> I've been playing around with this thing. It is stupendous. I love it. For
> some medias it doesn't make any difference, but for others, my goodness! I'm
> changing to sample_method 2 for good. =)

The old method is still good for cetain things, like very large objects with
complex media inside.  I think it's related to the random sampling.  You will
get pretty much the same result with the type 2 version in my patch using jitter
1, though it won't take advantage of variance or confidence and therefore
doesn't make good use of max samples.

Supersampling could offer the best of both worlds - oh yeah, and there's some
other tests I can do to speed things up.  Since the ray is sampled from near to
far, I could check if the total color is completely white and save taking
pointless samples.  The same is true for total absorption.  For example, why
take samples to infinity if you have a global media that turns white 10 units
away?

I should mention that all the stuff I'm doing is garnered from how halo and
atmosphere worked in version 3.

> I've tested the old vollumetric
> light scenes posted about 2 months ago. They rendered much faster and nicer
> with way lower settings. I also tested my old flame. It is rendering just
> like it used to, except the settings are 1/10 of what they were! This is how
> media should have been introduced.

Halo used to be used for things like light glows and flames, and using even
samples is just amazingly smooth for that kind of stuff.  I think I've mentioned
before that doing it that way doesn't actually make it faster, but it puts the
sampling to better use allowing you to use fewer samples.

> Oh, BTW, I would prefer the keyword
> "method" instead of "sample_method". Just a thought.

I like the idea.  You would have hated the original keyword I was using -
media_sampling_method.  If I can get supersampling to work (well down the road)
I will include that change in the new patch.  I guess I should have put
something in there about backward compatibility not gaurenteed.  :)

> Anyway, thanks Mike!

Happy to hear you are having fun with it.  Try a spherical camera render next
and map it to a sky_sphere using spherical mapping. :)

-Mike

Post a reply to this message

Mike <pov### [at] aolcom> schreef in berichtnieuws
37E3E6DA.DE1908AD@aol.com...
> Happy to hear you are having fun with it.  Try a spherical camera
render next
> and map it to a sky_sphere using spherical mapping. :)
>
> -Mike

Yep, fun it is, displacement mapping spherical camera images on
isosurface spheres. No distortion on the poles, makes perfect asteroids
etc.
Had a quick look at the media, but that will take more time.

So many goodies,
so little time.


Thanks Mike

Ingo

Post a reply to this message

Just stepping in to so I can say I like what I see.

Bob

ingo <ing### [at] homenl> wrote in message
news:37e3fe47@news.povray.org...
>
> Mike <pov### [at] aolcom> schreef in berichtnieuws
> 37E3E6DA.DE1908AD@aol.com...
> > Happy to hear you are having fun with it.  Try a spherical camera
> render next
> > and map it to a sky_sphere using spherical mapping. :)
> >
> > -Mike
>
> Yep, fun it is, displacement mapping spherical camera images on
> isosurface spheres. No distortion on the poles, makes perfect
asteroids
> etc.
> Had a quick look at the media, but that will take more time.
>
> So many goodies,
> so little time.
>
>
> Thanks Mike
>
> Ingo
>
>

Post a reply to this message

Mike <pov### [at] aolcom> wrote in message news:37E3E6DA.DE1908AD@aol.com...
> Happy to hear you are having fun with it.  Try a spherical camera render
next
> and map it to a sky_sphere using spherical mapping. :)
>

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.

But then I never used those slow media clouds in that image, so I never put
this technique to use.

-Nathan

Post a reply to this message

Use the Plane_clouds (stsky.pov) using this method. Excellent Results!

H.E. Day

Nathan Kopp wrote:

> Mike <pov### [at] aolcom> wrote in message news:37E3E6DA.DE1908AD@aol.com...
> > Happy to hear you are having fun with it.  Try a spherical camera render
> next
> > and map it to a sky_sphere using spherical mapping. :)
> >
>
> 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.
>
> But then I never used those slow media clouds in that image, so I never put
> this technique to use.
>
> -Nathan

Post a reply to this message

> 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