|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Look at http://povtoray.chat.ru/
What would you say about it.?
Post a reply to this message
|
|
| |
| |
|
|
From: Christoph Hormann
Subject: Re: I have some external OOP interface for povray.
Date: 28 Apr 2004 09:40:02
Message: <c6oc0s$5m4$1@chho.imagico.de>
|
|
|
| |
| |
|
|
Xoid wrote:
> Look at http://povtoray.chat.ru/
> What would you say about it.?
>
Quoting from that site:
"Though POVray has C-like script language, it lacks such powerfull
things as loops, if/then statements, variables, OOP. It is easy to
excuse, becouse POVray distributed for free, and authors working hard on
graphic aspects of system, involving new rendering features and ray
processing."
That's not correct, apart from OOP (which you can argue about how useful
it would be for actual scene design) POV-Ray comes with all those
features you mention it has not.
The main disadvantage of your system to me seems you don't have access
to the internal functions of POV-Ray which otherwise are very important
for creating scenes.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 21 Mar. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
From: Warp
Subject: Re: I have some external OOP interface for povray.
Date: 28 Apr 2004 09:48:45
Message: <408fb63d@news.povray.org>
|
|
|
| |
| |
|
|
Xoid <xoid-at-yandex.ru> wrote:
> Look at http://povtoray.chat.ru/
> What would you say about it.?
Why do you do it in such needlessly complicated way?
The example in the page could perfectly be implemented like this (with
the proper modifications to the library):
#include "povtor.hh" // This is not a C header. Don't name it as if it was.
int main()
{
Frame frame("c:\\my\\sedlo.pov");
Camera cam(1050, 950, -500, -300, 0, 1500);
Light light(2000, 2000, 2000, 50, 5, 5);
frame << "#include \"colors.inc\"\n#include \"textures.inc\"\n\n"
<< "global_settings {ambient_light rgb<4,4,4>}\n\n"
<< cam << light;
Cylinder cyl(3); // Could have this kind of constructor to set the radius
// If it's odd, you could just do cyl.Radius(3) instead
for(int x = 0, y = 0; x < 1000; x += 10, y += 10)
{
cyl.SetEnds(x,y,0, x,1000-y,1000);
cyl.Texture.Color(1+sin((x+y)/500), 1+sin(x/300), 1+sin(y/300));
frame << cyl;
}
for(int y = 0, z = 0; y < 1000; y += 10, z += 10)
{
cyl.SetEnds(0,y,z, 1000,1000-y,z);
cyl.Texture.Color(1+sin(y/300), 1+sin(z/300), 1+sin(y+z/400));
frame << cyl;
}
frame.Render();
return 0;
}
--
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
|
|
| |
| |
|
|
From: Warp
Subject: Re: I have some external OOP interface for povray.
Date: 28 Apr 2004 09:50:38
Message: <408fb6ae@news.povray.org>
|
|
|
| |
| |
|
|
Christoph Hormann <chr### [at] gmxde> wrote:
> The main disadvantage of your system to me seems you don't have access
> to the internal functions of POV-Ray which otherwise are very important
> for creating scenes.
That's true. For instance being able to call trace() or inside() is
pretty handy sometimes. I don't see any easy way of doing the same
with a C++ frontend (at least not without a lot of work).
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 28 Apr 2004 09:50:38 -0400, Warp <war### [at] tagpovrayorg> wrote:
> > The main disadvantage of your system to me seems you don't have access
> > to the internal functions of POV-Ray which otherwise are very important
> > for creating scenes.
>
> That's true. For instance being able to call trace() or inside() is
> pretty handy sometimes. I don't see any easy way of doing the same
> with a C++ frontend (at least not without a lot of work).
Something like below (not perfect at all) workaround comes to my mind:
bool Inside(Object& obj,Vector& V)
{
Frame temp_frame("c:\\temp\\temp_file.pov");
temp_frame << "#declare Object =";
temp_frame << obj;
temp_frame << ";\n\n";
temp_frame << "#declare Vector =";
temp_frame << V;
temp_frame << ";\n\n";
temp_frame << "#declare is_inside = inside( Object , Vector );\n\n";
temp_frame << "#fopen MyFile \"c:\\temp\\temp_file.out\" write";
temp_frame << "#write (MyFile,is_inside)";
temp_frame << "#fclose MyFile";
temp_frame.render();
FILE *temp_file = fopen ("c:\\temp\\temp_file.out" , "r");
int is_inside = fgetc(temp_file);
fclose(temp_file);
return is_inside == '1';
}
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <s9fv80lihsserosev6uibg0jg6ps2gj89a@4ax.com>,
ABX <abx### [at] abxartpl> wrote:
> > That's true. For instance being able to call trace() or inside() is
> > pretty handy sometimes. I don't see any easy way of doing the same
> > with a C++ frontend (at least not without a lot of work).
>
> Something like below (not perfect at all) workaround comes to my mind:
Sorry, but...ew. Set up a scene, write the file to disk, and run a
POV-Ray render just to find out whether a single point is inside an
object?
A better option would be to implement the intersection and insideness
tests in C++. Of course, this practically entails writing a raytracer
instead of a simple interface, which is a little more work...or you
could write your code as an addition to POV-Ray.
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 28 Apr 2004 13:31:49 -0400, Christopher James Huff
<cja### [at] earthlinknet> wrote:
> In article <s9fv80lihsserosev6uibg0jg6ps2gj89a@4ax.com>,
> ABX <abx### [at] abxartpl> wrote:
>
> > > That's true. For instance being able to call trace() or inside() is
> > > pretty handy sometimes. I don't see any easy way of doing the same
> > > with a C++ frontend (at least not without a lot of work).
> >
> > Something like below (not perfect at all) workaround comes to my mind:
>
> Sorry, but...ew. Set up a scene, write the file to disk, and run a
> POV-Ray render just to find out whether a single point is inside an
> object?
Sure, wasting of CPU power, but only from POV-Ray/3D guru who has good
knowledge about math behind POV. I wrote that piece of code for those who
found original Xoid software usefull in current task and could looking for
this particular missed feature. I intentionally marked it "workaround". I
agree that in long run it deserves better solution.
ABX
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <web.408fadc5786546717a2708b0@news.povray.org>,
"Xoid" <xoid-at-yandex.ru> wrote:
> Look at http://povtoray.chat.ru/
> What would you say about it.?
As already mentioned, POV-Ray already has loops, conditionals, and
variables. Here's a POV-only version of your scene:
camera {
location < 1050, 950, -500>
look_at <-300, 0, 1500>
}
#include "colors.inc"
#include "textures.inc"
global_settings {ambient_light rgb <4,4,4>}
// <4,4,4> as the global ambient?!? Don't you think that might be
//a little high?
light_source {< 2000, 2000, 2000>, color <50, 5, 5>}
//Again, rather insane color values.
//More oddball color values here...the components will reach values of 2.
//This is legal, but highly unrealistic.
#local X = 0;
#local Y = 0;
#local Z = 0;
#while(X < 1000)
cylinder {< X, Y, 0>, < X, 1000 - Y, 1000 - Z>, 3
pigment {color rgb < 1 + sin((X + Y)/500),
1 + sin(X/300),
1 + sin(Y/300)>}
}
#local X = X + 10;
#local Y = Y + 10;
#end
#local Y = 0;
#local Z = 0;
#while(Y < 1000)
cylinder {< 0, Y, Z>, < 1000, 1000 - Y, Z>, 3
pigment {color rgb < 1 + sin(Y/300),
1 + sin(Z/300),
1 + sin((Y + Z)/300)>}
}
#local Y = Y + 10;
#local Z = Z + 10;
#end
That's it...it's shorter, generally clearer, you don't have to mess
around with allocating and deleting memory (though that is only a
problem with the design of your C++ library...it could isolate the user
from memory management), and you don't have to go through a
compile-link-run cycle to render the image. (Though that isn't as much
of a pain as it could be...my Lumini tracer is driven by C++, I use a
script that builds the executable, runs it, and does whatever else is
needed.)
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|