"Christian Liesch" <lie### [at] gmxch> wrote in message
news:200### [at] gmxch...
> Hmmm, not very encouraging :-P

No, but understandable. As you say, a subset is possible, but translating a
complex CSG which uses macros to construct it's geometry? Iso-surfaces? Yeech.

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> No, but understandable. As you say, a subset is possible, but translating a
> complex CSG which uses macros to construct it's geometry? Iso-surfaces? Yeech.

  Actually tesselating an isosurface is not difficult (eg. using the
triangle marching algorithm).
  Tesselating CSG is a bit more difficult, but not impossible.
  However, POV-Ray can also handle infinite non-flat surfaces (such as
infinite paraboloids and hyperboloids) which can't be tesselated (you
simply can't create an infinite amount of triangles).

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message news:3e80451f@news.povray.org...

> infinite paraboloids and hyperboloids) which can't be tesselated (you
> simply can't create an infinite amount of triangles).

JOOC, how does pov handle infinities? Okay, the concept of an infinite plane is
easy enough, but at what distance does pov stop trying to find intersections
between the surface and the ray?

Post a reply to this message

On Tue, 25 Mar 2003 13:46:01 -0000, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> JOOC, how does pov handle infinities?

Mathematically. The shapes are usually stored just like they are defined in SDL.

ABX

Post a reply to this message

"ABX" <abx### [at] abxartpl> wrote in message
news:v1o08vs3i168mrihk5qt4o8lu8q3hrdvt0@4ax.com...
> On Tue, 25 Mar 2003 13:46:01 -0000, "Tom Melly" <tom### [at] tomandlucouk> wrote:
> > JOOC, how does pov handle infinities?
>
> Mathematically. The shapes are usually stored just like they are defined in
SDL.
>

Sorry, I should have been clearer (or, if your answer is complete, perhaps you
should ;).

Whilst internally POV can "see" that the shapes are infinite, at the trace-level
POV must give up at some distance, otherwise (afaics) any scene with an infinite
object might take forever to trace. I suppose another way of putting it is "what
bounding box does pov apply to infinite shapes?".

Post a reply to this message

On Tue, 25 Mar 2003 11:01:47 -0000
"Tom Melly" <tom### [at] tomandlucouk> wrote:

> "Christian Liesch" <lie### [at] gmxch> wrote in message
> news:200### [at] gmxch...
> > Hmmm, not very encouraging :-P
> 
> No, but understandable. As you say, a subset is possible, but translating a
> complex CSG which uses macros to construct it's geometry? Iso-surfaces? Yeech.
> 
> 

Of course just a subset:
- differences
- unions
- box
- cylinder
- scaling, translation, rotation

Ok. I just wonder that there is no convertion to any other Graphical system, cause
povray is a realy easy to use tool to build up modells and best of all it is a clear
text script not a binary...

In the meantime I found a Project, which convert a povray script into gts and stl, but
it can not handle scaling. So I have to program something addional stuff for it.

http://www.kritzner.de/

regards, Chrsitian

Post a reply to this message

Maybe this will be of some use to you (copied from pov.bins.utils):

"Wolfgang Thaller" <wol### [at] gmxnet> wrote in message
news:3c82b64c$1@news.povray.org...
> I've just released a new freeware utility program
> that might interest you:
> http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html
>
> VOP is a program that parses POV-Ray scene
> description files and renders them using OpenGL.
> While the resulting 3D images are not as nice as
> POV-Ray's, VOP is anywhere from five to two thousand
> times faster (depending on situation and measurement
> method).
>
> As you can imagine, this can be very practical for
> designing scenes and animations. The downside is that
> it doesn't yet support the entire scene description
> language - but I think it already supports more of it
> than any other program besides POV-Ray itself.
>
> There's a Windows compile available and I could probably
> compile a version for RedHat Linux 7.1, too, if somebody
> really wants it.
>
> I'm looking forward to your feedback.
>
> Cheers,
>
> Wolfgang Thaller
>


jim

Post a reply to this message

"James Taylor" <jim### [at] blueyondercouk> wrote:
>
> > http://www.kfunigraz.ac.at/imawww/thaller/wolfgang/vop-intro.html

If only this thing is at least half as smart as its name... :-)

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
> Whilst internally POV can "see" that the shapes are infinite, at the trace-level
> POV must give up at some distance, otherwise (afaics) any scene with an infinite
> object might take forever to trace.

  Uh? Calculating the intersection point of a ray and a surface which
is very very far away does not take any longer than with a surface
which is close. Why would you think it does?

  Anyways, what you are looking for in your question is not tracing *time*,
but tracing *accuracy*. Since floating point numbers have limited accuracy,
there's a certain limit how far the intersection point can be. There's a
maximum value which can be represented with a floating point number (and
values near this maximum value are not very accurate, as they make rather
big "jumps").

  Theoretically the upper limit of a distance is really large, as the
maximum value which can be represented with a (64-bit) 'double' type
is about 1.8*10^308 (that's "18" followed by 307 zeros). So theoretically
you could have an intersection point that far away from the origin in each
axis.
  However, as I said, the representation of numbers near that value become
really inaccurate and thus it's not very feasible to get close to it.
  There's an artificial limit in POV-Ray how far an intersection can be in
order for it to have effect. This is done so that they don't get close to
this upper limit, where inaccuracies are large. (However, I seem to recall
that this artificial limit is almost paranoidically low, even though it
could be a lot higher.)

  Anyways, even when there are limits imposed by finite accuracy, the
amount of triangles needed to approximate such surface would be enormous
nevertheless.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

3e805d9a$1@news.povray.org...
> "Warp" <war### [at] tagpovrayorg> wrote in message
news:3e80451f@news.povray.org...
>
> JOOC, how does pov handle infinities? Okay, the concept of an infinite
plane is
> easy enough, but at what distance does pov stop trying to find
intersections
> between the surface and the ray?
>
The wormhole towards other dimension of non-pov world is here if you
decomment the second line:
/******************************/
#declare Passage=9999999.0;
//#declare Passage=9999999.00002;


sphere { 0, Passage
 pigment{rgb<0,.5,1>}
        }

camera {
  location  <0, 0,-1>
  look_at   <0, 0,  0>
  right x*image_width/image_height
}
light_source{0,2}
/***********************************/
Thanks Martial

And found by Mael (mlPOV) in the frame.h file of the sources:

/*
 * These values determine the minumum and maximum distances
 * that qualify as ray-object intersections.
 */
#define Small_Tolerance 0.001
#define Max_Distance 1.0e7

Marc

Post a reply to this message