Hello,

 just an idea: imagine, that POV language is object-oriented,
 so for example sphere can be defined something like:

 Sph1=sphere;
 Sph1 < rad(1) < cen(<0, 0, 0>;

 CSG:

 Union1=union < add(Sph1) < add(Sph2);

 Global settings:

 global_settings < radiosity(on) <  background (rgb .5);

 '<' means 'send messasge to object'.

 Inheritance can be great for making complex custom object,
 with they own functionality,
 for example beam object, which is able to place itself
 between some two points as abstract class and his descendants
 with particular shapes, then I can use all beams in place
 where I need beams a there is no necessity to make some
 #switches.

 Any ideas?

Regards

Disnel

Post a reply to this message

Vaclav Cermak wrote:
> 
> Hello,
> 
>  just an idea: imagine, that POV language is object-oriented,

This is probably one of the most discussed subject ever in
these groups.  I'll suggest you to take a look at the numerous
past discussions about the idea of making POV-Ray's language
more object-oriented.

Fabien.

Post a reply to this message

Fabien already answered you.
  I would like to add that although object orientedness would be wonderful
from the point of view of a hardcore programmer (like myself), it would be
of little use to the average user who knows little or nothing about
programming (who are still fighting on understanding how #while-loops and
#macros work...).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Vaclav Cermak wrote:
> 
>  just an idea: imagine, that POV language is object-oriented,
>  so for example sphere can be defined something like:

Will it render faster?

Will it parse faster?

If not, forget it.

Regards,
John

Post a reply to this message

In article <39747AD8.E2567B43@itam.cas.cz>, Vaclav Cermak 
<dis### [at] itamcascz> wrote:

>  just an idea: imagine, that POV language is object-oriented,
>  so for example sphere can be defined something like:
...
>  Any ideas?

This has been discussed many times, you might want to look at those 
discussions. There was one big one which started out in povray.general.

The biggest problem with your syntax is that it would require a complete 
redesign of the POV language, and everyone would have to re-learn it. 
This isn't necessary, object-oriented features could be added to the 
existing language, and still support old scenes and people writing in 
the older style. For one thing, the dot operator is already used to 
access the components of vectors and colors, it makes sense to use it to 
access member variables and macros. Much more sense than to use the 
"less than" operator.
A form of inheritance could be done by having every copy of an object 
get independant copies of its parent's members.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <3975A3CF.43674EB9@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> Will it render faster?

Of course not, it is part of the language.


> Will it parse faster?

Well, the complete rewrite that this particular syntax would require 
could easily lead to a much faster parser. Just don't forget about the 
fact that a rewrite is already planned. :-)


> If not, forget it.

You seem to have forgotten about ease of use. On the one side, speed is 
irrelevant if only a few people can or will use it. On the other, many 
things would be much easier/more efficient with some object-oriented 
features. It is possible to add these features without forcing everyone 
to re-learn the language.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

An idea:

Have a constructor for each object that will initialize it with the
necessary properties.

sphere ballA(<0,1,0>,1);

The object could contain other objects for texturing and have member
functions for transformations.

ballA.finish.specular = 1;
ballA.translate(<0,0,10>);

The destructor could make the object go out of scope so that other
objects could reuse the destructed object's name.

~ballA();

It looks like a total redesign.  %-\

Brendan

Post a reply to this message

On Tue, 18 Jul 2000 17:42:16 +0200, Vaclav Cermak wrote:

> just an idea: imagine, that POV language is object-oriented,
> so for example sphere can be defined something like:

[...]

> Any ideas?

The povray scene language is good, because it can be used by professionals as
well as amateurs. Object-orienting things will probably need to break
backward compatability somewhere, and only a handfull of users will actually
understand the benefits of the new OO language.

However; No one has said that you, me, anyone can't write a Pov++ language
which can be "compiled" to simple .pov files. The output pov-source will
probably look horrible, but what the heck.. :-)


 /j

Post a reply to this message

> This has been discussed many times, you might want to look at those
> discussions. There was one big one which started out in povray.general.

I readed something from this very, very long thread.
I remember some ideas from it:

1) Possibility to give a name to object and then use dot operator, like:

sphere {
  name "Sphere1"
  ...
}

....

Sphere1.texture= ....

  Persistent animations can be done with it, for example:

Sphere1.persistent=yes

  and in next frame:

Sphere1.translate(<somewhere>}

  or

Sphere1.delete()

  It has backwards compatibility, my first idea not.....


2) No one talked about virtual methods, although its big advantage, I
think.

3) XLM is good idea for sharing POV scene with modellers, converters and
   so on, but I think that is very unfortunate for hand-coding.

4) Interesting idea of breaking POV into two parts: parser and renderer,
   then can be simply parser for actual POV language, parser for XML...
   If we enlarge this concet, an XML emitor can be connected to parser
   instead of renderer, for example.

> A form of inheritance could be done by having every copy of an object 
> get independant copies of its parent's members

This is true when you don't allow changing objects after they have been 
parsed, but I think, that can be one great advantage, mainly in
persistent animations.

Regards

Disnel

Post a reply to this message

John VanSickle <van### [at] erolscom> wrote:
: Will it parse faster?

: If not, forget it.

  Oh, so then we should remove #while-loops, #macros and even #defines. They
only slow parsing, don't they?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 20 Jul 2000 05:58:42 -0400, Warp wrote:
>John VanSickle <van### [at] erolscom> wrote:
>: Will it parse faster?
>
>: If not, forget it.
>
>  Oh, so then we should remove #while-loops, #macros and even #defines. They
>only slow parsing, don't they?

We did forget #defines. :) 

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:
: We did forget #defines. :) 

  Oops... I meant #declares, of course... :)

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

