Just out of curiousity....

IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
both?

If the scripting is changing, anyone fancy giving an approximation of a sphere
on check plane using 4.00 scripting?

--
#macro G(D,E,F)#local I=array[3]{D,E,F}#local B=0;triangle{#while(
B<3)#while(I[B])A[mod(I[B],10)]+#local I[B]=div(I[B],10);#end<-5,-
2,9>#local B=B+1;#end}#end #local A=array[7]{x,x*2,x*4,y,y*2,y*4,z
}light_source{-x*6-z*9,1}mesh{G(105,10,146)G(105,246,10)G(105,56,
146)G(105,1256,246)G(1256,126,220)G(22156,2216,201)pigment{rgb 1}}//TM

Post a reply to this message

Tom Melly <tom### [at] tomandlucouk> wrote:
: IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
: both?

  Most probably just the source.

  It will certainly make the life of patch-makers a LOT easier.

-- 
#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

>   Most probably just the source.
:,-(

Post a reply to this message

In article <3c57d5a1@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk> 
wrote:

> IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
> both?

The POV Team has said they were rewriting it in C++. Actually, the 
current source implements a kind of OOP, it is just hard to manage.
The scripting...it could be argued that it is already OOP: the various 
shapes are objects with a common interface (you apply textures, 
transformations, etc in the same way) and which can be arranged in a 
heirarchy, though they don't actually inherit from each other. The POV 
Team has mentioned they are considering reworking the language, but they 
haven't said anything more about it.


> If the scripting is changing, anyone fancy giving an approximation of a sphere
> on check plane using 4.00 scripting?

I highly doubt any of this has been decided yet...POV 4.0 doesn't even 
exist yet, and it will probably go through many changes. Even the syntax 
of POV 3.5 is still changing.
However, I'm guessing it would look something like it does now, at least 
recognizeable to someone who knows current POV script.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: The POV Team has said they were rewriting it in C++. Actually, the 
: current source implements a kind of OOP, it is just hard to manage.
: The scripting...it could be argued that it is already OOP

  It maybe modular, but it certainly is not object-oriented.
  Two basic requirements for object-orientedness are inheritance and dynamic
binding. Without those you just have a modular language, not object-oriented.

-- 
#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

Christopher James Huff <chr### [at] maccom> wrote in message
news:chr### [at] netplexaussieorg...
> In article <3c57d5a1@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk>
> wrote:
>
> > IIRC 4.0 will be OOP - does this just refer to the source, the scripting, or
> > both?
>
> The POV Team has said they were rewriting it in C++. Actually, the
> current source implements a kind of OOP, it is just hard to manage.
> The scripting...it could be argued that it is already OOP: the various
> shapes are objects with a common interface (you apply textures,
> transformations, etc in the same way) and which can be arranged in a
> heirarchy, though they don't actually inherit from each other. The POV
> Team has mentioned they are considering reworking the language, but they
> haven't said anything more about it.
>
>
> > If the scripting is changing, anyone fancy giving an approximation of a sphere
> > on check plane using 4.00 scripting?
>
> I highly doubt any of this has been decided yet...POV 4.0 doesn't even
> exist yet, and it will probably go through many changes. Even the syntax
> of POV 3.5 is still changing.
> However, I'm guessing it would look something like it does now, at least
> recognizeable to someone who knows current POV script.
>
> --
> Christopher James Huff <chr### [at] maccom>


About 5 years ago, I happened across a rayshade script for
some Lego blocks.

I wasn't able to obtain a working copy of rayshade, so I decided
to write a ray-tracer that would read the rayshade file.

I dug out my college notes from my Compilers course and my
CG course, did the geometry calcs, and had a basic ray-tracer
that could do basic primitives, bicubic patches, csg,
transformations, and some limited surfacing (like pigments,
ambient, diffusion, and reflections).  I even added some hooks
for animation.

The more I used it, the more I wanted to re-do it, making the
script object-oriented.  I had two main motivations:

----------------------------------------

First, I wanted to be able to access an object's parts after the
object had been defined to be able to make one instance
different from another.  A simplified example (using POV
pseudo-syntax):

#declare Part1 = cylinder { <0,0,0>, <0,1,0>, 1 pigment{Green}}
#declare Part2 = sphere { <0,0,0>, 1 pigment{White}}
#declare Piece = union {
  object{Part1}
  object{Part2 translate <0,1,0>}
}

