andrel wrote:

> is better left out. At this point I cannot judge very well because I
> still have no good perception of how an OOPOV would look, but perhaps

There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

Post a reply to this message

Tom Melly <pov### [at] tomandlucouk> wrote:
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

  If it were solely up to me, it would look as much as C++ as possible.

  However, it's not up to me. (Fortunately? ;) )

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

"Tom Melly" <pov### [at] tomandlucouk> wrote in message
news:4033cd07@news.povray.org...
> andrel wrote:
>
> > is better left out. At this point I cannot judge very well because I
> > still have no good perception of how an OOPOV would look, but perhaps
>
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?

I'm sorry; I know you didn't ask me. I have some ideas of how it could look:


object ColoredSphere (v, c) inherits Sphere
{
    pigment
    {
        color = c
    }
}

object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))

show red_sphere
show green_sphere


Off the top of my head, I could see this being useful. You could also do
this:

red_sphere.pigment.color = new Color.White

which you can't do right now.

Post a reply to this message

In article <cjameshuff-9D70B1.13425418022004@news.povray.org>, 
cja### [at] earthlinknet says...
> In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet> 
> wrote:
> 
> > Not me. It would add another layer of complexity that I don't want to have
> > to bother to learn. OO is for programming not a scene description language.
> > If I wanted to learn programming I would do that rather than using POV-Ray.
> 
> You only say that because you don't know what it would add. It would not 
> add complexity, it would greatly simplify many things.
> 
> 

I am seriously confused about what it would simplify... SDL already does 
most everything that OO stuff can. The one and only thing I can think of 
is the ability to over-ride specific attributes, the way you can replace 
an existing function in an object with a new one:

#define Motorcycle1 = object {Motorcycle}

object {
  Motorcycle1 {
    #replace Motorcycle1.Handlebars.texture{blah....}
  }
}

So you could start with an entirely prebuilt object and change any single 
item in it by directly replacing that item. However, for it to work, each 
individual object would need a unique name or you would need to have some 
way to index which of the objects in a CSG you are applying the changes 
to or adding/removing.

Is the above sort of what you are talking about? Because otherwise I 
don't get what OO feature you are talking about that the SDL doesn't 
already support in some fashion...

-- 
void main () {

    call functional_code()
  else
    call crash_windows();
}

Post a reply to this message

Dan P wrote:

> "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> news:4033cd07@news.povray.org...
> 
>>andrel wrote:
>>
>>
>>>is better left out. At this point I cannot judge very well because I
>>>still have no good perception of how an OOPOV would look, but perhaps
>>
>>There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
> 
> 
> I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
> 
> 
> object ColoredSphere (v, c) inherits Sphere
> {
>     pigment
>     {
>         color = c
>     }
> }
> 
> object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
> object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))
> 
> show red_sphere
> show green_sphere

I do not see why the current syntax with macros does not suffice here.

> 
> Off the top of my head, I could see this being useful. You could also do
> this:
> 
> red_sphere.pigment.color = new Color.White
Well if it allows you to have an object that is called red_sphere but
is actually white then we are in deep trouble.

Just kidding, I understand what you mean. My first reaction would be
that pigments can be much more complicated than just a simple color.
That is what POV makes exciting. I do not immediately see how you can
handle that complexity in a understandable way. I will think about that
(later).

Post a reply to this message

"Christopher James Huff" <cja### [at] earthlinknet> wrote
> In article <Xns94937169A2BACseed7@news.povray.org>,
>  ingo <ing### [at] tagpovrayorg> wrote:
>
> > If I want to read and understand those future OO-scenefiles, I'll have to
> > learn the new features. "Use" is more than just writing scenes.
>
> And reading and understanding the ugly, complex hacks used to work
> around the lack of object oriented features would be easier?

Or understanding entries to the short code contest? ;)

But seriously, I've seen plenty of scene files where I don't have a clue what's
happening, like where they use some feature of pov that I've never seen before.
Sometimes I think it's worth reading the manual to find out what it does,
sometimes I decide I'd rather not know. I don't think OO would make this much
worse.

Though I do think OO would run the risk of getting too far away from the SDL
being a language to describe scenes (objects that are conceptual not visible!?).

-- 
Tek
www.evilsuperbrain.com

Post a reply to this message

I think there's a lot of confusion between OO objects and pov's object {}. I
never intended for the two to be the same thing.