>   Oops... I meant #declares, of course... :)

:-D    I find myself typing in #define too.

What about the #locals?
Brendan

>
>

Post a reply to this message

"Oh, so then we should remove #while-loops, #macros and even #defines. They
only slow parsing, don't they?"

Well said, Warp.

However, I disagree with you statment
"it would be of little use to the average user who knows little or nothing
about programming (who are still fighting on understanding how #while-loops
and #macros work...)."

If OOP was done *right* in POV, it would be at the very core of the
language. Writing "sphere{...}" would create a an *object of the class
"sphere"* Everything would be object oriented. To the one learning the
language, object oriented structure would be as fundamental as placing
lights and cameras.

    Now, when a heard that POV 4.0 would be object oriented, my reaction was
"What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
learned that they create such a raystacer WITHOUT oop! But for OOP to really
work, it must be *fully* oop.

I'm all for an object oriented POV-Ray language, as long as it is fully
object oriented.

Post a reply to this message

In article <B59F94A4.17F9%dav### [at] maccom> , David <dav### [at] maccom>
wrote:

>     Now, when a heard that POV 4.0 would be object oriented, my reaction was
> "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
> learned that they create such a raystacer WITHOUT oop! But for OOP to really
> work, it must be *fully* oop.

While today this may sound unbelievable, ten years ago when POV-Ray was
created it was absolutely state of the art to write programs in good-old C.
Even today there is nothing 'wrong' with a C program, despite the biz around
object orientation.


     Thorsten

Post a reply to this message

David <dav### [at] maccom> wrote:
: If OOP was done *right* in POV, it would be at the very core of the
: language. Writing "sphere{...}" would create a an *object of the class
: "sphere"* Everything would be object oriented. To the one learning the
: language, object oriented structure would be as fundamental as placing
: lights and cameras.

  But povray already does this.

  When you write this:

#declare MySphere = sphere { 0,1 pigment { rgb 1 } }

what you are actually doing is defining a new object (or class if you like
that name) named 'MySphere'. Now 'MySphere' can be considered a new type,
extactly like a class can be considered in C++/Java.
  Now, when you write this:

object { MySphere }

you are actually creating an instance of that object (class). You can even
modify the attributes of the object (in a quite limited way, but still you
can do it). For example:

object { MySphere translate <1,2,3> }

  And by the way, this is not yet object-oriented programming. This is
modular programming. The first modular programming languages (like Modula2)
already had classes (called "modules") with member attributes, member
functions, public and private parts, etc.
  You get an object-oriented language when you add inheritance and dynamic
binding to this. Adding these to povray would be a quite laborious job and
would probably benefit little to regular non-programmers.

:     Now, when a heard that POV 4.0 would be object oriented

  No-one has said that pov4 would be object-oriented. Yes, its _source code_
will be object-oriented (that's the point of making it in C++ after all), but
no-one has said that the povray scripting language will change that much.
  And by the way, the source code of povray IS already object-oriented.

, my reaction was
: "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
: learned that they create such a raystacer WITHOUT oop! But for OOP to really
: work, it must be *fully* oop.

  Now I'm not sure if you are talking about the source code or the povray
scripting language. As I said, the source code is OO (although made in C).
The scripting language has some OO (or more precisely modular programming)
characteristics.

: I'm all for an object oriented POV-Ray language, as long as it is fully
: object oriented.

  Well, perhaps inheritance and dynamic binding could have some uses in the
povray scripting language, but do you really think it's worth the efforts?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> No-one has said that pov4 would be object-oriented. Yes, its _source code_
> will be object-oriented (that's the point of making it in C++ after all), but
> no-one has said that the povray scripting language will change that much.
> And by the way, the source code of povray IS already object-oriented.
    Yes, what a mean is the SOURCE CODE would be object-oriented.
    Now, how can you get OOP is C?
> 
> , my reaction was
> : "What, the current POV isn't OOP?!?". My aw of the POV Team grew as a
> : learned that they create such a raystacer WITHOUT oop! But for OOP to really
> : work, it must be *fully* oop.
> 
> Now I'm not sure if you are talking about the source code or the povray
> scripting language. As I said, the source code is OO (although made in C).
> The scripting language has some OO (or more precisely modular programming)
> characteristics.
    I mean the source code.
> 
> : I'm all for an object oriented POV-Ray language, as long as it is fully
> : object oriented.
> 
> Well, perhaps inheritance and dynamic binding could have some uses in the
> povray scripting language, but do you really think it's worth the efforts?
    Yes, I think it would be, if only for the sake of TRUE OOP.
    And by fully OOP, I mean in APPLICATION, more then concept.

Post a reply to this message

In article <B5A0E746.17FD%dav### [at] maccom>, David 
<dav### [at] maccom> wrote:

>     Yes, what a mean is the SOURCE CODE would be object-oriented.
>     Now, how can you get OOP is C?

Uh, ever hear of structs?
One example is the way POV handles objects, the struct for each shape 
has a bunch of function pointers for shape-specific tasks, so it usually 
doesn't have to care about what kind of object it is.
BTW, C++ originally was translated to plain C...C is capable of 
everything C++ is, you just have to do more work to get it done.


> > Well, perhaps inheritance and dynamic binding could have some uses 
> > in the povray scripting language, but do you really think it's 
> > worth the efforts?
>     Yes, I think it would be, if only for the sake of TRUE OOP.

Well, to do something just for the sake of doing it isn't usually the 
best way to go about designing things...


>     And by fully OOP, I mean in APPLICATION, more then concept.

Well, inheritance would be like this: each copy of the object gets 
copies of the originals members, unless it is overridden. I doubt 
multiple inheritance would be that useful, but you could add a keyword 
to do so. Private, protected, and public members wouldn't be necessary 
for this, everything would be public. You would just be adding unneeded 
complexity otherwise.
And I don't think different types of binding even make sense in the POV 
language...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <3975DC6C.3C023FF2@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> 2) No one talked about virtual methods, although its big advantage, I
> think.

I don't think they would apply to POV-Script...their main use is when 
referring to objects by pointers, and POV-Script doesn't have pointers. 
I think that *all* methods would behave "virtual", separate bindings 
would be useless in POV-Script.


> This is true when you don't allow changing objects after they have been 
> parsed, but I think, that can be one great advantage, mainly in
> persistent animations.

I don't see what you mean...why would changing the object be a problem? 
If you mean adding members to an existing variable, then don't do that! 
It would be like trying to add variables and methods to a C++ class. 
Just make a new object from that one, which has the additional members 
you need.
If you mean modifying an object which has been placed in the scene, and 
isn't a variable, then (again) don't do that! Modify the object, and 
*then* put it in the scene. This will work with persistent variables 
just fine...

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

> Uh, ever hear of structs?
    Can a struct have functions as well is vars? Can a struct have protected
members? Can a struct have inheritance? Are structs encapsulated? Ect.

> Well, to do something just for the sake of doing it isn't usually the
> best way to go about designing things...

That's not what I mean. Look one level deeper. I don't want it just for the
sake of OOP. I want it for the sake of OOP for the sake of the *application*
of OOP.

Post a reply to this message

David <dav### [at] maccom> wrote:
:> Uh, ever hear of structs?
:     Can a struct have functions as well is vars? Can a struct have protected
: members? Can a struct have inheritance? Are structs encapsulated? Ect.

  The fact that the language doesn't directly support modules (and that's
what we are talking about here; you have so far mentioned no truely OO
programming feature) it doesn't mean that you can't use structures as if
they were modules.
  You can have member variables and member functions (either you just call
the proper function giving the struct as parameter, as C++ internally does,
or you put function pointers inside the struct).
  This, of course, looks ugly, but when used properly it makes little
difference compared to a truely modular language (like C++).

  And I would like to emphasize that you keep talking about object-oriented
programming, and still you haven't mentioned ANY feature of object-oriented
languages (inheritance, dynamic binding, overloading...). You just keep
talking about modules.
  For your information, the povray source code even uses some kind of
inheritance (and even dynamic binding, I think), which makes it very OO-like.
It looks ugly in C, but it does it.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David <dav### [at] maccom> wrote:
:     Now, how can you get OOP is C?

  I know several programs that use OOP in C. The most obvious one is povray.
To mention another one, the GTK library uses OOP as well.
  They both use modules, inheritance and dynamic binding. It looks quite
ugly in C, but they use them.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <B5A11995.1927%dav### [at] maccom> , David <dav### [at] maccom>
wrote:

>    Can a struct have functions as well is vars? Can a struct have protected
> members? Can a struct have inheritance? Are structs encapsulated? Ect.

You can have all of it, also it obviously won't look the same.  Take a look
at the operating system you are running (Mac OS, I presume).  In particular,
look at the Window Manager. There is (in reverse order for better reading):

struct WindowRecord {
 GrafPort       port;
 short        windowKind;
 Boolean       visible;
 ...
};

struct GrafPort {
 short        device;
 BitMap        portBits;
 Rect        portRect;
 ...
};

struct BitMap {
 Ptr        baseAddr;
 short        rowBytes;
 Rect        bounds;
};


Now, as C++ classes this could look like:

class WindowRecord {
private:
 GrafPort       port;
 short        windowKind;
 Boolean       visible;
 ...
};

class GrafPort {
private:
 short        device;
 BitMap        portBits;
 Rect        portRect;
 ...
};

class BitMap {
private:
 Ptr        baseAddr;
 short        rowBytes;
 Rect        bounds;
};

typedef WindowRecord *      WindowPtr;


Instead of having functions in here, this example shows that you do _not_
even need function pointers (also C++ does it this way) to get OOP.  All you
need is a well defined interface, and every call then just does this:

WindowPtr win = NewWindow(...);

SetWindowTitle(win, "My Title");

DisposeWindow(win);


While in C++ this would look like:

Window *win = new Window(...);

win->SetTitle("My title");

delete win;


If you want private data members, and as a good OOP principle is to disallow
access to all direct data members anyway, and to use accessor functions you
would get:

// in the "public" header, you do this
typedef struct OpaqueWindowPtr *      WindowRef;
// while in the private header you would do this
typedef WindowRecord *      WindowPtr;
// this allows you to have both working, it is just a matter of a few simple
// "tricks" in C


WindowRef win = NewWindow(...);

SetWindowTitle(win, "My Title");

DisposeWindow(win);


Now, all you functions need to do is to cast the win pointer they receive to
WindowPtr and they can use it as they did before.  By not exporting function
prototypes of functions, you make these functions "private".  In C you could
always do so by declaring a function "static".

As you can see, most OOP support is "included" in C, and additionally, the
code above was (like the original Mac OS) done in Pascal!  And the above
code is actual code, the first part as it has been until now, and the later
(windowRef) as it is when using the Carbon APIs.

The difference and reason for C++ to exists is to make these "features" of C
more accessible and integrated into the language, which allows greater
flexibility and speed.  Of course there are templates and multiple
inheritance in C++, but with the simple C preprocessors directives, even
templates are possible.  The only thing really missing is operator
overloading...

Anyway, this discussion has little to do with OOP, more with the
implementation of support for OOP in various languages - in some (like Java)
OOP is nearly enforced, while others like C leave it to the programmer to
write in good OOP style.   BTW, the Java Virtual Machine is not written in
C++, but C...


      Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: but with the simple C preprocessors directives, even
: templates are possible.

  Are you sure? How do you make this extremely simple template in C:

template<typename T>
void swap(T& x, T& y)
{
  T tmp = x;
  x = y;
  y = tmp;
}

  Yes, you can make that code in a #define macro, but the problem is where
are you going to the the type for 'tmp'?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 24 Jul 2000 10:22:27 -0400, Warp wrote:
>  Yes, you can make that code in a #define macro, but the problem is where
>are you going to the the type for 'tmp'?

Make it one of the parameters to the macro?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On 24 Jul 2000 10:37:25 -0400, Ron Parker wrote:
>On 24 Jul 2000 10:22:27 -0400, Warp wrote:
>>  Yes, you can make that code in a #define macro, but the problem is where
>>are you going to the the type for 'tmp'?
>
>Make it one of the parameters to the macro?

Better yet (untested):

#define SWAP(a,b) {                \
  char tmp[sizeof(a)];             \
  assert( sizeof(a) == sizeof(b)); \
  memcpy( tmp, &a, sizeof(a));     \
  memcpy( &a, &b, sizeof(a));      \
  memcpy( &b, tmp, sizeof(a));     \
  }