#declare Piece1 = instance{Piece}
#declare Piece2 = instance{Piece}

#declare Piece2.Part1.pigment = Red;

So we get two pieces, but one is green and white, and the other
is red and white.

----------------------------------------

Second, I wanted to be able to access an object coordinate
space in order to connect to them.  For example, if I wanted my
model of a person to move its arms about while holding a bar in
both of its hands, I could do something like this:

#declare end1 = John.LeftArm.ForeArm.Hand.coord(<0,1,0>);
#declare end2 = John.RightArm.ForeArm.Hand.coord(<0,1,0>);

cyclinder { end1, end2, 1 }.

----------------------------------------

I since found POVRay, and have used it instead of my own
simply because it is SO much better.

I still, however, have hoped to find a ray-tracer or graphics tool
that has the OO features that I planned for my own rewrite.  I've
even considered writing a parser that would take an OO syntax
and generate standard POV code from it (once I have time for
something like that).

I know these things can be done in other ways using current POV
syntax, and I've done them.  I just think it would be easier to do in
an OO syntax.

--
Tom Bates

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
> : The POV Team has said they were rewriting it in C++. Actually, the
> : current source implements a kind of OOP, it is just hard to manage.
> : The scripting...it could be argued that it is already OOP
>
>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and
dynamic
> binding. Without those you just have a modular language, not
object-oriented.

you mean, if it would something like the following, it wouldn't be OO ?

----- Example, how _I_ would wish the SDL to be
... ----------------------------

#declare MySphere=sphere{<0,0,0>,5}
#declare MyMaterial=material{texture{pigment{color rgb 1}}}

MySphere.setCenter(<5,2,5>)
MySphere.setMaterial(MyMaterial)

MyMaterial.getTexture.setFinish(finish{ambient 0})

#declare MyBox=box{}
MyBox.setCorners(<-1,-2,-3>,<1,2,3>)
MyBox.setMaterial(MyMaterial.clone())
MyBox.getMaterial.getTexture.setFinish(finish{reflection 0.7 ambient 0.0
diffuse 0.2})
MyBox.translate(<-5,0,8>)

Scene.add(MyBox)
Scene.add(MySphere)
Scene.add(camera{lookAt 0, location y*5+z*-10})
Scene.add(lightSource{y*20, color rgb 1})

Scene.render()


-----------------------------------------------------------------------------
----

Maybe I've done too much Java ...

this would IMHO provide a certain degree of compatibility, and allow a
perfect
manipulation of objects, after they've been declared ...

The mainThing I prefer in this solution, is:
- you can declare Objs (maybe even only the frame of the obj)
- specify afterwards, how to manipulate it
- add it to the Scene-Object if it should be taken into account while
rendering
- you can specify the moment, when the scene should be rendered ...
- do some cleanup, or prepair the next frame to be rendered ...


--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

On 30 Jan 2002 15:19:27 -0500, Warp wrote:
> Christopher James Huff <chr### [at] maccom> wrote:
>: The POV Team has said they were rewriting it in C++. Actually, the 
>: current source implements a kind of OOP, it is just hard to manage.
>: The scripting...it could be argued that it is already OOP
> 
>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and dynamic
> binding. Without those you just have a modular language, not object-oriented.

I assume you're referring to the claim that POV SDL is OO here.  The POV
source, though written mostly in C, could be said to have both inheritance
and dynamic binding.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbt 1}hollow interior{media{emission T}}finish{
reflection.1}}#end Z(-x-x.2y)Z(-x-x.4x)camera{location z*-10rotate x*90}

Post a reply to this message

hehe ... maybe YOU will understand the other post, I made ...

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

In article <3c58554e@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   It maybe modular, but it certainly is not object-oriented.
>   Two basic requirements for object-orientedness are inheritance and dynamic
> binding. Without those you just have a modular language, not object-oriented.

