is there a way to make a hemishere?

Post a reply to this message

"FCB" <nomail@nomail> wrote in message
news:web.40ce359f86b59361dc24a13d0@news.povray.org...
> is there a way to make a hemishere?

I'll answer with one complete simple solution, but if you're asking about
something more than what's shown below feel free to ask more.

/* BEGIN simple hemisphere */

camera {location -4*z look_at 0}

light_source {-100*z,1}

#declare Hemisphere=
intersection {
  plane {-y,0} // could use x, instead of y, for East/West
 // negative y for northern hemisphere, positive for southern
  sphere {0,1}
  pigment {color rgb <1,1,1>}
}

object {Hemisphere
  rotate < 15 , 0 , 0 > // to turn whichever way needed
  translate -1.25*x} // put on left side

/* and to hollow it out... */

difference {
  object {Hemisphere}
  sphere {0,1 // cutaway object
   pigment {color rgb <1,0,0>}
   scale 0.9 // scale for thickness ( nearer 1 is thinner)
   }
  rotate < 15 , 0 , 0 > // to turn whichever way needed
  translate 1.25*x // put on right side
}

/* END */

Post a reply to this message

Hughes, B. nous apporta ses lumieres ainsi en ce 14/06/2004 21:20... :

>"FCB" <nomail@nomail> wrote in message
>news:web.40ce359f86b59361dc24a13d0@news.povray.org...
>  
>
>>is there a way to make a hemishere?
>>    
>>
>
>I'll answer with one complete simple solution, but if you're asking about
>something more than what's shown below feel free to ask more.
>
>/* BEGIN simple hemisphere */
>
>camera {location -4*z look_at 0}
>
>light_source {-100*z,1}
>
>#declare Hemisphere=
>intersection {
>  plane {-y,0} // could use x, instead of y, for East/West
> // negative y for northern hemisphere, positive for southern
>  sphere {0,1}
>  pigment {color rgb <1,1,1>}
>}
>
>object {Hemisphere
>  rotate < 15 , 0 , 0 > // to turn whichever way needed
>  translate -1.25*x} // put on left side
>
>/* and to hollow it out... */
>
>difference {
>  object {Hemisphere}
>  sphere {0,1 // cutaway object
>   pigment {color rgb <1,0,0>}
>   scale 0.9 // scale for thickness ( nearer 1 is thinner)
>   }
>  rotate < 15 , 0 , 0 > // to turn whichever way needed
>  translate 1.25*x // put on right side
>}
>
>/* END */
>
>
>  
>
I prefer to use a box instead of a plane like:
intersection{
    sphere{0,1}
    box{<0,1.1,1.1>,-1.1}
    pigment{MyPigment}
    scale MyScale
    }
If you want an empty hemisphere, try this:
difference{
    sphere{0,1}
    sphere{0,.9}// adjust for the thickness you want
    box{<0,-1.1,-1.1>,1.1}
    pigment{MyPigment}
    scale MyScale
    }

That way, the bounding is more efficient (tighter)

Alain

Post a reply to this message

"Alain" <aze### [at] qwertygov> wrote in message
news:40cecb48$1@news.povray.org...
> Hughes, B. nous apporta ses lumieres ainsi en ce 14/06/2004 21:20... :
> >
> >#declare Hemisphere=
> >intersection {
> >  plane {-y,0} // could use x, instead of y, for East/West
> > // negative y for northern hemisphere, positive for southern
> >  sphere {0,1}
> >  pigment {color rgb <1,1,1>}
> >}
> >
> I prefer to use a box instead of a plane like:
> intersection{
>     sphere{0,1}
>     box{<0,1.1,1.1>,-1.1}
>     pigment{MyPigment}
>     scale MyScale
>     }
>
> That way, the bounding is more efficient (tighter)

I was going to concede about this until I decided to try a test of the two
ways.

Yours parsed and rendered slower, than mine, (in version 3.6) over several
runs, rather consistently too. I put them into a while loop, making a
150X150 grid facing the camera. Output image resolution was 1280X1024 and
default AA used. I kept the number of objects down to prevent going to XP's
Page File, so it wouldn't interfere.

plane = Parse: 1 to 2 seconds Render: 19 to 20 seconds, or averaging 21
seconds total.

box = Parse: 2 to 4 seconds Render: 23 to 24 seconds, or averaging 27
seconds total.

Perhaps imprecise, being so short-lived, but I believe it is showing the
introduction of the box is actually causing a loss of optimization or
something. I don't know the truth behind the numbers; it just looks like the
plane has an advantage, at least in this case.

Bob H.

Post a reply to this message

"Hughes, B." <omn### [at] charternet> wrote:
> Perhaps imprecise, being so short-lived, but I believe it is showing the
> introduction of the box is actually causing a loss of optimization or
> something. I don't know the truth behind the numbers; it just looks like the
> plane has an advantage, at least in this case.