This does assume that your dialect of C allows you to declare variables
at the start of any block rather than just at the top of the function, 
but I don't see any way of doing it without stipulating that.  It looks
like tmp has a dynamic size, but since sizeof is a compile-time operator,
it really doesn't.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

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

>  Are you sure? How do you make this extremely simple template in C:
>
> template<typename T>
> void swap(T& x, T& y)
> {
>   T tmp = x;
>   x = y;
>   y = tmp;
> }

I would do it with include files that are not protected from
multiple-inclusion.  It could look like this:

FILE: mytmpl.h

void TEMPLATE_swap(T& x, T& y);

void TEMPLATE_swap(TEMPLATE_T& x, TEMPLATE_T& y)
// OK, there are no references in C...
{
  TEMPLATE_T tmp = x;
  x = y;
  y = tmp;
}


FILE: mymain.c

#define T int
#define TEMPLATE_swap swap1
#include "mytmpl.h"
#undef TEMPLATE_swap
#undef T

#define T char *
#define TEMPLATE_swap swap2
#include "mytmpl.h"
#undef TEMPLATE_swap
#undef T


While this is more work than just two functions, it does exactly the same.

However, if you have complex "classes" (structs) you only have to create a
new class name but can reuse the code without having to rename each
function.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Ok, let's take this a step further:

