In my first-ever attempt at trying to decide on an object-oriented
programming language to learn (other than POV-Ray itself, that is!), I've
been looking at both Java and Python. In doing so, I'm beginning to see
similarities between the POV-ray scene description language and some of
Java (and perhaps some of Python as well, but I'm not sure yet!) POV
*seems* to use good parts of both...as well as improvements of it own...
but that's my rather uninformed opinion at this point.  I find the POV-ray
SDL easier and easier to work with, and would like to branch out into
learning one of the major, similarly-constructed languages. (Not C++ -- not
yet, anyway -- that's just too arcane for me right now. Big learning curve.)

My (really basic) question is this: Which OOP language is the POV-ray SDL
most similar to? (This question probably begs other questions, but it will
do for now.)

Ken W.

Post a reply to this message

Kenneth wrote:
> My (really basic) question is this: Which OOP language is the POV-ray SDL
> most similar to? (This question probably begs other questions, but it will
> do for now.)

None, because POV-Ray's current SDL is not an object-oriented language at
all. The syntax looks a lot like that of C/C++/Java of course, but that is
primarily due to the commenting style and the '{' and '}' everywhere.

	Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Kenneth wrote:
> > My (really basic) question is this: Which OOP language is the POV-ray SDL
> > most similar to? (This question probably begs other questions, but it will
> > do for now.)
>
> None, because POV-Ray's current SDL is not an object-oriented language at
> all. The syntax looks a lot like that of C/C++/Java of course, but that is
> primarily due to the commenting style and the '{' and '}' everywhere.
>
>  Thorsten

Fascinating. Thanks. Looks like I need to do a bit more research on what an
OOP language really is.

Ken W.

Post a reply to this message

> Fascinating. Thanks. Looks like I need to do a bit more research on what an
> OOP language really is.

Indeed yes.

The only "object oriented" thing about the SDL is that you create 
"objects" with it - as in, things that you can see on the screen.

"Object oriented programming" is a way of programming where you build 
program objects. Each such object belongs to a particular class and this 
defines what data the object contains and which operations can be 
performed upon it.

http://en.wikipedia.org/wiki/Object-oriented_programming

It would probably *be* useful if POV-Ray's SDL *was* OOP - but that is a 
debate that has been had many times, essentially without a consensus 
arrising.

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> The only "object oriented" thing about the SDL is that you create 
> "objects" with it - as in, things that you can see on the screen.

  The "objects" in POV-Ray have nothing to do with object-oriented
programming. The similarity in the name is just coincidence and is
not indicative in any way.
  Of course you made a pun there, but I just wanted to make sure that
nobody gets confused.

  There are basically three requirements for an OOP language:

1) Modules.
2) Inheritance.
3) Dynamic binding.

  In some OOP languages 2 and 3 are replaced with a delegation mechanism,
but basically it's almost the same thing (ie. doesn't make too much of a
difference in object-oriented design).

  The POV-Ray SDL lacks all 3 of those. (Well, ok, #include files could be
seen as *very* primitive modules, but just barely.)

  Modula is an excellent example of a programming language which has
(very advanced) modules but which is not an OOP language. Its modules
have public and private sections and you can make instances of these
modules in the exact same way as you can make instances of Java or C++
classes. This module mechanism resembles so much the classes of Java and
C++ that most people would erroneously call it an OOP language even
though technically it isn't.

  Besides modules, an OOP language needs inheritance and dynamic binding
mechanisms. This means that modules can have an "is-a" relationship and
that you can handle more concrete instances (iow. lower in the inheritance
hierarchy) with generic code designed for more abstract instances (iow.
upper in the inheritance hierarchy), which means that the exact same
code can handle different objects if they have a common base class.
Dynamic binding means that the objects can specialize (ie. reimplement)
functions of the base class, and these functions will be called instead
of the base class functions even in code which only handles objects of
the base class type.

> It would probably *be* useful if POV-Ray's SDL *was* OOP - but that is a
> debate that has been had many times, essentially without a consensus
> arrising.

  I don't think there even has been any question which requires some
consensus. Some people just resist change and don't want the current
SDL to be modified (even if the new one resembles it). Also some people
have the strange misconception that "supports feature X" means the same
as "you must learn to use feature X or you can't do anything at all".

-- 
                                                          - Warp

Post a reply to this message

>> The only "object oriented" thing about the SDL is that you create 
>> "objects" with it - as in, things that you can see on the screen.
> 
>   The "objects" in POV-Ray have nothing to do with object-oriented
> programming. The similarity in the name is just coincidence and is
> not indicative in any way.

Indeed, a ray tracer's idea of an "object" and a programmer's idea of an 
"object" are completely unrelated. Both can be highly variable, so they 
are given the generic name "object".


As an aside, if the SDL ever becomes object-oriented, the whole subject 
will become a whole lot more confusing. ;-)

(I think if that ever happened, we would need to sit down and have a 
careful think about terminology to try and keep people un-confused.)

Post a reply to this message