This may go right to something I have wondered for a while.  When using a
plane in CSG, how is the bounding box determined?  Per the docs regarding
manual bounding, the automatic bounding uses the size of the objects used
in the CSG, but I'm thinking here that infinite is not used...

RG

Post a reply to this message

gonzo wrote:
> "Hughes, B." <omn### [at] charternet> wrote:
> 
>>Perhaps imprecise, being so short-lived, but I believe it is showing the
>>introduction of the box is actually causing a loss of optimization or
>>something. I don't know the truth behind the numbers; it just looks like the
>>plane has an advantage, at least in this case.
> 
> 
> This may go right to something I have wondered for a while.  When using a
> plane in CSG, how is the bounding box determined?  Per the docs regarding
> manual bounding, the automatic bounding uses the size of the objects used
> in the CSG, but I'm thinking here that infinite is not used...
> 
> RG
> 

I'm not sure if this is it, but I'd image that in a difference it only 
needs to take the bounding box of the first object and that in an 
intersection it only needs the bounding box of the smallest object.

Shalom Naumann

Post a reply to this message

Hughes, B. nous apporta ses lumieres ainsi en ce 15/06/2004 07:31... :

>
>I was going to concede about this until I decided to try a test of the two
>ways.
>
>Yours parsed and rendered slower, than mine, (in version 3.6) over several
>runs, rather consistently too. I put them into a while loop, making a
>150X150 grid facing the camera. Output image resolution was 1280X1024 and
>default AA used. I kept the number of objects down to prevent going to XP's
>Page File, so it wouldn't interfere.
>
>plane = Parse: 1 to 2 seconds Render: 19 to 20 seconds, or averaging 21
>seconds total.
>
>box = Parse: 2 to 4 seconds Render: 23 to 24 seconds, or averaging 27
>seconds total.
>
>Perhaps imprecise, being so short-lived, but I believe it is showing the
>introduction of the box is actually causing a loss of optimization or
>something. I don't know the truth behind the numbers; it just looks like the
>plane has an advantage, at least in this case.
>
>Bob H.
>
>
>  
>
OK. Aparently, when removing a plane, an infinite object, the bounding 
is limited to the original object, but when removing a box, a finite 
object, the bounding encompas both objects. Did you try both 
intersection and difference?

Alain

Post a reply to this message

"Alain" <aze### [at] qwertygov> wrote in message
news:40d24d88$1@news.povray.org...
> Did you try both intersection and difference?

No, had not. Have now, here are the results:

I= parse 3 sec.; render 20 sec.
D=parse 4 sec.; render 25 sec.

I had to change the -y plane to +y in order to get the same object, and move
the sphere to first place in the CSG, other than that it's all the same as
before.

Oh yeah, and the box isn't <1.1,0,1.1>,-1.1, like the originally suggested
one, I tightened it up some and went with a <1.01,0,1.01>,-1.01. However,
also checking into using either one of these isn't showing any true change I
can be certain of; only a peculiar instance of a 2 seconds parse when I
moved the negative corner ahead of the positive, which hasn't occured again.
That shows an unworthiness to my tests but the ones done between plane or
box and intersection or difference are still very consistent, even if it is
a mere several seconds of time.

Bob H.

Post a reply to this message

Im not too sure about bounding objects, but in the case of a difference from
a sphere it makes sense that a planar difference is more efficient than a
boxed difference.
This is because the plane only has 1 component; that is...plane exists if
y>0 and plane doesn't exist if y<0. So when cutting it out of a sphere only
one component of the sphere needs to be checked, in this case the y
component.
For a box; the sphere needs to be checked against all 3 components <x,y,z>.
Is this right?

387






Alain <aze### [at] qwertygov> wrote:
> Hughes, B. nous apporta ses lumieres ainsi en ce 15/06/2004 07:31... :
>
> >
> >I was going to concede about this until I decided to try a test of the two
> >ways.
> >
> >Yours parsed and rendered slower, than mine, (in version 3.6) over several
> >runs, rather consistently too. I put them into a while loop, making a
> >150X150 grid facing the camera. Output image resolution was 1280X1024 and
> >default AA used. I kept the number of objects down to prevent going to XP's
> >Page File, so it wouldn't interfere.
> >
> >plane = Parse: 1 to 2 seconds Render: 19 to 20 seconds, or averaging 21
> >seconds total.
> >
> >box = Parse: 2 to 4 seconds Render: 23 to 24 seconds, or averaging 27
> >seconds total.
> >
> >Perhaps imprecise, being so short-lived, but I believe it is showing the
> >introduction of the box is actually causing a loss of optimization or
> >something. I don't know the truth behind the numbers; it just looks like the
> >plane has an advantage, at least in this case.
> >
> >Bob H.
> >
> >
> >
> >
> OK. Aparently, when removing a plane, an infinite object, the bounding
> is limited to the original object, but when removing a box, a finite
> object, the bounding encompas both objects. Did you try both
> intersection and difference?
>
> Alain

Post a reply to this message