template<typename T1, typename T2>
void swap(T1& x, T2& y)
{
    T1 tmp = x;
    x = y;
    y = tmp;
}

  And suppose we have:

class B;

class A
{
 public:
    A& operator=(const B&);
}

class B
{
 public:
    B& operator=(const A&);
}

int main()
{
    A a;
    B b;
    swap(a,b);
}

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

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

>   Ok, let's take this a step further:

OK, keep in mind that I pointed out before "The only thing really missing is
operator overloading...".  So a trick is needed to replace your overloaded
operator.  Of course this trick won't work with built-in types and two
versions of your template will be needed, one for classes and one for
built-in types!


FILE: mytmpl.h

void TEMPLATE_swap(T1& x, T2& y);

void TEMPLATE_swap(TEMPLATE_T1& x, TEMPLATE_T2& y)
// OK, there are no references in C...
{
  TEMPLATE_T1 tmp = x; // may need "copy" constructor replacement here

  x.assignment(&x, y);
  y.assignment(&y, tmp);
}


FILE: mymain.c

// First, every "class" gets "assignment" member functions:

struct A
{
    void (*assignment)(A *this, B& b);
};

struct B
{
    void (*assignment)(B *this, A& a);
};


#define T1 A
#define T2 B
#define TEMPLATE_swap swap_AB
#include "mytmpl.h"
#undef T1
#undef T2

int main(void)
{
    A a;
    B b;

    swap_AB(a,b);

    return 0;
}



____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: #define T1 A
: #define T2 B
: #define TEMPLATE_swap swap_AB
: #include "mytmpl.h"
: #undef T1
: #undef T2

  What is shorter, to write the 6 lines of code above for every pair of
structs you use, or just write the swap function directly?

  Perhaps in this case it could be better to have a 'swap' method inside
the classes/structs, so you could write:

  a.swap(b);

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

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

>   What is shorter, to write the 6 lines of code above for every pair of
> structs you use, or just write the swap function directly?
>
>   Perhaps in this case it could be better to have a 'swap' method inside
> the classes/structs, so you could write:
>
>   a.swap(b);

For the swap function this is to long, yes, but what about classes similar
to ones link vector<>, list<> or map<> templates in C++?  While in many
cases good old void pointers will do, it is possible to use macros instead.

Anyway, my point was not that templates are easy and good to do in C, just
that it is possible with a little bit of work to get a lot of features of
C++ in C - and the three lines would be exactly what it would takes to
implement a vector<> template of any class in C.


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Chris Huff wrote:
> 
> In article <3975DC6C.3C023FF2@itam.cas.cz>, Disnel <dis### [at] itamcascz>
> wrote:
> 
> > 2) No one talked about virtual methods, although its big advantage, I
> > think.
> 
> I don't think they would apply to POV-Script...their main use is when
> referring to objects by pointers, and POV-Script doesn't have pointers.
> I think that *all* methods would behave "virtual", separate bindings
> would be useless in POV-Script.

But what are POV #declares? They can be taken as references, I think.
You are right with virtual methods, all would behave "virtual"

> 
> > This is true when you don't allow changing objects after they have been
> > parsed, but I think, that can be one great advantage, mainly in
> > persistent animations.
> 
> I don't see what you mean...why would changing the object be a problem?

