Hi

I have a pic with two HFs, several animal meshes and clouds using the
stacked plane technique.

Each individual item parses and renders within a few minutes but put
together I suspect a render time in excess of 3 days!

I believe this has something to do with the combination of the HF which use
the superpatch slope texture method with some transparency in one of the
textures and the sky.

Can anyone explain this and possibly suggest a solution.

BTW max_trace_level is set at 124 there are 80 odd planes in the sky! but I
suspect could be lowered but at these render times I'm loath to experiment.

Mick

Post a reply to this message

If it's all that transparency in those layered clouds then let me suggest the
following.

Intersect two planes that are seperated about the distance you have all those
planes at now.  So say you want it in the region between y500 and y600:

intersection {
plane {y, 500 inverse}
plane {y, 600}

pigment {color rgbf <1, 1, 1, 1>}

interior {
media {
scattering {1, 1 extinction .1}
samples 5, 10
density {
your pattern stuff here
}
}
}
hollow
}

Having your media defined to such a small range will generally render pretty
fast.

Post a reply to this message

Something tells me Mick might not be using 'media' at all but rather
various textured planes instead (like the clouds, clouds, clouds post
recently). If so then I'd suggest rendering those animal objects and
HFs separately and combining later if you can via post-processing.

Bob

Mike <pov### [at] aolcom> wrote in message
news:37D0B642.502B7B3B@aol.com...
> Having your media defined to such a small range will generally
render pretty
> fast.
>

Post a reply to this message

Bob Hughes wrote:
> 
> Something tells me Mick might not be using 'media' at all but rather
> various textured planes instead (like the clouds, clouds, clouds post
> recently). If so then I'd suggest rendering those animal objects and
> HFs separately and combining later if you can via post-processing.
> 
> Bob

 Bob: That is unconscionable !

Mick: If you build em like this they are going to take a long time to render.
      You are asking the program to calculate a whole bunck of rays and it's
      going to take time. May I suggest a good book...


-- 
Ken Tyler

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

Post a reply to this message

Thanks guys

No I'm not using media.  Actually I,ve got a pile of books to read.

It's now 17hrs in and speeding up so a 20 hour render seems likely - not so
bad!

I did wonder about manually bounding the objects? might that help?

Mick


Ken <tyl### [at] pacbellnet> wrote in message
news:37D0DCCA.2E03E3F8@pacbell.net...
>
>
> Bob Hughes wrote:
> >
> > Something tells me Mick might not be using 'media' at all but rather
> > various textured planes instead (like the clouds, clouds, clouds post
> > recently). If so then I'd suggest rendering those animal objects and
> > HFs separately and combining later if you can via post-processing.
> >
> > Bob
>
>  Bob: That is unconscionable !
>
> Mick: If you build em like this they are going to take a long time to
render.
>       You are asking the program to calculate a whole bunck of rays and
it's
>       going to take time. May I suggest a good book...
>
>
> --
> Ken Tyler
>
> See my 850+ Povray and 3D Rendering and Raytracing Links at:
> http://home.pacbell.net/tylereng/index.html

Post a reply to this message

Mick Hazelgrove wrote:
> 
> Thanks guys
> 
> No I'm not using media.  Actually I,ve got a pile of books to read.
> 
> It's now 17hrs in and speeding up so a 20 hour render seems likely - not so
> bad!
> 
> I did wonder about manually bounding the objects? might that help?
> 
> Mick

Bounding may help as well as trying to use large scaled boxes as well. A
box acts like a plane of sorts when specified like this:

box { <-22000,0,-22000>, <22000,0,22000> }

Notice how there is no scale given in the box's y direction ?
It works well and has the advantage that automatic bounding is
very effecient for the box object. Also you will have a problem
with Pov if you try to add manual bounding to a union of planes
because Pov will simply remove the manual bounding unless you
turn bounding off. This may cause the rest of your scene to take
even longer to render and the savings for the planes being bounded
may become moot. 22 hrs for a Pov scene to render is not all that
uncommon and who said raytracing was fast anyway ?

-- 
Ken Tyler

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

Post a reply to this message