If you're talking about the scripting language:
The shapes could be arranged in a heirarchy where they seem to "inherit" 
attributes:
The base "object" has transformations and textures, and all objects have 
double_illuminate, etc.
The solid objects have insides and can be hollow, but are objects. The 
patch objects do not have insides.
The sturm objects can use the sturm keyword for more accurate rendering, 
but are solid objects.
The blob and lathe objects are sturm objects.

The system is just so limited and static that dynamic binding is almost 
meaningless (almost...the individual shapes do "override" transformation 
as an optimization, for example, I'm pretty sure translating a sphere 
moves it's center).

What I was saying is that you could look at it like an object-oriented 
system, and the language could become a real prototype-based object 
oriented language with just a little modification.

If you're talking about the source code, it does a sort of dynamic 
binding using function pointers, and a sort of inheritance using macros 
to generate code common to all shapes.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

What about something like this:

------------------------------------------------------------------------
BEGIN or REAL Java code
------------------------------------------------------------------------
package samples.basic; 
 
import jxl.num.linalg.DoubleVector3; 
import jxl.graphics.color.*; 
import jpovapi.base.*; 
import jpovapi.pigments.*; 
import jpovapi.normals.*; 
import jpovapi.finishes.*; 
import jpovapi.textures.*; 
import jpovapi.lights.*; 
import jpovapi.objects.*; 
import jpovapi.atmosphere.*; 
import jpovapi.renderers.*; 
 
public class test { 
    public static void main(String[] args) { 
        Scene scn = new Scene();                               
 
        PerspectiveCamera cam = new PerspectiveCamera(); 
        cam.setAngle(70); 
        cam.setAspectRatio(4. / 3.); 
        cam.setLocation(new DoubleVector3(0, 4, -3)); 
        cam.setLookAt(new DoubleVector3()); 
        scn.setCamera(cam); 
 
        scn.add(new PointLight(new DoubleVector3( 20, 20, 20), new 
ColorDef(1., 1., 1.))); 
        scn.add(new PointLight(new DoubleVector3(-20, 20, 20), new 
ColorDef(1., 1., 1.))); 
        
        Finish f  = new Finish(); 
        f.setDiffuse(.9); 
        f.setAmbient(new ColorDef(.1, .1, .1)); 
  
        Texture t0 = new Texture(new SolidPigment(new ColorDef(1., 0., 
0.)), null, f); 
        Texture t1 = new Texture(new SolidPigment(new ColorDef(0., 1., 
0.)), null, f); 
 
        Sphere s = new Sphere(); 
        s.setTexture(t0); 
        s.setCenter(new DoubleVector3(0, .5, 0)); 
        s.setRadius(1); 
        scn.add(s); 
         
        Plane p = new Plane(); 
        p.setTexture(t1); 
        p.setNormal(DoubleVector3.Y); 
        p.setDistance(0); 
        scn.add(p); 
 
        RenderOptions ro = new RenderOptions(); 
 
        POVRayGenerator.generate(scn, ro); 
    } 
}

--------------------------------------------------------------------------------
END OF JAVA CODE
--------------------------------------------------------------------------------

Well?

Bye!!!
        Alessandro Coppo
        a.c### [at] REMOVEiolit

P.S.:
        A red sphere on a green plane with two lights.... ;-)

Post a reply to this message

Tom Melly wrote:

> Just out of curiousity....
> 
> IIRC 4.0 will be OOP - does this just refer to the source, the scripting,
> or both?

There is nothing to stop the embedding of an existing OO language ( like 
Ruby ) into the POV GUI with POV libraries or bindings to some form of POV 
API. This meta scripting language could drive the GUI and external 
utilities as well as be embedded into the POV SDL files.

You could, with a complete library, use Ruby right now as an OO meta 
language for generating POV code.

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
: you mean, if it would something like the following, it wouldn't be OO ?

  Precisely. What you described is a typical modular language.
  Modular languages (eg. Modula 2) can have classes, member variables,
member functions, public and private parts, etc, but if they don't support
inheritance and dynamic binding, they are not OO.

  OO just happens to have been the hype the last 10-20 years and people call
almost anything "object-oriented". There was a joke in some OO forums that
if you want to sell your cat, you shouldn't praise how nice and clean etc
the cat is, but you should say that the cat is object-oriented.
  People have some misunderstandings about what is object-oriented and what