What I need for my scene is the concept of a data structure which can hold a
series of "function" calls (actually macro calls) according to what type of
structure it is. It does not need to be associated with anything renderable.
This just extends the range of possibilities for how pov's macro language can be
used to perform calculations or procedural scene generation, etc.

I can see some uses for having OO objects associated with pov objects, but I
think it would REALLY defeat the point if you are forced to have that
association. For example, you could create a tree using an object that creeps
along the trunk, leaving a trail of spheres, then spawns another object for each
branch, etc... so there would be many more spheres than there are OO objects.

Anyway, just my 2 cents. I'm gonna get on and write my macros :)

-- 
Tek
www.evilsuperbrain.com


"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1a9d8de2d9dc8dc39899ad@news.povray.org...
> In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
> cja### [at] earthlinknet says...
> > In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> > wrote:
> >
> > > Not me. It would add another layer of complexity that I don't want to have
> > > to bother to learn. OO is for programming not a scene description
language.
> > > If I wanted to learn programming I would do that rather than using
POV-Ray.
> >
> > You only say that because you don't know what it would add. It would not
> > add complexity, it would greatly simplify many things.
> >
> >
>
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can. The one and only thing I can think of
> is the ability to over-ride specific attributes, the way you can replace
> an existing function in an object with a new one:
>
> #define Motorcycle1 = object {Motorcycle}
>
> object {
>   Motorcycle1 {
>     #replace Motorcycle1.Handlebars.texture{blah....}
>   }
> }
>
> So you could start with an entirely prebuilt object and change any single
> item in it by directly replacing that item. However, for it to work, each
> individual object would need a unique name or you would need to have some
> way to index which of the objects in a CSG you are applying the changes
> to or adding/removing.
>
> Is the above sort of what you are talking about? Because otherwise I
> don't get what OO feature you are talking about that the SDL doesn't
> already support in some fashion...
>
> -- 
> void main () {

>     call functional_code()
>   else
>     call crash_windows();
> }

Post a reply to this message

"andrel" <a_l### [at] hotmailcom> wrote in message
news:403### [at] hotmailcom...
>

> > "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> > news:4033cd07@news.povray.org...

<snip />

> > red_sphere.pigment.color = new Color.White
> Well if it allows you to have an object that is called red_sphere but
> is actually white then we are in deep trouble.

Heheh :-)

> Just kidding, I understand what you mean. My first reaction would be
> that pigments can be much more complicated than just a simple color.
> That is what POV makes exciting. I do not immediately see how you can
> handle that complexity in a understandable way. I will think about that
> (later).

Could do red_sphere.pigment.image_map.file and stuff too. Any level of
indirection. OO gives smarter people than I the ability to do things I'd
never dream of with it. The more flexible the code can be, the more people
will find ways to do new, interesting stuff.

Post a reply to this message

Dan P <dan### [at] yahoocom> wrote:
> new ColoredSphere
> new ColoredSphere

> new Color.White

  Aaargh! No, no and no.

  The fact that you must fill your code with the 'new' keyword in Java does
not mean it's a good thing.
  Why force the user to do that? In all those cases the 'new' keyword is
obsolete. It contributes nothing to the code.

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

Patrick Elliott <sha### [at] hotmailcom> wrote:
> I am seriously confused about what it would simplify... SDL already does 
> most everything that OO stuff can.

  It certainly does not.

  One of the basic features of an object-oriented language are modules.
  A module (in OO languages usually called a class) has a state (defined by
its attributes, ie. member variables) which can be modified with the methods
(ie. member functions) of the module. In well-designed OOP the state of the
module is private and can only be modified through the public methods (the
principle of abstraction, an extremely important principle in good
programming).
  You can create instances of modules, and modules can have other modules
or references to other modules (even of its own type) as attributes. (Among
tons of other things, it allows you to make eg. linked lists of module
instances.)

  A second basic feature of an OO language is inheritance. You can create
a new module which implements everything some other module implements
plus more (this is usually called specialization).
  Among other things, inheritance allows making more abstract, generic
functions to handle different types of modules (given that they have been
inherited from a common base class).
  Some modules may even be defined as abstract, meaning that they can't be
instantiated directly (because it wouldn't make any sense) but must be used
through inheritance.

  A third basic feature, related to inheritance, is dynamic binding. You
can declare virtual functions in a base class which the inherited classes
can implement. When a function having only a base class reference calls
this virtual function, the proper inherited function is called (even
though the caller doesn't have any knowledge about the inherited classes).

  The POV-Ray SDL does not implement anything of this.

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