For example I have two spheres and my new object, which connects
these two spheres with cylinder. When one sphere was changed during
animation, my connecting object need to be notified about it.
Where it contains only copies of sphere, it knows nothing about
change.

> If you mean adding members to an existing variable, then don't do that!
> It would be like trying to add variables and methods to a C++ class.
> Just make a new object from that one, which has the additional members
> you need.

I don't mean anything else.

> If you mean modifying an object which has been placed in the scene, and
> isn't a variable, then (again) don't do that! Modify the object, and
> *then* put it in the scene. This will work with persistent variables
> just fine...

Here we don't understand: you are thinking about object oriented
preprocesor and I'am thinking about object oriented scene during
rendering and animation, I'am right?

> 
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

Post a reply to this message

In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> But what are POV #declares? They can be taken as references, I think.

I suppose they could be considered references...
You could create basic "types" by making certain base objects to 
inherit/copy from, just like you do in some of the include 
files(shapes.inc, for example). Members would be copied as well. In 
other words, objects inherit from objects, not from object types.
My idea doesn't separate types of objects and actual objects, like C++, 
but it should work, and might be much easier for people to learn. 
Besides, I don't see any simpler way of adding OOP to POV-Script.


> You are right with virtual methods, all would behave "virtual"

I don't see how they couldn't, since POV is interpreted all in one pass, 
and doesn't have separate compile-link-run stages. That, and the way 
it's "types" are done...


> For example I have two spheres and my new object, which connects
> these two spheres with cylinder. When one sphere was changed during
> animation, my connecting object need to be notified about it.
> Where it contains only copies of sphere, it knows nothing about
> change.

I still don't see the problem...have one sphere be changed with a member 
macro, which calls member macros of the other sphere and the linking 
cylinder. When one changes, the other two will be updated automatically. 
The main sphere is updated every frame of the animation, and all three 
are stored in persistent variables, say Sphere1, Cylinder, and Sphere2. 
After processing is done, copies of them are placed in the scene, like 
this:
Sphere1.Update(clock);

object {Sphere1}
object {Cylinder}
object {Sphere2}



> > If you mean adding members to an existing variable, then don't do that!
> > It would be like trying to add variables and methods to a C++ class.
> > Just make a new object from that one, which has the additional members
> > you need.
> 
> I don't mean anything else.

Just make a new variable/class with the new members, and using the same 
name as the parent object...like this:
#declare Foo = object {...}
#declare Foo = object {Foo ...new members...}
Where is the problem? You don't need to be able to add variables or 
functionality to an existing object, just create a new one derived from 
the original. What do you think inheritance is for?


> Here we don't understand: you are thinking about object oriented
> preprocesor and I'am thinking about object oriented scene during
> rendering and animation, I'am right?

No processing of the scene file is done during rendering...the scene 
*has* to remain static during that stage, and it wouldn't make sense 
otherwise. It makes sense to only modify objects which you have in 
dynamic form, as a variable. As for animation, the scene is reprocessed 
before every frame. You can keep variables from one frame to the next, 
what is wrong with modifying those and rebuilding the scene each frame?

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itamcascz>
> wrote:
> 
> > But what are POV #declares? They can be taken as references, I think.
> 
> I suppose they could be considered references...
> You could create basic "types" by making certain base objects to
> inherit/copy from, just like you do in some of the include
> files(shapes.inc, for example). Members would be copied as well. In
> other words, objects inherit from objects, not from object types.
> My idea doesn't separate types of objects and actual objects, like C++,
> but it should work, and might be much easier for people to learn.
> Besides, I don't see any simpler way of adding OOP to POV-Script.

I also think, that C++ style with class declaration and using
new after is inappropriate for POV language. Better will be
true OO style: each object can contain each object, messages
sent to object are also objects and result of message sent to object is
also object.

> 
> > You are right with virtual methods, all would behave "virtual"
> 
> I don't see how they couldn't, since POV is interpreted all in one pass,
> and doesn't have separate compile-link-run stages. That, and the way
> it's "types" are done...

Sure, they can.

> 
> > For example I have two spheres and my new object, which connects
> > these two spheres with cylinder. When one sphere was changed during
> > animation, my connecting object need to be notified about it.
> > Where it contains only copies of sphere, it knows nothing about
> > change.
> 
> I still don't see the problem...have one sphere be changed with a member
> macro, which calls member macros of the other sphere and the linking
> cylinder. When one changes, the other two will be updated automatically.
> The main sphere is updated every frame of the animation, and all three
> are stored in persistent variables, say Sphere1, Cylinder, and Sphere2.
> After processing is done, copies of them are placed in the scene, like
> this:
> Sphere1.Update(clock);
> 
> object {Sphere1}
> object {Cylinder}
> object {Sphere2}

Yes, it will work, but it will waste memory and CPU time,
its no problem with sphere but if you want make descendant from 50MB
tree, it will be very unfortunate.
Second, it will be unnecessary compilcated to use.

> 
> > > If you mean adding members to an existing variable, then don't do that!
> > > It would be like trying to add variables and methods to a C++ class.
> > > Just make a new object from that one, which has the additional members
> > > you need.
> >
> > I don't mean anything else.
> 
> Just make a new variable/class with the new members, and using the same
> name as the parent object...like this:
> #declare Foo = object {...}
> #declare Foo = object {Foo ...new members...}
> Where is the problem? You don't need to be able to add variables or
> functionality to an existing object, just create a new one derived from
> the original. What do you think inheritance is for?

Maybe.