isn't. Most of the time you hear/read about people discussing
object-orientedness, they are actually speaking about modularity.
  It's of course true that modularity is a very essential part of OO
programming (OO is like modularity + some extra stuff).
  I'm sure that many of these people, if they saw a language like Modula 2,
they would call it an object-oriented language.

  As I said earlier, a modular language becomes object-oriented when it
implements at least the two requirements: Inheritance and dynamic binding
(mostly virtual functions). Some modular languages do even support some
kind of inheritance (I don't remember if some version of Modula does), but
they don't support the dynamic binding part.

-- 
#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

Hmm, I just couldn't resist converting this to CSDL (or at least, 
something that resembles what CSDL eventually will be):


object POV = load("povray.csdl");

object MySphere = POV.Sphere {center = <0,0,0>; radius = 5;};

object MyMaterial = POV.Material;
MyMaterial.texture.pigment.color = < 1, 1, 1>;

MySphere.SetCenter(<5,2,5>);
MySphere.SetMaterial(MyMaterial);

MyMaterial.texture.finish.ambient = 0;

object MyBox = POV.Box {
    material = MyMaterial {
        texture.finish {
            reflection = 0.7;
            ambient = 0.0;
            diffuse = 0.2
        };
    };
};
MyBox.SetCorners(<-1,-2,-3>,<1,2,3>);
MyBox.Translate(<-5,0,8>);


POV.AddShape(MyBox)
POV.AddShape(MySphere)
POV.AddShape(
    object POV.LightSource {location = y*20; color = < 1, 1, 1>;});

POV.camera {look_at = 0; location = y*5 + z*-10;};

POV.render()

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: I assume you're referring to the claim that POV SDL is OO here.  The POV
: source, though written mostly in C, could be said to have both inheritance
: and dynamic binding.

  Yes, I was talking about the POV SDL.
  I know that the povray source code, even though written in C, uses pretty
much object-oriented features (of course it's a bit clumsy to do this in C,
as it has no direct support, but possible).

-- 
#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 <3c586bd2@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Modular languages (eg. Modula 2) can have classes, member variables,
> member functions, public and private parts, etc, but if they don't support
> inheritance and dynamic binding, they are not OO.

But Jan's example does use inheritance (the setCenter() and 
setMaterial() methods) and wasn't complex enough to show dynamic 
binding...


>   OO just happens to have been the hype the last 10-20 years and people call
> almost anything "object-oriented". There was a joke in some OO forums that
> if you want to sell your cat, you shouldn't praise how nice and clean etc
> the cat is, but you should say that the cat is object-oriented.

I've got some free kittens, they all demonstrate inheritance pretty 
obviously and are very dynamic...

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff <chr### [at] maccom> wrote:
: But Jan's example does use inheritance (the setCenter() and 
: setMaterial() methods)

  Uh? Calling a member function is not inheritance.

-- 
#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:
: Christopher James Huff <chr### [at] maccom> wrote:
: : But Jan's example does use inheritance (the setCenter() and 
: : setMaterial() methods)

:   Uh? Calling a member function is not inheritance.

  I think it would come closer to OO if you could do something like:

class MySphere: specializes sphere
{
  virtual setCenter(Coords)
  {
    do_something_with(Coords);
  }
}

  Then you could have functions (or macros) which take 'sphere' type objects
and to which you could give wither true spheres or your MySphere and if
this function calls 'setCenter', the correct implementation will be called.

-- 
#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

My Idea was, to have a constructor that resembles the "old" SDL ...
So with some minor wrappings, you could use old code and on the other
hand, can later modify it...

So pure Java was not the solution
(Except you put this constructor in as a String (Hey, thats the idea ...
I think, I can specify such a thing ... can I ?))

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

In article <586### [at] 3-enet>, Daniel Matthews <dan### [at] 3-enet> 
wrote:

> There is nothing to stop the embedding of an existing OO language ( like 
> Ruby ) into the POV GUI with POV libraries or bindings to some form of POV 
> API. This meta scripting language could drive the GUI and external 
> utilities as well as be embedded into the POV SDL files.

