 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I started making library to generate pov SDL with c++. The idea is to
have API like this:
int main() {
p_camera();begin();
p_look_at(); p_vector(2,3,2);
p_angle(); p_float(135);
end();
box(); begin();
p_float(-1); p_float(9);
p_pigment(); begin();
p_rgb(.8);
end();
p_finish();begin();
p_reflection(); p_float(.3);
end();
end();
}
which produces POV SDL like this:
camera { look_at <2,3,2> angle 135 } box { -1 9 pigment { rgb 0.8 }
finish { reflection 0.3 } }
Large parts of this API can be generated directly from list of reserved
words and only some parts need to be hand coded (vector, color etc.).
With this API one could implements his own routines and take advantage
from full power of c++. Greatest problem I see is that error messages
would be difficult to map into code.
void camera(vector a,vector b,float c)
{
p_camera();p_begin();
p_location();p_vector(a);
p_look_at();p_vector(b);
p_angle();p_float(c);
p_end();
}
Here is what I have allready made
http://www.cs.helsinki.fi/u/ojamies/pov++/
I have just joined these groups so I don't know if someone has allready
made this kind of system for POV (and I don't have patience to read few
thousand mail headers). Does anyone have links?
pto
--
camera{look_at y+2angle 135} box{-1 9pigment{rgb.8} finish{reflection.3}
no_image}#macro l(a) light_source{8*a rgb a/vlength(a)fade_power 2
fade_distance 3}#end l(x)l(y)l(z)l(1-x)l(1-y)l(1-z)l(x+y+z) sphere{4 3
finish{reflection 1}no_shadow}//pto
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"pto" <oja### [at] cs helsinkifi> wrote in message
news:3D5### [at] cshelsinkifi...
>
<snip>
Just out of curiosity, what would be the point of this? (I have a pretty good
idea, but seek clarification).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I can't but wonder how writing this:
> int main() {
> p_camera();begin();
> p_look_at(); p_vector(2,3,2);
> p_angle(); p_float(135);
> end();
> box(); begin();
> p_float(-1); p_float(9);
> p_pigment(); begin();
> p_rgb(.8);
> end();
> p_finish();begin();
> p_reflection(); p_float(.3);
> end();
> end();
> }
would be better than writing this:
> camera { look_at <2,3,2> angle 135 } box { -1 9 pigment { rgb 0.8 }
> finish { reflection 0.3 } }
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
pto <oja### [at] cshelsinkifi> wrote in news:3D5### [at] cshelsinkifi
>
> I started making library to generate pov SDL with c++. The idea is to
grr... that is my idea ! ;-)
and about point of this - making complicated images/animations that would
be REALY hard to do via SDL only. Watch .b.i in inext few days :)
--
#macro g(U,V)(.4*abs(sin(9*sqrt(pow(x-U,2)+pow(y-V,2))))*pow(1-min(1,(sqrt(
pow(x-U,2)+pow(y-V,2))*.3)),2)+.9)#end#macro p(c)#if(c>1)#local l=mod(c,100
);g(2*div(l,10)-8,2*mod(l,10)-8)*p(div(c,100))#else 1#end#end light_source{
y 2}sphere{z*20 9pigment{function{p(26252423)*p(36455644)*p(66656463)}}}//M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> I can't but wonder how writing this:
>
>
>>int main() {
>> p_camera();begin();
>> p_look_at(); p_vector(2,3,2);
>> p_angle(); p_float(135);
>> end();
>
>
>> box(); begin();
>> p_float(-1); p_float(9);
>> p_pigment(); begin();
>> p_rgb(.8);
>> end();
>> p_finish();begin();
>> p_reflection(); p_float(.3);
>> end();
>> end();
>>}
>
>
> would be better than writing this:
>
>
>>camera { look_at <2,3,2> angle 135 } box { -1 9 pigment { rgb 0.8 }
>>finish { reflection 0.3 } }
>
>
It would seem to be that they are letting the computer do the writing.
Maybe they want to generate some data and let the program genetate
"snapshots" of what is going on that POV will then render...
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Looks a little similar to OpenGL. Something like "begin(kCamera)" would
be more compact and get rid of the repetitive "xxx(); begin();" pattern.
You would of course put it in its own namespace to avoid name conflicts.
I don't really see the point of this approach though, it doesn't take
advantage of any C++ features. The only advantage I see is that it could
probably be mostly automatically generated. How about something more
like:
begin("camera");
key("look_at"); vecval(2, 3, 2);
key("angle"); vecval(135);
end();
or:
//the constructor pushes the camera onto a stack of things being
//constructed
Camera cam1();
key("look_at"); vecval(2, 3, 2);
key("angle"); vecval(135);
Close();//Pops the camera off the construction stack
SetCamera(cam1);
I wouldn't like using either of these though, I personally would do
something like:
Scene scene;
scene.SetCamera(PerspectiveCamera);
scene.GetCamera().SetLookAt(vec(2, 3, 2));
scene.GetCamera().SetAngle(135);
Material boxMat;
boxMat.SetPigment(SolidPigment(0.8));
boxMat.GetFinish().SetReflection(0.3);
scene.AddShape(Box(-1, 9, boxMat));
scene.OGLPreview();
outfile << scene;
This is similar to what I'm doing for the CSDL/Sapphire POV library,
though things are a little different with a prototype-based OOL.
Sapphire is slower than C++ because it is interpreted, but faster and
more flexible than POV-Script. It will look more like:
delegate load POV: "povray.csdl";
function run() {
.camera.SetLookAt(< 2, 3, 2>);
.camera.SetAngle(135);
//make() is a method of the POV-Ray library object that
//clones a shape object and adds the clone to the scene,
//and returns the clone.
.make(.Box) {
pta = -1;
ptb = 9;
material {
clone pigment: SolidPigment {color = 0.8};
finish.SetReflection(0.3);
};
};
clone fout: stream;
fout.open("outputfile.pov");
fout.write(POV);
};
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
The C++ version could be used in a C++ program that does things like
particle and cloth simulation that are difficult to program and
extremely slow to compute directly in POV.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> The C++ version could be used in a C++ program that does things like
> particle and cloth simulation that are difficult to program and
> extremely slow to compute directly in POV.
I don't see any reason for making it that complicated.
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
It still looks kind of ugly.
With the power or C++, you can get close to what POV-Ray SDL does. For
example, you could have a vector class which is almost as flexible as in
povray, like:
class Vec
{
public:
Vec();
Vec(double);
Vec(double, double, double);
Vec(const Vec& rhs);
Vec operator+(const Vec& rhs);
Vec operator-(const Vec& rhs);
Vec operator*(const Vec& rhs);
// etc etc...
};
// Some global definitions á la povray:
const Vec x(1,0,0);
const Vec y(0,1,0);
const Vec z(0,0,1);
double vlength(const Vec&);
// etc etc...
For example the camera object could be defined as:
class Camera
{
public:
Camera(const Vec& location = -z, const Vec& look_at = 0);
Vec location();
void location(const Vec& loc);
// etc etc...
};
When the library is defined like that, you could create a scene like this:
Camera cam(Vec(1,2,3), 0);
// Could also be:
// Camera cam(-z*20, y*2); // or Camera cam(10, Vec(1,2,3));
// or:
// Camera cam;
// cam.location(Vec(1,2,3)); // or cam.location(5);
// cam.look_at(0); // or cam.look_at(Vec(2,3,4));
cam.angle(35);
Light l(Vec(4,5,6), 1);
// Could also be:
// Light l(y*100, x+y);
Box obj1(-1, 1)
Sphere obj2(y, 1), obj3(x, .5);
Difference csg1;
csg1 << obj1 << obj2 << obj3;
csg1.texture(Texture(Pigment(RGB(.5,1,1))));
outfile << cam << l << csg1;
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I have something similar in Java that I plan on releasing, I just haven't
had the time to clean it up. I wanted objects to work with rather than a
scripting language. It allows you to create things like tables that you can
query later, to ask how to place things on top of them. There are tons of
uses. Here's a snippet from some of my code.
public static void main(String[] args) {
SceneQuick scene = new SceneQuick();
scene.setGroundPlane(false);
scene.build();
{
Camera camera = new Camera("45");
camera.setLocation(0, 2, -6);
camera.setLookAt(0, 0, 0);
camera.rotate(0,45,0);
scene.addCamera(camera);
}
SurfaceFactory surfaces = D3PartFactory.getSurfaceFactory();
D3Object obj = scene.add(new Xylophone());
obj.rotate(0,30,0);
//obj.translate(0,0.0,0);
Camera camera = scene.getCamera(0);
camera.setLocation(0, 4.5, -6.0);
camera.setLookAt(0, 0, 0);
camera.rotate(0,45,0);
scene.add(new LightSource(LightSource.POINTLIGHT, new D3Vector(
30,1,-30), surfaces.colour(1,1,1)));
scene.add(new LightSource(LightSource.POINTLIGHT, new
D3Vector(-30,1,-30), surfaces.colour(1,1,1)));
try {
scene.render(args);
}
catch(Throwable t) {
t.printStackTrace();
}
}
--
#macro Q(A,E,W)box{-A/2,A/2pigment{rgb 9*W}translate E*A+W/1000}#end#macro
M(D,E)#local A=1/pow(3,D);#if(D<3)#local C=D+1;union{M(C,1)M(C,x+y)M(C,x+z)
M(C,y+z)M(C,x+y-z)M(C,x+z-y)M(C,y+z-x)M(C,x-y)M(C,z-x)M(C,y-z)M(C,y-x)M(C,
x-z)M(C,z-y)M(C,x-y-z)M(C,y-x-z)M(C,z-x-y)translate A*E}#else Q(A,E,x)Q(A,E
,y)Q(A,E,z)#end#end union{M(0,0)rotate<45,145,0>translate z*2}//Andrew
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d5bf720@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> With the power or C++, you can get close to what POV-Ray SDL does. For
> example, you could have a vector class which is almost as flexible as in
> povray, like:
I know, I have constructed such a class for my raytracer and assumed one
for my example. Mine is just named "Vect3D" instead of "Vec", and for
this example it is called "vec".
> Camera cam(Vec(1,2,3), 0);
I was trying to make an equivalent to the original scene, which only
modifies the look_at and angle. A constructor with these didn't make
sense to me, so I did it with methods. My PerspectiveCamera would have
that constructor though, "PerspectiveCamera cam(vec(1,2,3), 0);" would
be perfectly valid.
> Box obj1(-1, 1)
> Sphere obj2(y, 1), obj3(x, .5);
> Difference csg1;
> csg1 << obj1 << obj2 << obj3;
> csg1.texture(Texture(Pigment(RGB(.5,1,1))));
>
> outfile << cam << l << csg1;
I don't see how this is significantly different from my example, except
you don't have a scene object to manage things and I wouldn't use the <<
operator to insert shapes into a CSG. I assumed a vector and color class
like you have, that's nothing different. There are some other
differences, in my version vlength() would be Vec::Length().
Aside from slightly different names, your code would work fine with my
framework. What "looks ugly" in my example that doesn't in yours?
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Just out of curiosity, what would be the point of this? (I have a pretty good
> idea, but seek clarification).
The point is, that real programming languages are much more powerfull
than pov sdl. Even more important is that there is huge amount of
ready-made sourcecode for c/c++ (like ik systems, cloth etc.).
Idea is not to write those stupid-looking commands that are about three
times longer than real pov sdl, but to wrap it in component's that would
be wery easy to use. These stupid command are only here as the lowest
level that should be practically same as the SDL.
Making that higher-level API above this is a bit more complex project.
I understand why you find this idea weird, but I think many non-povies
could find this guite nice. You could also ask why povray should have
it's own dedicaded programming language instead of using pov through a
library?
Btw. The idea came when I was debating with my friend about differences
between bmrt and pov. He argued that it is not necesary to develop pov
sdl to more expressive language. Instead there should be this kind of
API for some language.
Btw2. I heard that bmrt is not doing too well.
pto
--
camera{look_at y+2angle 135} box{-1 9pigment{rgb.8} finish{reflection.3}
no_image}#macro l(a) light_source{8*a rgb a/vlength(a)fade_power 2
fade_distance 3}#end l(x)l(y)l(z)l(1-x)l(1-y)l(1-z)l(x+y+z) sphere{4 3
finish{reflection 1}no_shadow}//pto
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
> Aside from slightly different names, your code would work fine with my
> framework. What "looks ugly" in my example that doesn't in yours?
For example:
scene.GetCamera().SetLookAt(vec(2, 3, 2));
vs:
cam.look_at(Vec(2, 3, 2));
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3d5cd5be@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
> > Aside from slightly different names, your code would work fine with my
> > framework. What "looks ugly" in my example that doesn't in yours?
>
> For example:
>
> scene.GetCamera().SetLookAt(vec(2, 3, 2));
>
> vs:
>
> cam.look_at(Vec(2, 3, 2));
This would work just as well:
PerspectiveCamera cam;
cam.SetLookAt(vec(2, 3, 2));
scene.SetCamera(cam);
Or this:
#define look_at SetLookAt
typedef vec Vec;
...
cam.look_at(vec(2, 3, 2));
A #define and a typedef and the exact same code will work.
The only difference is the name of the method for setting the look-at
point, and the fact that I used a scene object in my example. I don't
see how "SetLookAt" is so much uglier than "look_at", it is just a
different naming convention: method names starting with capitals with
each internal "word" of the name starting with a capital, instead of all
lower case with words separated by underscores.
I broke my naming convention of capitalizing class names for "vec" to
make it easier to type, my own vector class is "Vect3D", but I don't
think you're complaining about 'V' vs. 'v'. Just assume a typedef in the
header file.
Are you complaining about the scene object? It isn't necessary, but can
make things much more convenient and less complicated. It would set up a
default scene, show an OpenGL preview, automatically generate a file and
run POV or some other renderer on it...
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3D5### [at] cshelsinkifi>,
pto <oja### [at] cshelsinkifi> wrote:
> The point is, that real programming languages are much more powerfull
> than pov sdl. Even more important is that there is huge amount of
> ready-made sourcecode for c/c++ (like ik systems, cloth etc.).
More precisely, it is easier to do complex things in other languages and
the result is much faster. There is no real distinction between
POV-Script and a "real programming language".
> Btw. The idea came when I was debating with my friend about differences
> between bmrt and pov. He argued that it is not necesary to develop pov
> sdl to more expressive language. Instead there should be this kind of
> API for some language.
The existing scene language allows you to access all the features of
POV, so there isn't really a need for a special API, just write code
that writes a scene file.
> Btw2. I heard that bmrt is not doing too well.
If by "not doing too well" you mean "dead", then yes. Fairly permanently
too, apparently.
It has a good sized community behind it though, it won't stop being used
soon and I wouldn't be surprised to see a clone project.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Doing this work in Python...
I plan to release the thing before Christmas (too much work and burdens).
Bye!!!
--
Alessandro Coppo
a.coppo@<REMOVE_ME>iol.it
www.geocities.com/alexcoppo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly wrote:
>Just out of curiosity, what would be the point of this? (I have a pretty good
>idea, but seek clarification).
For semi- (or actual) simulation projects, this sort of thing would be
useful. I once ran into things that would be better done outside the SDL
rather than within it, or perhaps I was corrupted when I started pretending
to program in an object-orientated fashion. However, I think that the
inverse problem to this is the harder (SDL -> other language); it's pretty
simple to talk SDL with a few choice printf/ostream/equivalent commands for
most simulations, I would've thought. Or just read the simulation output
from within POV using the SDL file commands.
There seem to be many C++/other languages -> SDL projects going on, but few
SDL -> C++ projects. Is anyone else looking at this?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> There is no real distinction between
> POV-Script and a "real programming language".
>
Now there's a statement that could spark an argument over p.o-t[1]... ;)
--
Pandora/Scott Hill/[::O:M:C::]Scorpion
Software Engineer.
http://www.pandora-software.com
[1] though, is it really 'off-topic' ? maybe we need a
povray.not-quite-off-yet-not-quite-on-either-topic group... ;)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