Orchid XP v3 <voi### [at] devnull> wrote:
> As an aside, if the SDL ever becomes object-oriented, the whole subject 
> will become a whole lot more confusing. ;-)

  Not really. C++ doesn't talk about "objects" anywhere in its syntax,
and neither has the SDL to do so (when referring to class instances).
Even the documentation could avoid the word "object" in relation to
class instances (and talk about "instances" instead).

-- 
                                                          - Warp

Post a reply to this message

What I'd be very interested in is if a future version of the POV SDL could
be parsed into some intermediate, platform-independent "bytecode"-like
format.

This would have benefits for parallel rendering, since a fast machine could
parse the scene, then distribute the pre-parsed scene info to other nodes.

Even better would be if the parsing could be done in parallel and the
results
recombined.. but I'm not holding my breath for that part :)

George
http://www.gammaburst.net

Post a reply to this message

George Pantazopoulos <go### [at] tomyaboutpage> wrote:
> This would have benefits for parallel rendering, since a fast machine could
> parse the scene, then distribute the pre-parsed scene info to other nodes.

  Parsing the SDL is actually often not the slowest part of the whole
parsing step. The vast majority of time usually goes into allocating
and setting up the objects and such.

  The exception is when the SDL has loops which loop a lot, in which
case a bytecode would speed up this interpretation. (For example, I once
compared the speed of an SDL code which just prints an ascii mandelbrot
set to stdout with a completely equivalent Perl code, and the latter was
approximately 13 times faster. This is because Perl compiles to bytecode
and then interprets that.)

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> George Pantazopoulos <go### [at] tomyaboutpage> wrote:
> > This would have benefits for parallel rendering, since a fast machine could
> > parse the scene, then distribute the pre-parsed scene info to other nodes.
>
>   Parsing the SDL is actually often not the slowest part of the whole
> parsing step. The vast majority of time usually goes into allocating
> and setting up the objects and such.
>
>   The exception is when the SDL has loops which loop a lot, in which
> case a bytecode would speed up this interpretation. (For example, I once
> compared the speed of an SDL code which just prints an ascii mandelbrot
> set to stdout with a completely equivalent Perl code, and the latter was
> approximately 13 times faster. This is because Perl compiles to bytecode
> and then interprets that.)
>
> --
>                                                           - Warp

Would it be possible to imagine such a thing: Develop Java POV-equivalent
classes and an adaptation layer though JNI that would parse Java code and
build the actual POV scene, and then render it by the actual POV engine
(adapted and activated by JNI)? Or am I off-track? It would be possible to
benefit all the power of the java syntax and modularity (and a debugger for
our macros).

Could one imagine something like this

import org.pov.*;
import org.pov.vegetation.*;
import org.pov.hormann.isowood.*;
import org.pov.tran.clouds.*;
import org.pov.someguru.WonderfulFeature4;
import org.pov.cabasson.PoorFeature1;

public class MyScene extends BasicOutDoorScene // Which extends POVScene,
and already has a light_source, a sun, and methods for the seasons and
Earth rotation ....
{
    public static main (int argc, String [] argv)
    {
        SetHandedness(LEFT_HANDEDNESS);

        GlobalSetting gs = new GlobalSettings();
        Radiosity rad = new RadiositySettings(); // Empty constructor with
defaults
        rad.setPretrace(0.04, 0.01);
        rad.setErrorbound(0.6);

        gs.setRadiosity(rad); // Or
gs.setRadiosity(Radiosity.OUT_DOOR_LOW_QUALITY)

        BuildScene();

        Render(640, 480);
    }

    private void BuildScene() // virtual method
    {
        final RADIUS = Double.parseDouble(argv[0]).doubleValue();

        Sphere s = new Sphere (0, RADIUS); // promotion is implemented by
method overloading: could be new Sphere (new Position(0,0,0), RADIUS) or so
....

        s.translate(10, 0, 0);
        s.rotate(-20, 0, 0);
        Pigment p = new Pigment(new Rgbt(1));
        Interior interior = new Interior();
        interior.setIor(Consts.GLASS_IOR);
        interior.setFadeColor(Colors.Blue);
        interior.setFadeDistance(s.getRadius()/2);
        s.setPigment(p);
        s.setInterior(interior);
        set.setPhotons(new ObjectPhotons(...));
        this.add(s);

        Plane ground = new Plane
        (
            y, 0,
            new Pigment
            (
                CHECKER,
                new ColorMap
                (
                    .../...
                ),
                new Turbulence(0.5, 2.0, 0.65, 8)
            )
        )
        ground.getPigment().setWarp(BLACK_HOLE, new Position(...));
        ground.getPigment().scale(2.0);
        this.add(ground);

        /// Etc ....

    }
}

If the java classes are well chosen, I think the java-equivalent syntax of a
scene could be as clear as sdl. Maybe more, when the scene would use lots of
complicated macros. Btw, JNI allows a DLL to call java code, then the sdl
function{} feature would execute at java speed (quite fast with HotSpot).

Then this scene would be rendered with a command line like:

java org.pov.MyScene 1.0

But I would not mind if you called me insane ... cos' I am  already  LOL

    Bruno

Post a reply to this message