Well, there is one thing: licensing. The current POV license is pretty 
restrictive (though for very good reasons).
Of course, you could just write a library in that other language that 
generates a scene and calls POV. That should be perfectly legal, as long 
as you don't hide the fact that your program/library is a separate piece 
of software using POV-Ray. That's what I am doing for the CSDL POV-Ray 
scene library, and I think Moray does it.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

The first sentence was more a rethoric one ...

Reality is: _I_ (read that this means Me, and only Me) don't care, if SDL
resembles OO by the definition, or not... Maybe it would be enough, to stay
modular...

I just typed, what _I_ would like the SDL to be...
I've no complete concept of this yet, how to handle different types and
properties ...
Maybe it makes sense, to implement inheritance into this concept ...

BTW: wasn't modula2 this pascal-like thingie ? ... (I think it was the other
way around)

--
#macro J(N A)#local a=mod(N 3);#local W=<int(mod(A,4)*2)int(-A/4)9>*2;#if
(!mod(a 2))sphere{W,2,2pigment{color rgb<a*5A/2W.x/A*5>}}#if(a<1)sphere{W
+<2,0>2 2pigment{color rgb<a*10A 10>}}#end#end#if(N>3)J(int(N/3)A+1)#end#
end blob{J(29229171 0)threshold 1translate<-6 3>}/******Jan Walzer******/

Post a reply to this message

In article <3c586ea0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   Uh? Calling a member function is not inheritance.

Those member functions were pretty obviously inherited from "sphere".

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

On Wed, 30 Jan 2002 17:35:15 -0500, Christopher James Huff wrote:
> In article <3c586ea0@news.povray.org>, Warp <war### [at] tagpovrayorg> 
> wrote:
> 
>>   Uh? Calling a member function is not inheritance.
> 
> Those member functions were pretty obviously inherited from "sphere".

You're confusing objects with classes here.

-- 
#macro R(P)z+_(P)_(P)_(P+1)_(P+1)+z#end#macro Q(C,T)bicubic_patch{type 1u_steps
6v_steps 6R(1)R(3)R(5)R(7)pigment{rgb z}}#end#macro _(Y)#local X=asc(substr(C,Y
,1))-65;<T+mod(X,4)div(X,4)9>-2#end#macro O(T)Q("ABEFUQWS",T)Q("WSXTLOJN",T)#
end O(0)O(3)Q("JNKLCGCD",0)light_source{x 1}// ron### [at] povrayorg

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
:> Those member functions were pretty obviously inherited from "sphere".

: You're confusing objects with classes here.

  As I said in another article, there are lots and lots of
misunderstandings... :)

-- 
#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 <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> > Those member functions were pretty obviously inherited from "sphere".
> 
> You're confusing objects with classes here.

No, though I might have misunderstood Jan's example. I was assuming the 
complete lack of classes.
http://www.google.com/search?hl=en&q=prototype+based+object+oriented
http://www.cetus-links.org/oo_self.html

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Jan Walzer <jan### [at] lzernet> wrote:
: Reality is: _I_ (read that this means Me, and only Me) don't care, if SDL
: resembles OO by the definition, or not... Maybe it would be enough, to stay
: modular...

  In fact, the povray SDL has currently very poor means of achieving good
modularity.
  You can't make modules (classes, structs, whatever) with public interfaces
and private attributes and implementations, you can't construct your own
abstract data types, you can't make objects (ie instances of these data
types) and so on. You can't even construct the most basic types of dynamic
data containers (eg. lists, trees and so on; and yes, I know about arrays,
but they are currently just too clumsy and inefficient as *dynamic* data
containers).
  Just the possibility of defining structure types (á la C struct) and being
able to dynamically allocate them (and having references to these allocated
objects) would be an enormous step in versatility and modularity. Structures
and references cover most of the features needed for user-defined abstract
data types (although without interfaces they are still not very modular).

-- 
#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

Christopher James Huff <chr### [at] maccom> wrote:
:> There is nothing to stop the embedding of an existing OO language ( like 
:> Ruby ) into the POV GUI with POV libraries or bindings to some form of POV 
:> API. This meta scripting language could drive the GUI and external 
:> utilities as well as be embedded into the POV SDL files.

: Well, there is one thing: licensing. The current POV license is pretty 
: restrictive (though for very good reasons).

  I think that what he proposed was not embedding *povray* into a language