> 
> > Here we don't understand: you are thinking about object oriented
> > preprocesor and I'am thinking about object oriented scene during
> > rendering and animation, I'am right?
> 
> No processing of the scene file is done during rendering...the scene
> *has* to remain static during that stage, and it wouldn't make sense
> otherwise. It makes sense to only modify objects which you have in
> dynamic form, as a variable. As for animation, the scene is reprocessed
> before every frame. You can keep variables from one frame to the next,
> what is wrong with modifying those and rebuilding the scene each frame?

Sure, scene should remain static during rendering, you are right ;-).
But rebuilding whole scene for each frame is once more wasting
of CPU time, is some cases, chance to use objects from previsous
scene with only slight modifications can improve rendering time.
For example smoothing height field, tree generation .... It can be
done once for whole animation.

> 
> --
> Christopher James Huff - Personal e-mail: chr### [at] maccom
> TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
> Personal Web page: http://homepage.mac.com/chrishuff/
> TAG Web page: http://tag.povray.org/

Post a reply to this message

Disnel <dis### [at] itamcascz> wrote:
: I also think, that C++ style with class declaration and using
: new after is inappropriate for POV language.

  Firstly, you have to define somehow what the object looks like. A class
is as good as any other method of doing it. I don't see the problem.
  Secondly, you don't need to use 'new'. I seldom use it although I code
a lot in C++.

: Better will be
: true OO style: each object can contain each object, messages
: sent to object are also objects and result of message sent to object is
: also object.

  It seems to be that a variable or table or structure allocated in the
memory (and some 'handle' to get it) becomes an 'object' after you just
say "this is an object". As long as you don't say it, it's not an object,
but something else.
  Of course everything can be considered an object. What else could it be?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

In article <39815686.AA9BAAB5@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> Better will be true OO style: each object can contain each object, 
> messages sent to object are also objects and result of message sent 
> to object is also object.

This could be done...just pass the message object as a parameter to a 
member macro.


> Sure, they can.

That is what I meant: they can't not be like this. It wouldn't make 
sense for them to be any other way.


> Yes, it will work, but it will waste memory and CPU time,
> its no problem with sphere but if you want make descendant from 50MB
> tree, it will be very unfortunate.
> Second, it will be unnecessary compilcated to use.
...snip...
> But rebuilding whole scene for each frame is once more wasting
> of CPU time, is some cases, chance to use objects from previsous
> scene with only slight modifications can improve rendering time.
> For example smoothing height field, tree generation .... It can be
> done once for whole animation.

First, I don't think it would be any slower and not much more memory 
intensive. Some data could be shared, and only duplicated when 
absolutely necessary.
And it wouldn't be more complicated...you have to add those objects to 
the scene in the first place, being able to modify objects which are 
already in the scene could easily get more complex than modifying 
variables, and it might not be as efficient in memory usage.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Declaration of object structure you need when objects has types,
I'am thinking about untyped language.

Warp wrote:
> 
> Disnel <dis### [at] itamcascz> wrote:
> : I also think, that C++ style with class declaration and using
> : new after is inappropriate for POV language.
> 
>   Firstly, you have to define somehow what the object looks like. A class
> is as good as any other method of doing it. I don't see the problem.
>   Secondly, you don't need to use 'new'. I seldom use it although I code
> a lot in C++.
> 
> : Better will be
> : true OO style: each object can contain each object, messages
> : sent to object are also objects and result of message sent to object is
> : also object.
> 
>   It seems to be that a variable or table or structure allocated in the
> memory (and some 'handle' to get it) becomes an 'object' after you just
> say "this is an object". As long as you don't say it, it's not an object,
> but something else.
>   Of course everything can be considered an object. What else could it be?
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

> This could be done...just pass the message object as a parameter to a
> member macro.

Sure, its one implementation. But not neccessary the one possible.

> 
> > Sure, they can.
> 
> That is what I meant: they can't not be like this. It wouldn't make
> sense for them to be any other way.
> 

OK. You are right.

> First, I don't think it would be any slower and not much more memory
> intensive. Some data could be shared, and only duplicated when
> absolutely necessary.

But its not a "copy" of object, then.

> And it wouldn't be more complicated...you have to add those objects to
> the scene in the first place, being able to modify objects which are
> already in the scene could easily get more complex than modifying
> variables, and it might not be as efficient in memory usage.

How you mean "add in the first place"?

If some object will support it (heightfield is able to change its small
part, for example) it will be very usable. All objects should support
basic things, such as transformation matrix change, texture change....


Disnel

Post a reply to this message

In article <398ACFB9.BBCFCC2B@itam.cas.cz>, Disnel <dis### [at] itamcascz> 
wrote:

> Sure, its one implementation. But not neccessary the one possible.

It seems to be the easiest and simplest way to do it, with minimal 
disturbance to the existing language.


> But its not a "copy" of object, then.

Sure it is. Just because shared data isn't duplicated doesn't mean it is 
a different object. For example, you can have many "copies" of a mesh 
which share the same mesh data, possibly saving megabytes of memory. 
Textures also can share data, and I think the same goes for height 
fields.


> How you mean "add in the first place"?

The object was placed in the scene before, there is no other way for it 
to get there. :-)
Since you obviously have code to put it in the scene, just don't add 
extra code to not put in the scene for later frames.
If persistant objects are used, you have to check to see if the object 
already exists, and if it does, than don't add it to the scene again, or 
you will just waste memory and render time. If only persistent variables 
are used, you don't have to do this. You don't have to have special 
handling for placing an object in the scene, or any special code for 
modifying it.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message

> It seems to be the easiest and simplest way to do it, with minimal
> disturbance to the existing language.

OK.

> 
> > But its not a "copy" of object, then.
> 
> Sure it is. Just because shared data isn't duplicated doesn't mean it is
> a different object. For example, you can have many "copies" of a mesh
> which share the same mesh data, possibly saving megabytes of memory.
> Textures also can share data, and I think the same goes for height
> fields.