Mick Hazelgrove wrote:
> 
> Hi
> 
> I have a pic with two HFs, several animal meshes and clouds using the
> stacked plane technique.
> 
> Each individual item parses and renders within a few minutes but put
> together I suspect a render time in excess of 3 days!
> 
> I believe this has something to do with the combination of the HF which use
> the superpatch slope texture method with some transparency in one of the
> textures and the sky.
> 
> Can anyone explain this and possibly suggest a solution.
> 
> BTW max_trace_level is set at 124 there are 80 odd planes in the sky! but I
> suspect could be lowered but at these render times I'm loath to experiment.
> 
> Mick

80 planes !!
Can you reduce this by using layered textures on fewer planes?
Perhaps combine some of your pigments with pigment_maps.
Do the cloud planes cast shadows, can you use no_shadow for at least
some of them?

Cheers, PoD.

Post a reply to this message

On Sat, 04 Sep 1999 06:57:15 -0700, Ken <tyl### [at] pacbellnet> wrote:

>Notice how there is no scale given in the box's y direction ?

The things one learn every day... I think though that this is
internally converted to a unit box with the appropriate transformation
matrix applied, and since POV changes a zero scale to unity scale, you
might as well replace the zeroes with ones there as there's no
difference between them. There, I beat the bejesus out of boolean
algebra :)

>It works well and has the advantage that automatic bounding is
>very effecient for the box object. Also you will have a problem
>with Pov if you try to add manual bounding to a union of planes
>because Pov will simply remove the manual bounding unless you
>turn bounding off.This may cause the rest of your scene to take
>even longer to render and the savings for the planes being bounded
>may become moot. 22 hrs for a Pov scene to render is not all that
>uncommon and who said raytracing was fast anyway ?

I regret to say this, but you are wrong. You can use manual *and*
automatic bounding simultaneously. You just have to tell POV to keep
the user bounds, because by default it will remove them. The command
line option is -UR and the INI file setting is Remove_Bounds=off. In
case you are bounding a union you might have to have Split_Unions=off
or use -SU in the command line.


Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote:
> 
> On Sat, 04 Sep 1999 06:57:15 -0700, Ken <tyl### [at] pacbellnet> wrote:
> 
> >Notice how there is no scale given in the box's y direction ?
> 
> The things one learn every day... I think though that this is
> internally converted to a unit box with the appropriate transformation
> matrix applied, and since POV changes a zero scale to unity scale, you
> might as well replace the zeroes with ones there as there's no
> difference between them. There, I beat the bejesus out of boolean
> algebra :)

The proof comes from rendering the following:

camera{location z*-3.5 look_at 0 }
light_source { z*-13 rgb 1}
background{rgb .55}

box { <-1,0,-1>, <1,0,1> pigment{red 1}}

All that you will see once rendered is a thin red line. I found this about
9 months ago and it was discussed for a while and dropped as to why Pov
allows this. The important thing is that it does work. In fact it you attempt
to use it like a triangle in a CSG operation it suffers the same limitations
as a triangle or other similar infinitely thin Pov primitives.

> I regret to say this, but you are wrong. You can use manual *and*
> automatic bounding simultaneously. You just have to tell POV to keep
> the user bounds, because by default it will remove them. The command
> line option is -UR and the INI file setting is Remove_Bounds=off. In
> case you are bounding a union you might have to have Split_Unions=off
> or use -SU in the command line.
> 
> Peter Popov
> ICQ: 15002700

I was not wrong I simply did not offer all of the possible solutions that
you did :)

-- 
Ken Tyler

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

Post a reply to this message

On Sat, 04 Sep 1999 13:13:44 -0700, Ken <tyl### [at] pacbellnet> wrote:

>The proof comes from rendering the following:
>
>camera{location z*-3.5 look_at 0 }
>light_source { z*-13 rgb 1}
>background{rgb .55}
>
>box { <-1,0,-1>, <1,0,1> pigment{red 1}}
>
>All that you will see once rendered is a thin red line. I found this about
>9 months ago and it was discussed for a while and dropped as to why Pov
>allows this. The important thing is that it does work. In fact it you attempt
>to use it like a triangle in a CSG operation it suffers the same limitations
>as a triangle or other similar infinitely thin Pov primitives.

I stand corrected and I thank you for showing me the light, master
Ken. :) 

"The stupid learn from their mistakes, the wise - from the mistakes of
others." :)

<snip>

>I was not wrong I simply did not offer all of the possible solutions that
>you did :)

Ever thought of becoming a lawyer? :)


Peter Popov
ICQ: 15002700

Post a reply to this message