interpreter, but the other way around, ie. embedding a language interpreter
*into* povray. That is, just make a patch for another scripting language
support.

-- 
#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

In article <3c587c08@news.povray.org>, Warp <war### [at] tagpovrayorg> 
wrote:

>   I think that what he proposed was not embedding *povray* into a language
> interpreter, but the other way around, ie. embedding a language interpreter
> *into* povray. That is, just make a patch for another scripting language
> support.

He said "as well as be embedded into the POV SDL files".
Though I suppose you could do both...embed another language in the 
script, have another program go through, execute that code, replace it 
with POV code, and then pass the result on to POV-Ray.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c585ac5$1@news.povray.org>,
 "Tom Bates" <tho### [at] shawca> wrote:

> I still, however, have hoped to find a ray-tracer or graphics tool
> that has the OO features that I planned for my own rewrite.  I've
> even considered writing a parser that would take an OO syntax
> and generate standard POV code from it (once I have time for
> something like that).

Have you looked at my CSDL project? It will have a library that does 
just that.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Nice! What do I have to do to have a go at this stuff?

Christopher James Huff wrote:
> 
> Hmm, I just couldn't resist converting this to CSDL (or at least,
> something that resembles what CSDL eventually will be):

[code]

> --
> Christopher James Huff <chr### [at] maccom>
> POV-Ray TAG e-mail: chr### [at] tagpovrayorg
> TAG web site: http://tag.povray.org/

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

I don't think that it's possible to make the SDL completely OO. OOP is too
complex to be used in the POV-Ray SDL. An example: When creating an object,
several elements must be created: pigment, finish, texture, ... But who
creates them? Does the user have to call MyObject.add_finish? This wouldn't
be logical. An object has a finish, whether it's created by the user or not.
POV-Ray had to have a lot of pre-defined classes which provide all those
features.
Also, the POV-Ray parser is not very fast. OOP would make parsing even
slower. Why not creating scenes with an external program (like moray)?
Although pseudo-OOP would be a good idea (to acces elements like
MyObject.Part1.finish.phong).

Post a reply to this message

Looks like CSDL might be the future. Not that it'll stop us hand-coding
everything, but it's nice to have the option

Felix Wiemann wrote:
> I don't think that it's possible to make the SDL completely OO. OOP is too
> complex to be used in the POV-Ray SDL.
> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower. Why not creating scenes with an external program (like moray)?
> Although pseudo-OOP would be a good idea (to acces elements like
> MyObject.Part1.finish.phong).

-- 
signature{
  "Grey Knight" contact{ email "gre### [at] yahoocom" }
  site_of_week{ url "http://digilander.iol.it/jrgpov" }
}

Post a reply to this message

"Felix Wiemann" <Fel### [at] gmxnet> wrote in message
news:3c594865@news.povray.org...
> I don't think that it's possible to make the SDL completely OO. OOP is too
> complex to be used in the POV-Ray SDL. An example: When creating an
object,
> several elements must be created: pigment, finish, texture, ... But who
> creates them? Does the user have to call MyObject.add_finish? This
wouldn't
> be logical. An object has a finish, whether it's created by the user or
not.
> POV-Ray had to have a lot of pre-defined classes which provide all those
> features.

That's why you use object constructors :)

> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower. Why not creating scenes with an external program (like moray)?
> Although pseudo-OOP would be a good idea (to acces elements like
> MyObject.Part1.finish.phong).

True.  Maybe speed optimizations for the parser?

...Chambers

Post a reply to this message

Felix Wiemann <Fel### [at] gmxnet> wrote:
: Although pseudo-OOP would be a good idea (to acces elements like
: MyObject.Part1.finish.phong).

  What is "pseuso-OOP" and what does it have to do with getting individual
components of a module/structure?

-- 
#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 <3c594865@news.povray.org> , "Felix Wiemann" 
<Fel### [at] gmxnet> wrote:

> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower.

Sorry to say, but you don't know what your are talking about.  The parser
isn't slow, memory allocation for objects is slow.  It has been a topic in
these groups more than once.

Please note that 4.0 has been a topic of pointless discussion more than once
as what you say or don't say will not be considered for 4.0 in the first
place.  This has been made clear in various official statements. For example:

From: "Chris Cason"
Newsgroups: povray.announce.frequently-asked-questions
Subject: POV-Team Status Report - September 1, 2000
Date: Sun, 3 Sep 2000 22:29:58 +1100
Message-ID: <39b2364b@news.povray.org>
Xref: news.povray.org povray.announce.frequently-asked-questions:40


    Thorsten

Post a reply to this message

> That's why you use object constructors :)

But these constructors had to be pre-defined by POV-Ray, I meant.

Post a reply to this message

>   What is "pseuso-OOP" and what does it have to do with getting
> individual components of a module/structure?

You're right, "pseudo-OOP" is not the right word, better is "using of
structs".

Post a reply to this message

"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3c57d5a1@news.povray.org...
> Just out of curiousity....

Pardon me for speaking out of turn, because most of the people contributing
to this thread seem pretty on the ball with their languages, but doesn't POV
has a basic sort of inheritance anyway?

#local MySphere1=sphere {0 1 pigment {rgb 1}}

#local MySphere2=object {MySphere1 pigment {rgb 0}}

MySphere1 and MySphere2 come out different.  If you want cascading changes
similar to classes why not have something like:

#local MySphere2=object {MySphere1 inherit {all | include {some things or a
#declared collection of things} | exclude {other things or a #declared
collection of things} }

I know this kind of inheritance doesn't work for things like mesh2 objects
and their textures, but I think something like the above would make for more
friendly, and tighter, script than the other hypothetical examples posted in
this thread.

Or am I talking tosh?

Post a reply to this message

On Thu, 31 Jan 2002 19:12:28 -0000, Alan Holding wrote:
> Pardon me for speaking out of turn, because most of the people contributing
> to this thread seem pretty on the ball with their languages, but doesn't POV
> has a basic sort of inheritance anyway?

Yes, sort of, but not in the way you use the term when speaking of OO.  
POV can't have inheritance because it doesn't really have classes, and 
you can't talk about inheritance without using the notion of a class.

-- 
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end 
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}

Post a reply to this message

Alan Holding <tro### [at] tiscalicouk> wrote:
: #local MySphere2=object {MySphere1 inherit {all | include {some things or a
: #declared collection of things} | exclude {other things or a #declared
: collection of things} }

  This is the wrong concept of inheritance.
  Inheritance is not "make an object including some features of another
object and excluding other features, or changing some of the features".

  Inheritance is spezialization. A base class is a more generic concept
and an inherited class is specialization, ie. a more concrete version of
that concept. The inherited class is, by all means, a base class (with
some additions, implementations or specializations).
  For example, we could have a base class called 'Vehicle' which is a
generic concept. Then we could specialize a more concrete class 'Car' from
it. A 'Car' is a 'Vehicle' by all means. 'Car' knows and supports everything
'Vehicle' does. Everything that uses an object of the 'Vehicle' can use an
object of type 'Car'.

-- 
#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:3c59a0c1@news.povray.org...
>   For example, we could have a base class called 'Vehicle' which is a
> generic concept. Then we could specialize a more concrete class 'Car' from
> it. A 'Car' is a 'Vehicle' by all means. 'Car' knows and supports
everything
> 'Vehicle' does. Everything that uses an object of the 'Vehicle' can use an
> object of type 'Car'.

To relate this (hypothetically) to POV, we could have:
Object
    Solid
        Infinite
            Plane
        Finite
            Sphere
            Box
            Cone
    Patch
        Poly
        Mesh
        Bicubic

(This is just a start, of course)

Hmm... Perhaps the "Solids" could be divided into prisms (defined by flat
surfaces, not sure what the technical term is) and curves.

...Chambers

Post a reply to this message

"Ben Chambers" <bdc### [at] yahoocom> wrote in message
news:3c5a448e@news.povray.org...
<snip>

Of course, the more I think about it, the sillier I feel for not using
multiple inheritance - a simple tree like that wouldn't give you everything
you need :)

...Chambers

Post a reply to this message

Ben Chambers <bdc### [at] yahoocom> wrote:
: To relate this (hypothetically) to POV, we could have:
: Object
:     Solid
:         Infinite
:             Plane
:         Finite
:             Sphere
:             Box
:             Cone
:     Patch
:         Poly
:         Mesh
:         Bicubic

  The inheritance hierarchy in the C++ code of povray 4 will probably look