OK. I meaned "copy" as physical copy, not only shared data.
If you will use shared data, all is OK.

> 
> > How you mean "add in the first place"?
> 
> The object was placed in the scene before, there is no other way for it
> to get there. :-)
> Since you obviously have code to put it in the scene, just don't add
> extra code to not put in the scene for later frames.
> If persistant objects are used, you have to check to see if the object
> already exists, and if it does, than don't add it to the scene again, or
> you will just waste memory and render time. If only persistent variables
> are used, you don't have to do this. You don't have to have special
> handling for placing an object in the scene, or any special code for
> modifying it.

But when I need to scale height field in y direction during
animation, for example, I need to modify it for each frame.
But rebuilding whole HF for each frame is not neccessary
(OK, I don't know if POV does some precomputation for HF
which should need rebuild of HF structure when changing
its scale, but its only for example).

Best regards

Disnel

Post a reply to this message

Ok, this is a favourite subject of mine, and also a (I hope) subject for
my Masters thesis, so I really can't keep myself from posting :)

As a POV user for almost 5 years now (and part-time comp. sci. student
<g>), I got the same idea during the development of my smoke effect
include file. I realized that very little information on the objects in
the scene is available from within POV, one example was that you
couldn't extract the current frame number during parsing and thus not
know if the current frame was the first frame - which is required since
the include uses file I/O. These kind of problems become obvious when
you write include files that needs to know certain things - they maybe
even have to alter existing objects (if that's what they're supposed to
to).

Areas where OO syntax would be useful is...well, everywhere...but let's
look at some examples. Let's say you want to make an include file that
takes care of physics modelling. Let's say you want it to make all
objects in the scene have real world gravity. You have no idea what
objects the user has in his/her scene, but you want all objects to
behave in a real world manner. Let's say there was a global array
variable called scene.objects[], and an integer value property
(scene.objects.count) of that array that held the number of objects in
the array. Then, this code could take care of the whole thing:

#declare i=0;
#while(i<scene.objects.count)
  scene.objects[i].translate(<0, -9.82*pow(clock,2) ,0>)  //well, sort
of...
  #declare i=i+1;
#end

This is just one example. You could access all objects and their
properties, as well as changing them if you wanted to. Let's say you
wanted to make a spotlight follow your camera, without having to
#declare two vector variables (not a big deal, but, anyway..). The
camera currently in use is of course accessible by scene.camera, or even
just camera, and since it (as all other POV objects) has a .location and
a .rotation attribute as well as it's own special attributes (.look_at
being one of them) you can easily describe this spotlight:

#declare MySpot=light_source{
  camera.location+<0,0.5,0>                //sets MySpot.location =
camera.location+<0,0.5,0>
  spotlight                                           //sets MySpot.type
= spotlight
   ..
  point_at camera.look_at                   //sets MySpot.point_at =
camera.look_at
}

Of course, you can now both read and write the attributes of your
object, which means you can check if MySpot.point_at equals
camera.look_at, you can change the radius of it (as well as all other
spotlights) in a loop:

#declare i=0;
#while(i<scene.objects.count)
  #if (scene.objects[i].type=spotlight)
    scene.objects[i].radius=20;
  #end
 #declare i=i+1;
#end

..as well as all other type of operations you could come up with.
Everything is now accessible, the only thing setting the limits is your
imagination.

Since there now is references and inheritance, you can now easily create
a "linked list"-type object:

#declare worm_part1=sphere{
 0, 0.5
 pigment{color rgb 1}
 ref{next}  // tells POV that this object has a reference, called "next"

}

// instead of copying the above code, let's create another object that
inherits from worm_part1:
#declare worm_part2=like worm_part1{     // IDENTIFIER = like ANCESTOR
 pigment{color rgb 0}  // leaves everything like worm_part1, except the
pigment.
}

// references can also be declared to "point" to a certain objects from
the start:
#declare worm_head=sphere{
 0, 0.5
 texture{some_texture}
 ref{next, worm_part1} // REFNAME [,OBJECT]
}

// Changing the reference of worm_part1:
#declare worm_part1.next=worm_part2;

// Let's create an explicit reference:
#declare temp_ref=ref{worm_head};

// All references are nil:ed from start (if no reference object is
given), so we now can do this:
#while(temp_ref<>nil)
 #declare temp_ref.location = temp_ref.location + <1,0,0>;
 #declare temp_ref=temp_ref.next;
#end

And of course, the new OO-POV is fully backwards compatible with the
non-OO language...so noone has to throw away their old scenes. Or learn
a new language - if you don't want to use the new features, of course.

Someone asked: "will it render/parse faster?". Answer: No - the language
itself does not affect render/parsing time. A complete C++ rewrite maybe
will, as it will allow for more efficient memory handling, but that does
not have to include a new syntax.

So...these are just some ideas, that still are very much on the
"ideas"-stage. I would really enjoy to do this as part of my masters
thesis research, the only problem is what scientific approach I should
have. (Possibly: creating a new method for developing an OO-language)
All ideas are welcome...


----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse

Post a reply to this message

Has anyone ever thought of using a straight C++ interface for POV?
It seems the language is slowly growing that way anyway but its all getting
a bit messy with more and more switches etc.
My thought is that you could define a set of standard C++ objects
corresponding to the objects POV understands. Each has a set of operations
such as object.rotate(x,y,z) and object.interior.ior(1.5)... At some point
in the code there's a call to "object.store" to download the resulting
primitives in some form the renderer understands.
Compile this in a shareware compiler and run it, then a separate renderer
can then act on the primitives generated.
Is this all too geeky?

My first posting - be gentle
Matt Webster

Post a reply to this message

In article <39f89df8@news.povray.org>, "Matthew Webster" 
<mat### [at] nospamvirginnet> wrote:

> Has anyone ever thought of using a straight C++ interface for POV?

I think a language designed for scene description would be a better 
idea. Something similar in basic syntax to C/C++/ObjC/Java, but 
simplified and modified to make scene description part of the language. 
My "CSDL" project is an example of what I am talking about...(CSDL == 
C-like Scene Description Language)


> It seems the language is slowly growing that way anyway but its all 
> getting a bit messy with more and more switches etc.

Um, it doesn't seem very C++-like to me...and what do you mean by 
switches? I don't use the #switch command very often at all...and I 
don't see what it has to do with making POV-Script more object-oriented 
or using C++.


> My thought is that you could define a set of standard C++ objects 
> corresponding to the objects POV understands. Each has a set of 
> operations such as object.rotate(x,y,z) and 
> object.interior.ior(1.5)... At some point in the code there's a call 
> to "object.store" to download the resulting primitives in some form 
> the renderer understands.
> Compile this in a shareware compiler and run it, then a separate renderer
> can then act on the primitives generated.
> Is this all too geeky?

A few things that make it a bad idea to use C++ as the POV language: 
1: Ease of use. Everyone would have to forget POV-Script and learn C++. 
Some people simply don't like C++, others don't have time, talent, or 
will to learn and use it. And even once you learn it and use it, it just 
isn't the best tool for doing many scenes.
2: Everyone would need a C++ compiler. Unless the POV-Team writes one 
for each platform and includes it with POV, they will have to go find 
some free or shareware one, figure out how to install and use it with 
what documentation they can find, and cope with differences between 
compilers.
3: Platform/development environment differences. POV always runs 
POV-Script the same way, compilers(especially free/cheap ones) often 
have odd little "issues". And then there are differences in the 
libraries...again, unless the POV-Team writes one for each platform and 
includes it with POV, these will be big problems.
4: Security. Using C++ means a POV-Script would be able to do 
*anything*. For some applications this is simply unacceptable.

However, a "POV-Library" that can emit POV-Script code would still be 
very useful for other things: utilities, complex simulations or 
calculations, etc. It just wouldn't be a good idea to use C++ as the 
main scene description language.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Matthew Webster <mat### [at] nospamvirginnet> wrote:
: Has anyone ever thought of using a straight C++ interface for POV?

  Yes. Someone has made this kind of library for C++ (I think it supported
POV 3.0 syntax when reading from a pov-file).

: such as object.rotate(x,y,z) and object.interior.ior(1.5)...

  Ugh!
  Make that: object.interior().ior(1.5); (although it may be done even better).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

It can be done when POV will be divided into two parts:
raytracer itself and parser modules. Raytracer should then
have some interface, which will be some shared library, you 
can use this library in your programs then (technically,
license is another point of discussion).

Disnel

Matthew Webster wrote:
> 
> Has anyone ever thought of using a straight C++ interface for POV?
> It seems the language is slowly growing that way anyway but its all getting
> a bit messy with more and more switches etc.
> My thought is that you could define a set of standard C++ objects
> corresponding to the objects POV understands. Each has a set of operations
> such as object.rotate(x,y,z) and object.interior.ior(1.5)... At some point
> in the code there's a call to "object.store" to download the resulting
> primitives in some form the renderer understands.
> Compile this in a shareware compiler and run it, then a separate renderer
> can then act on the primitives generated.
> Is this all too geeky?
> 
> My first posting - be gentle
> Matt Webster

Post a reply to this message

> > Has anyone ever thought of using a straight C++ interface for POV?

	Yes, and apart from being forbidden by the POV license,
	there is a great deal invested here by people in their
	POV script.

> However, a "POV-Library" that can emit POV-Script code would still be
> very useful for other things: utilities, complex simulations or
> calculations, etc. It just wouldn't be a good idea to use C++ as the
> main scene description language.

	Yes indeed, and it could form a component of POV 4.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <3A03B95C.D5C34F86@nigels.com>, nig### [at] nigelscom wrote:

> > However, a "POV-Library" that can emit POV-Script code would still be
> > very useful for other things: utilities, complex simulations or
> > calculations, etc. It just wouldn't be a good idea to use C++ as the
> > main scene description language.
> 
> 	Yes indeed, and it could form a component of POV 4.

How? What I am talking about is a framework for manipulating objects in 
C++ and outputing .pov files...nothing to do with POV-Ray itself. There 
is no reason it couldn't be done now and used with POV-Ray 3.1...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> >       Yes indeed, and it could form a component of POV 4.
> 
> How? What I am talking about is a framework for manipulating objects in
> C++ and outputing .pov files...nothing to do with POV-Ray itself. There
> is no reason it couldn't be done now and used with POV-Ray 3.1...

	Of course it would be useful for 3.1, but by the time you've
	done all the POV glue in C++, you're left with two things:
	The parser, and the raytracing code.  And really, it's
	only the parser (and control of it) that differentiates
	POV.

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message

In article <3A077C3D.C5606AE0@nigels.com>, nig### [at] nigelscom wrote:

> 	Of course it would be useful for 3.1, but by the time you've
> 	done all the POV glue in C++, you're left with two things:
> 	The parser, and the raytracing code. 

Oh, you are talking about releasing the parser code separately from the 
POV core? I was talking about a library for creating .pov files, not 
reading them. I plan on starting such a project, someday...


> And really, it's only the parser (and control of it) that 
> differentiates POV.

A lot of people (including me) would disagree with you...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

> A lot of people (including me) would disagree with you...

Only you, apparently.  :-)

--
Nigel Stewart (nig### [at] nigelscom)
Research Student, Software Developer
Y2K is the new millenium for the mathematically challenged.

Post a reply to this message