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...
};


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