something like that.
  Of course it doesn't mean that the SDL will look like that.

-- 
#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

In article <slr### [at] fwicom>,
 Ron Parker <ron### [at] povrayorg> wrote:

> POV can't have inheritance because it doesn't really have classes, and 
> you can't talk about inheritance without using the notion of a class.

Not true, prototype-based languages don't have classes. Objects inherit 
from other objects.
And in some languages that are closer to being class-based, the classes 
themselves are still objects. Not all languages are like C++ or Java.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3c5a45f6@news.povray.org>,
 "Ben Chambers" <bdc### [at] yahoocom> wrote:

> Of course, the more I think about it, the sillier I feel for not using
> multiple inheritance - a simple tree like that wouldn't give you everything
> you need :)

Multiple inheritance is not needed...many languages don't have it, but 
use other mechanisms.
Anyway, you're missing a branch:
object
    solid
    patch
    aggregate (CSG objects...not necessarily solid. Meshes are still 
patch objects.)

Things like global_settings, the camera, light sources, etc. would need 
modification to fit in this heirarchy, of course...that's if you want 
that. "object" could have the meaning of a language object instead of a 
shape.

object
    global_settings
    transformable_object
        texture, ...
        camera
        light_source
        shape
            solid, patch, aggregate...

Many of these would never be seen by the user, they would only exist to 
help categorize things.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3C594F53.68A90D4B@namtar.qub.ac.uk>,
 Grey Knight <s16### [at] namtarqubacuk> wrote:

> Looks like CSDL might be the future. Not that it'll stop us hand-coding
> everything, but it's nice to have the option

Well, CSDL isn't made for scene description, it could be a bit awkward 
for that. It is a testbed for some ideas I have about the POV scene 
description language though.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

In article <3C592023.7D965CDC@namtar.qub.ac.uk>,
 Grey Knight <s16### [at] namtarqubacuk> wrote:

> Nice! What do I have to do to have a go at this stuff?

It's currently in very early alpha...very much in progress. It isn't far 
along enough to handle the code I posted, though it is close. I post 
announcements of releases and progress to this group.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

>   The inheritance hierarchy in the C++ code of povray 4 will probably
>   look 
> something like that.
>   Of course it doesn't mean that the SDL will look like that.
> 

I *really* hope the sdl gets completely redone for pov 4.  Imo, an object-
oriented approach would be much cleaner & prettier.  I would love to see a 
more powerful sdl (cleaner (no more '{'s and '#'s, for example), user-
defined data types, fast, etc.) in pov 4.  It would also be neat if it were 
possible to implement a platform dependant jit compiler that could sort of 
"plug in" to an existing installation (like  Sun's "hotspot" thing).  Has 
anyone considered using an existing scripting language, such as Lua or 
Python, as the pov sdl?  This is *exactly* the sort of thing these langs 
were designed for.

Jordan

P.S.  Maybe someone should write a pov compiler that targets the CLR & 
.NET.  Just kidding...;-P

Post a reply to this message

Jordan <hookflash@_hotmail_.com> wrote:
: I *really* hope the sdl gets completely redone for pov 4.

  I don't. How many people out there do you think that will like that
none of their scenes will work with the new version and that they will have
to learn a completely new language?

:  Imo, an object-
: oriented approach would be much cleaner & prettier.

  OOP is not the solution for everything.
  I don't think the povray SDL would benefit too much from a full OO language.
  Some modularity could be good (user-defined abstract types with member
variables and methods, dynamic allocation, references...), but that's it.

:  I would love to see a 
: more powerful sdl (cleaner (no more '{'s and '#'s, for example)

  I don't understand why it would be "more powerful" and "cleaner" with
no '{'s and '#'s.
  Specially the lack of '{'s would make it uglier and harder to write and
read.
  (No, I *DON'T* want to start writing 'begin' and 'end' like in Pascal.)

-- 
#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

In article <3c5bb4d3@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   (No, I *DON'T* want to start writing 'begin' and 'end' like in Pascal.)

Worked great in DKBTrace...

    Thorsten

Post a reply to this message