 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hi all,
I'm looking for a program that could translate a povray script to OpenGL C sources. Is
there a way to do that? Else is there perhaps a povray script OpenGL interpreter?
Best regards,
Christian
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christian Liesch" <lie### [at] gmx ch> wrote in message
news:200### [at] gmxch...
> Hi all,
>
> I'm looking for a program that could translate a povray script to OpenGL C
sources. Is there a way to do that? Else is there perhaps a povray script OpenGL
interpreter?
>
I'm tempted to say 'forget it', but I've been caught out on that once before.
Instead, I'll point you to Warp's VFAQ:
http://www.students.tut.fi/~warp/povQandT/
and the specific bit you should read is:
http://www.students.tut.fi/~warp/povQandT/filesQandT.html#povtootherformatsdiffi
culty
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hmmm, not very encouraging :-P
To model a povray figure is very easy (readable text file, cause it is a script) and
cheap, so I thought I'm surely not the only one how wishes to have a translation to an
other format (rapid prototyping as a catchword). Just a subset of the povray script
would help. But ok, perhaps this is impossible, but don't give up - not now :-)
thanx and best regards,
Christian
On Tue, 25 Mar 2003 09:26:30 -0000
"Tom Melly" <tom### [at] tomandlucouk> wrote:
> "Christian Liesch" <lie### [at] gmxch> wrote in message
> news:200### [at] gmxch...
> > Hi all,
> >
> > I'm looking for a program that could translate a povray script to OpenGL C
> sources. Is there a way to do that? Else is there perhaps a povray script OpenGL
> interpreter?
> >
>
> I'm tempted to say 'forget it', but I've been caught out on that once before.
> Instead, I'll point you to Warp's VFAQ:
> http://www.students.tut.fi/~warp/povQandT/
>
> and the specific bit you should read is:
> http://www.students.tut.fi/~warp/povQandT/filesQandT.html#povtootherformatsdiffi
> culty
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> a écrit dans le message de news:
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message
news:3e8095f9@news.povray.org...
> 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?
Well, I was kind of thinking that an infinite plane would require an
infinite number of rays to trace since there would be an infinite number of
places that a ray could intersect (and that would be potentially in view).
However, on reflection, it occurs to me that:
a) the number of rays is limited by the resolution
and
b) that would just be silly.
Toodleoo.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Marc Jacquier" <jac### [at] wanadoofr> wrote in message
news:3e809ff1@news.povray.org...
> /*
> * These values determine the minumum and maximum distances
> * that qualify as ray-object intersections.
> */
Many thanks.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom & Lu Melly <all### [at] tomandlucouk> wrote:
> Well, I was kind of thinking that an infinite plane would require an
> infinite number of rays to trace since there would be an infinite number of
> places that a ray could intersect
A ray can intersect a plane only in one place. There's no way for a ray
to intersect a plane in more than one place (unless it bends somehow). :)
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Marc Jacquier <jac### [at] wanadoofr> wrote:
> #define Small_Tolerance 0.001
> #define Max_Distance 1.0e7
IMHO those values should be promptly changed...
--
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> a écrit dans le message de news:
3e80c6c4@news.povray.org...
> Marc Jacquier <jac### [at] wanadoofr> wrote:
> > #define Small_Tolerance 0.001
> > #define Max_Distance 1.0e7
>
> IMHO those values should be promptly changed...
I agree they are limitating when you need close-small and remote-huge
objects in the same scene
Marc
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanx, I think this will help me.
Only - it is not GPL software and the source distributen is awful ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3e80c672@news.povray.org...
>
> A ray can intersect a plane only in one place. There's no way for a ray
> to intersect a plane in more than one place (unless it bends somehow). :)
Sorry, I'm not explaining my question/confusion well (which is now pretty much
resolved).
A plane stretching to infinity would, presumably, need an infinite bounding box
(otherwise it's not infinite). An infinite number of rays would be required to
trace it, since there would be an infinite number of intersection points. This
would take an infinite amount of time. This is obviously wrong, but I was
curious as to how it was wrong, which I think I now largely understand.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <tom### [at] tomandlucouk> wrote:
> A plane stretching to infinity would, presumably, need an infinite bounding box
> (otherwise it's not infinite).
I think an infinite object does not have a bounding box at all.
> An infinite number of rays would be required to
> trace it, since there would be an infinite number of intersection points.
I don't understand how you came to this conclusion.
An infinite number of intersection points to calculate what? For one
pixel we need one intersection point (unless using antialiasing, which
means we may need something like 9 intersection points). What do you need
to calculate an infinite amount of intersection points for?
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote in message news:3e8175ca@news.povray.org...
>
> I don't understand how you came to this conclusion.
You obviously forgot to factor in my idiocy.
> An infinite number of intersection points to calculate what? For one
> pixel we need one intersection point (unless using antialiasing, which
> means we may need something like 9 intersection points). What do you need
> to calculate an infinite amount of intersection points for?
This is the solution to my confusion (and fairly bleedin' obvious when I think
about it). I was thinking that the number of rays required to trace an object
was dependant on the object's actual size (infinite in the case of a plane),
whereas the number of rays is more dependant on the area of the image that the
object occupies (always finite).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Warp" <war### [at] tagpovrayorg> wrote:
>
> I think an infinite object does not have a bounding box at all.
>
Internally, infinite objects are even kept in a separate list, at scene
root, outside of any hierarchies.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
