Hello

Does anyone of you can send me or does know a link to a documentation to the
FRAME structure?

Thank you for any help

Henryk

Post a reply to this message

In article <397ffc99$1@news.povray.org> , "Henryk Mueller" 
<hen### [at] gmxde> wrote:

> Does anyone of you can send me or does know a link to a documentation to the
> FRAME structure?

There is no documentation of the POV-Ray source code except the comments in
it.  It is part of the fun with the POV-Ray source code to play with it and
find out how it works.


     Thorsten


____________________________________________________
Thorsten Froehlich
e-mail: mac### [at] povrayorg

I am a member of the POV-Ray Team.
Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

> There is no documentation of the POV-Ray source code except the comments
in
> it.  It is part of the fun with the POV-Ray source code to play with it
and
> find out how it works.

Hey, I can imagine things that make more fun that exploring source code! ;-)

Btw, do you or anybody else know the source file where FRAME is defined.
There are way to many files and I hate those extern declarations...

Henryk

Post a reply to this message

On Thu, 27 Jul 2000 15:37:05 +0200, Henryk Mueller wrote:
>> There is no documentation of the POV-Ray source code except the comments
>in
>> it.  It is part of the fun with the POV-Ray source code to play with it
>and
>> find out how it works.
>
>Hey, I can imagine things that make more fun that exploring source code! ;-)
>
>Btw, do you or anybody else know the source file where FRAME is defined.
>There are way to many files and I hate those extern declarations...

Yes.

Oh, you want us to tell you.  Well then.  It's a typedef in povray.h.

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

Post a reply to this message

What is FRAME?

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

>   What is FRAME?

typedef struct Frame_Struct FRAME;

struct Frame_Struct
{
  CAMERA *Camera;
  int Screen_Height, Screen_Width; /* OPTIONS */
  int Number_Of_Light_Sources;
  LIGHT_SOURCE *Light_Sources;
  OBJECT *Objects;
  DBL Atmosphere_IOR, Atmosphere_Dispersion, Antialias_Threshold;
  COLOUR Background_Colour;
  COLOUR Ambient_Light;
  COLOUR Irid_Wavelengths;
  IMEDIA *Atmosphere;
  FOG *Fog;
  RAINBOW *Rainbow;
  SKYSPHERE *Skysphere;
};



____________________________________________________
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

In article <398039fd@news.povray.org> , "Henryk Mueller" 
<hen### [at] gmxde> wrote:

> Btw, do you or anybody else know the source file where FRAME is defined.
> There are way to many files and I hate those extern declarations...

Yes, this is a typical problem of large programs.  Depending on the
operating system you are using, either 'grep' or an IDE/text editor with a
multi-file search function will be very useful.


      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 wrote:

> In article <398039fd@news.povray.org> , "Henryk Mueller"
> <hen### [at] gmxde> wrote:
>
> > Btw, do you or anybody else know the source file where FRAME is defined.
> > There are way to many files and I hate those extern declarations...
>
> Yes, this is a typical problem of large programs.  Depending on the
> operating system you are using, either 'grep' or an IDE/text editor with a
> multi-file search function will be very useful.

Do any other IDEs have the equivalent of MSVC's Source Browser & ClassWizard
functions.

--
Bye
Pabs

Post a reply to this message

For which operating system?  I can suggest several decent ones for
linux.

Pabs wrote:
> 
> Thorsten Froehlich wrote:
> 
> > In article <398039fd@news.povray.org> , "Henryk Mueller"
> > <hen### [at] gmxde> wrote:
> >
> > > Btw, do you or anybody else know the source file where FRAME is defined.
> > > There are way to many files and I hate those extern declarations...
> >
> > Yes, this is a typical problem of large programs.  Depending on the
> > operating system you are using, either 'grep' or an IDE/text editor with a
> > multi-file search function will be very useful.
> 
> Do any other IDEs have the equivalent of MSVC's Source Browser & ClassWizard
> functions.
> 
> --
> Bye
> Pabs

Post a reply to this message

Ken Cecka wrote:

> For which operating system?  I can suggest several decent ones for
> linux.
> > Do any other IDEs have the equivalent of MSVC's Source Browser & ClassWizard
> functions.

I was just asking if these kind of things are implemented for other IDEs (they are
incredibly useful)
I only have access to M$ Windoze machines at the moment.
Bye
Pabs

Post a reply to this message

In article <3980ECAB.761DB51F@hotmail.com>, Pabs <pab### [at] hotmailcom> 
wrote:

> Do any other IDEs have the equivalent of MSVC's Source Browser & 
> ClassWizard functions.

It would help if you described what those features *are*.
MetroWerks CodeWarrior has a class browser which allows you to 
graphically browse the class heirarchy and look at class members, and 
has a nifty feature which allows you to find definitions/implementations 
of #defines, structs, classes, and functions by simply highlighting a 
word in the source code and popping up a contextual menu. There are 
probably several other features of this sort in CodeWarrior, but I 
haven't used them much.

-- 
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 <3980ECAB.761DB51F@hotmail.com>, Pabs <pab### [at] hotmailcom>
> wrote:
>
> > Do any other IDEs have the equivalent of MSVC's Source Browser &
> > ClassWizard functions.
>
> It would help if you described what those features *are*.

Source browser is like this.
When you compile a project M$VC saves all definitions & references of all
symbols to a browse file.  You can then bring up a list of these and for
functions call & callers lists & for classes & structs members lists & (I
think) inheritance lists.

> MetroWerks CodeWarrior has a class browser which allows you to
> graphically browse the class heirarchy and look at class members, and
> has a nifty feature which allows you to find definitions/implementations
> of #defines, structs, classes, and functions by simply highlighting a
> word in the source code and popping up a contextual menu. There are
> probably several other features of this sort in CodeWarrior, but I
> haven't used them much.

Classwizard is similar to what you describe & to Source browser but it is
more dynamic in that you don't need to recompile to find variables, structs
etc.

Both are a little deficient when it comes to defines & typedefs

--
Bye
Pabs

Post a reply to this message

Pabs wrote:

> Both are a little deficient when it comes to defines & typedefs

So is the autocomplete function.

--
Bye
Pabs

Post a reply to this message

Thorsten Froehlich wrote:

> typedef struct Frame_Struct FRAME;
>
> struct Frame_Struct
> {
>   CAMERA *Camera;
>   int Screen_Height, Screen_Width; /* OPTIONS */
>   int Number_Of_Light_Sources;
>   LIGHT_SOURCE *Light_Sources;
>   OBJECT *Objects;
>   DBL Atmosphere_IOR, Atmosphere_Dispersion, Antialias_Threshold;
>   COLOUR Background_Colour;
>   COLOUR Ambient_Light;
>   COLOUR Irid_Wavelengths;
>   IMEDIA *Atmosphere;
>   FOG *Fog;
>   RAINBOW *Rainbow;
>   SKYSPHERE *Skysphere;
> };
>

Hmm....this looks like a good foundation for the basic "scene" object that I
think should be the proxy class (object) for the whole scene in an
OO-version...

(think java)

public class scene{
  povCamera camera;
  povObject objects[];
  // everything is an object - light sources too, for example
  povIniOption ini_options;
  double initial_clock, final_clock, clock;
  povAtmosphere atmosphere;
  povFog fog;
  povSkysphere sky_sphere;
  public class image{
    int width, height;
    outputType output_type;
    // etc.
  }
  // etc.
}

This way, the scene object encapsulates everything regarding the scene to be
rendered, and it feels logical to write lines as these:

scene.image.width
scene.camera.look_at
scene.atmosphere
scene.sky_sphere
..
#if (scene.current_frame=scene.ini_options.initial_frame) ... #end // new one,
that...
#declare scene.objects[0].scale = foo;
#if(scene.camera.look_at=myFoo.location) ... #end

Well, hope I'm not the only one who sees the possibilities here...sorry for
being OT.

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

Btw, good OO design says that you DON'T put member attributes in the public
part of a class.
  Just a side note :)

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

>   Btw, good OO design says that you DON'T put member attributes in the public
> part of a class.
>   Just a side note :)

And just as another side note:  What is the difference between a struct and
a class only containing public data members...?


     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 wrote:
> 
> And just as another side note:  What is the difference between a struct and
> a class only containing public data members...?

None.

Markus

Post a reply to this message

Warp wrote:

>   Btw, good OO design says that you DON'T put member attributes in the public
> part of a class.
>   Just a side note :)
>

Yep, that's right....but I (personally) do not think that any "project" in POV
will be large enough to require information hiding, which was (if I remember
correctly) the reason for inventing encapsulation. I don't think any POV user
would like having to write

#if(MyObject.getLocation()=scene.getCurrentCamera().getLookAt())
  MyObject.setLocation(fubar)
#end

...at least I know _I_ wouldn' t like it. I don't know about you, of
course....would you? :)

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

Thorsten Froehlich wrote:

> And just as another side note:  What is the difference between a struct and
> a class only containing public data members...?
>

As long as you don't want to inherit from that class: none....

:)

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

In article <399D27CE.F6D3DC58@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

>> And just as another side note:  What is the difference between a struct and
>> a class only containing public data members...?
>>
>
> As long as you don't want to inherit from that class: none....

Exactly, so why would it make any difference if it is a class or a struct?

After all, this is the idea behind the rewrite of POV-Ray 4.0:  it is not
about calling every struct "class" now, as a matter of fact a lot of code
has to be changed to provide proper encapsulation.  And this is the major
problem in the current POV-Ray core code <sigh>


     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 wrote:

> Exactly, so why would it make any difference if it is a class or a struct?
>

I think we are discussing apples and bananas here... On one side, it's a
discussion about a complete source-code rewrite...on the other side, it's a
discussion about the POV language. There are areas where they intersect{<g>}, but
as someone pointed out earlier: the java virtual machine is written in plain C
(not C++), i.e. the interpreter does not have to be written in an OO language to
interpret OO source-code.

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

In article <399D3001.2EE450CC@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> I think we are discussing apples and bananas here... On one side, it's a
> discussion about a complete source-code rewrite...on the other side, it's a
> discussion about the POV language.

Ups, you are right, we are discussing different topics here.


     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:
: And just as another side note:  What is the difference between a struct and
: a class only containing public data members...?

  A struct is C. That kind of class is _AWFUL_ C++.

-- 
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 <399D0A81.2F562E82@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Hmm....this looks like a good foundation for the basic "scene" object 
> that I think should be the proxy class (object) for the whole scene 
> in an OO-version...

Are you talking about a scripting language feature, or a start at a 
design for the conversion to C++? Or both?

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

Mikael Carneholm wrote:

> I don't think any POV user would like having to write
> 
> #if(MyObject.getLocation()=scene.getCurrentCamera().getLookAt())
>   MyObject.setLocation(fubar)
> #end

I can confirm that for you :)

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Chris Huff wrote:

> Are you talking about a scripting language feature, or a start at a
> design for the conversion to C++? Or both?
>

Scripting language feature mainly...but it may be suitable with a similar
structure in the code, as well...? That would require some more research,
though...just a quick sketch, that.

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

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

>   A struct is C. That kind of class is _AWFUL_ C++.

Yes, and the compiler I use most of the time (CodeWarrior) has a nice
optional warning "inconsistent use of 'class' and 'struct' keywords" ... it
is very useful when it comes to converting C or old C++ code to clean ISO
C++ code!


     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

In article <399D54D3.1F785B88@pacbell.net> , Ken <tyl### [at] pacbellnet>  
wrote:

>> I don't think any POV user would like having to write
>>
>> #if(MyObject.getLocation()=scene.getCurrentCamera().getLookAt())
>>   MyObject.setLocation(fubar)
>> #end
>
> I can confirm that for you :)

Hmm, what about a language more like an object oriented lisp. For example
(OK, not a great one):


set MyHouse to new house with 10 windows at <10,10,10>

for every window of MyHouse add new curtain with colour red 0.4 green 0.9


I am serious!  Why would an object oriented POV scene description language
have to look like C++???   Surely not just because POV-Ray uses {} and
dot-style vector attribute access?   Anybody remember DKBTrace - it used
Pascal like syntax (and there was already a skyvase.dat)!


     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

In article <399d749a@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Hmm, what about a language more like an object oriented lisp. For example
> (OK, not a great one):
> 
> set MyHouse to new house with 10 windows at <10,10,10>
> for every window of MyHouse add new curtain with colour red 0.4 green 0.9

Have you been playing with AppleScript lately? :-)
I haven't looked at lisp much, but this doesn't resemble what I have 
seen of it...I thought it had a lot of parenthesis, and a generally 
weird syntax? This does resemble AppleScript, though.


> I am serious!  Why would an object oriented POV scene description language
> have to look like C++???   Surely not just because POV-Ray uses {} and
> dot-style vector attribute access?   Anybody remember DKBTrace - it used
> Pascal like syntax (and there was already a skyvase.dat)!

So what you are suggesting would be a completely new language? Or would 
this somehow fit in with the current 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

In article <chrishuff-FFDA79.12564618082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> Have you been playing with AppleScript lately? :-)

Well, AppleScript is a language based on OO-Lisp research...

> I haven't looked at lisp much, but this doesn't resemble what I have
> seen of it...I thought it had a lot of parenthesis, and a generally
> weird syntax? This does resemble AppleScript, though.

Yes, parenthesis are one of the worst problems of Lisp :-)   If you look at
some more recent programming language books, you will even find AppleScript
somewhere in the Lisp tree (but some it in a tree for scripting languages).


      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

In article <399d82ed@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Well, AppleScript is a language based on OO-Lisp research...

Hmm, I didn't know that...
What do you know about Smalltalk and Objective-C?

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

Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, what about a language more like an object oriented lisp. For example
: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>

: for every window of MyHouse add new curtain with colour red 0.4 green 0.9

  That's not even close to lisp.

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

>   That's not even close to lisp.

I did NOT say that this is close to Lisp...


   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 wrote:

> I am serious!  Why would an object oriented POV scene description language
> have to look like C++???   Surely not just because POV-Ray uses {} and
> dot-style vector attribute access?   Anybody remember DKBTrace - it used
> Pascal like syntax (and there was already a skyvase.dat)!
>

There's really nothing wrong with the current POV-Script syntax - all it needs
is some modifications to make it a (somewhat) fully object oriented language.
We should not change the language into something completely different, just
add some new features - like it was when file I/O was introduced in v3.1.

Just my 0,18 SKr.. (that's the value of $0.02, in swedish crowns!) :)

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

In article <399FE3F5.A96D722F@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> There's really nothing wrong with the current POV-Script syntax - all it needs
> is some modifications to make it a (somewhat) fully object oriented language.

This still doesn't answer my question: Why?

Why would more OO features in the scene language improve its usability?
Would it be easier to learn?  Would it be fast to parse?  Would it allow
porting C/C++/Java programs to POV-script?

In short : What are the _practical_ benefits for the scene description, the
primary purpose of the POV scene description language?


    Thorsten

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: I did NOT say that this is close to Lisp...

  Well, that's what your statement seems to imply:

: Hmm, what about a language more like an object oriented lisp. For example
       =====================      ====                    ====  ===========

: (OK, not a great one):

: set MyHouse to new house with 10 windows at <10,10,10>


  I undestand your statement that your example should look like lisp.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
: This still doesn't answer my question: Why?

: Why would more OO features in the scene language improve its usability?

  What I am personally still missing from povray are dynamically allocated
objects (where, the objects in povray are indeed dynamically allocated, but
their syntax makes them quite static) and references or pointers to handle
them.
  That would allow making, for example, linked lists, trees and so on.

  If those were implemented in an object-oriented way, it would be a plus.
Making them in a C way would just cause a lot of spaghetti code.

  And object orientedness would help making better scripts. Perhaps most
users will not get any advantage of it, but most include file makers
certainly could.
  Just think about the possibilites. Include files using common abstract
base classes could be used more or less seamlessly together. Clear
interfaces will make them easy to use and maintain, and information hiding
will help avoiding all namespace trashing problems (there's nothing more
annoying than two include files using identifiers with same names).

: Would it be easier to learn?

  It doesn't matter. You don't have to learn it if you don't want it. The
fact that a feature is there doesn't mean you have to learn and use it.
You can let it be and leave the usage to the "experts" :)

: Would it be fast to parse?

  Would it be slower? Does it matter?

:  Would it allow
: porting C/C++/Java programs to POV-script?

  Why anyone would want to do this? They do different things.

: In short : What are the _practical_ benefits for the scene description, the
: primary purpose of the POV scene description language?

  Ok, let's then remove identifiers and #while-loops and #macros. They have
no practical benefit, have they? You can do the same thing without them,
can't you?

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

Warp wrote:

>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

No you can't at least where #while loops are concerned. You would have
to use an external program to get the same funcionality. #macros could
be eliminated without loss of funcionality however.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

Ken <tyl### [at] pacbellnet> wrote:
: No you can't at least where #while loops are concerned. You would have
: to use an external program to get the same funcionality.

  Of course you can. Just write all the generated objects by hand.

: #macros could
: be eliminated without loss of funcionality however.

  If #while-loops are indispensable, then so are #macros. Just think about
recursive #macros. Although recursion is very similar to looping, it's
easy to make a recursive #macro which functionality cannot be made with
#while loops (because you would need a dynamic stack and there are no
such things in povray (or at least not any efficient one)).
  One example of recursive macros are tree generator macros.

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

Warp wrote:

>   One example of recursive macros are tree generator macros.

Thre were recursive tree include files around before macros were
introduced. PTDTree for example.

-- 
Ken Tyler - 1400+ POV-Ray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

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

>   What I am personally still missing from povray are dynamically 
> allocated objects (where, the objects in povray are indeed 
> dynamically allocated, but their syntax makes them quite static) and 
> references or pointers to handle them.
> That would allow making, for example, linked lists, trees and so on.

Another built-in data structure might be sufficient for this. What I am 
talking about is a new data structure and functions for operating on it, 
a kind of tree which can link to any number of nodes. You could use it 
to build a linked list, a binary tree, an oct-tree, etc.
Maybe a separate "list" structure would still be useful, it would be 
more memory efficient than the above structure. Both of these would be 
easier to use and faster than their equivalents in POV-Script.

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

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

> : I did NOT say that this is close to Lisp...
>
>   Well, that's what your statement seems to imply:
>
> : Hmm, what about a language more like an object oriented lisp. For example
>        =====================      ====                    ====  ===========
[...]
>  I undestand your statement that your example should look like lisp.

Well, English and German are belong to the same family of languages, yet
they do not look the same either.  Yet the "idea" (history), if there is
such a thing behind a spoken language, is the same.

So, please do not read my "like" as "looks like", but if the plain "like" is
not precise enough for you as "inspired by" Lisp.  Also, you cannot just
pick a few words of a sentence and ignore the rest:  I didn't say "like
Lisp", I said "like an object oriented lisp" - note the words _between_
"like" and "Lisp" :-)

As for the actual "idea" behind Lisp is the abstraction _and_ the way it is
implemented, this is the actual similarity between the examples I provided
and any example doing the same in Lisp.  I played it safe by using an
example which would in this style nearly work in a language I know:
AppleScript (which is very similar to HyperTalk).

And at least HyperTalk is considered to be part of the same language family
Lisp is a member of (also it is not _close_ to Lisp syntax)...


     Thorsten


PS: I tried to find a good link to some place proving my statement, but
unfortunately any search for Lisp and AppleScript or Hypertalk return tons
and tons of resume pages <sigh>   The closest but not very well discussed
note I could find is at <http://www.useit.com/papers/tripreports/ht89.html>.
I don't have any of my Prog. Language (History) books here in Germany, so I
can't give you any printed references right now :-(

____________________________________________________
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

In article <399feed3@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> This still doesn't answer my question: Why?
> Why would more OO features in the scene language improve its usability?

I've often wished I could store a bunch of different types of data for a 
data structure in one chunk. Objects are an obvious place to put them. I 
had to settle for a bunch of global arrays, and eventually gave up.
The technique of #declaring a bunch of variables and #indluding a file 
is clumsy and can lead to variable name conflicts. Macros don't have 
variable numbers of parameters, so you sometimes have to resort to the 
same thing: #declaring variables before calling the macro. Long lists of 
macro parameters are difficult to keep track of. If object-oriented 
features were added, you could simply declare an object that does 
whatever was done by #including or calling a macro. For example, a lens 
flare object could be used like this:

#declare MyFlare = object {PlainLensFlare};

MyFlare.SetSize(5);
MyFlare.SetPos(< 5, 1, 6>);
MyFlare.SetColor(< 1, 0, 0.5>);
object {MyFlare.CalculateFlare();}

#declare MyFlare = object {SparkleLensFlare};
MyFlare.SetSize(2);
MyFlare.SetPos(<-5, 1, 6>);
MyFlare.SetColor(< 0, 1, 0>);
object {MyFlare.CalculateFlare();}

MyFlare.SetPos(< 0, 5, 6>);
MyFlare.SetColor(< 1, 1, 0>);
object {MyFlare.CalculateFlare();}

This would make 3 lens flares, a purple one to the right, a smaller 
green one to the left, and a yellow one above. You would only need to 
specify the parameters which you want to change, you could have as many 
as you want with no trouble, and you would have far fewer problems with 
variable name collision, since you would only need to watch out for the 
object names, not the parameters. If you wanted to make a slightly 
different lens flare, you wouldn't have to copy/paste a bunch of code 
from the original include and modify it, you could just make an object 
from one of the original objects and override some of the member macros.


> Would it be easier to learn? 

No, but since the existing language wouldn't need to be disturbed, you 
wouldn't have to learn it. It would be considerably easier to learn than 
C++, though.


> Would it be fast to parse? 

It probably wouldn't be noticeably slower without benchmarking, and 
could possibly allow doing some things in a way that would parse faster 
than previously possible.


> Would it allow porting C/C++/Java programs to POV-script?

No more than you can already port C or Pascal programs to POV-Script. 
Why would you want to do such a thing, anyway?


> In short : What are the _practical_ benefits for the scene 
> description, the primary purpose of the POV 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

In article <chrishuff-47A4E5.19070718082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> What do you know about Smalltalk and Objective-C?

That a Smalltalk development system for the Mac does not have any space in
my budget for the next few years :-(

As for Objective-C, I have not programmed in it myself, but I have gone over
many of the (old) NextStep sample code a few years back.  It is not
difficult to understand (compared to 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

In article <chrishuff-5D4489.11363420082000@news.povray.org> , Chris Huff 
<chr### [at] maccom>  wrote:

> I've often wished I could store a bunch of different types of data for a
> data structure in one chunk.

Well, this is obviously not a feature of object oriented languages only.  I
agree that there hsould be some way to store data of different types more
easily, but I am not sure if C++/Java style syntax would really be the most
appropriate and easy to learn.

As said before, there are programming languages that fit the language model
of POV-Ray much better than C/C++/Java.

> #declare MyFlare = object {PlainLensFlare};
>
> MyFlare.SetSize(5);
> MyFlare.SetPos(< 5, 1, 6>);
> MyFlare.SetColor(< 1, 0, 0.5>);
> object {MyFlare.CalculateFlare();}

What is wrong with:

object
{
    PlainLensFlare
    scale 5
    translate < 5, 1, 6>
    color < 1, 0, 0.5>
}

I understand that there are cases when it appears to be the best way to use
the kind of syntax you suggest. (continues below)


>> Would it be easier to learn?
>
> No, but since the existing language wouldn't need to be disturbed, you
> wouldn't have to learn it. It would be considerably easier to learn than
> C++, though.

My major problem with it is that is obvious in all discussions about an
object oriented POV scene description language is that people who are
familiar with C/C++/Java seem be caught in the thinking that every language
should look this way. to quote the old Apple slogan "Think Different"!

In particular, I think the low level capabilities of C/C++/Java are in the
way of creating a simple and easy to learn object oriented extension to the
POV language.  As a matter of fact, due to the completely different nature
of C/C++/Java and POV, nobody having to learn it would benefit from existing
C/C++/Java documentation, books, etc if he/she does not know any of them
before.

To quote [1] Tog talking about the JavaScript in "How Programmers Stole the
Web":

>> And from whence arose this new syntax? It was derived from, and I am quoting
here, "the familiar C++ syntax." Familiar to whom? Certainly not the
millions upon millions of people who know BASIC. Certainly not the millions
upon millions who know HTML. It was familiar to the select cadre of
engineers at Netscape, along with all of their friends. Did they set out to
be exclusionary? I'm sure not; they just simply adapted the tools with which
they themselves felt comfortable. <<

So, should programmer also "steal POV-Ray"?

>> Would it be fast to parse?
>
> It probably wouldn't be noticeably slower without benchmarking, and
> could possibly allow doing some things in a way that would parse faster
> than previously possible.

Well, I would say it would parse slower because certain access to internal
data structures of POV-Ray would surely take some time.  A more abstract
language could hide these complex tasks behind the POV scene language and
use the many benefits of a hardwired access of C++ (in POV-Ray 4.0) rather
than doing it in small steps in the interpreted POV scene language!

>> Would it allow porting C/C++/Java programs to POV-script?

This is a rather provocative question, and I wanted to see someone claim
this would be the reason for the language extension :-)


     Thorsten




[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>

____________________________________________________
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

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

> : Why would more OO features in the scene language improve its usability?
>
>   What I am personally still missing from povray are dynamically allocated
> objects (where, the objects in povray are indeed dynamically allocated, but
> their syntax makes them quite static) and references or pointers to handle
> them.
>   That would allow making, for example, linked lists, trees and so on.
>
>   If those were implemented in an object-oriented way, it would be a plus.
> Making them in a C way would just cause a lot of spaghetti code.

Hmm, you seriously want to call the C++ STL anything else but "spaghetti
code"?  ;-)

Did you consider more abstract Basic-like (READ: in the spirit of ease of
use and learn typical for the average Basic, NOT the syntax style of Basic)
syntax for it?  POV-Ray already has a few hundred keywords, would the ten or
so for a simple built-in implementation really matter compared to the two or
so needed for a C++/Java style implementation allowing references (no
pointers, pleeeeeeeeeeeease!)?

>   And object orientedness would help making better scripts. Perhaps most
> users will not get any advantage of it, but most include file makers
> certainly could.

Since when does object orientedness improve programming?  How many books,
lectures, labs and practice did you need to master the basics of C++ (not to
mention the basics of object oriented design) compared to the basics of POV?
How many "users" of POV-Ray would really benefit and have the background to
use it?

>   Just think about the possibilities Include files using common abstract
> base classes could be used more or less seamlessly together. Clear
> interfaces will make them easy to use and maintain, and information hiding
> will help avoiding all namespace trashing problems (there's nothing more
> annoying than two include files using identifiers with same names).

For whom?  Programmers with a Ph.D. or the average user with perhaps one or
two years of (hobby) programming experience?

namespaces are a problem, but they can be overcome by simple organisational
manners, without the need for a language extension.  Namespaces are merely a
hack to allow programmers not to talk to each other and follow naming
conventions that could be set by a majority vote and central name
registration system!

> : Would it be easier to learn?
>
>   It doesn't matter. You don't have to learn it if you don't want it.

Great argument!  Who cares if someone can read a POV scene and learn from
it, why should there be new novice users of POV-Ray?

Please read [1], maybe then you understand and leave your tower <sigh>

> : Would it be fast to parse?
>
>   Would it be slower? Does it matter?

Yes (answering your second question).

> :  Would it allow
> : porting C/C++/Java programs to POV-script?
>
>   Why anyone would want to do this? They do different things.

See my note to Chris Huff :-)

> : In short : What are the _practical_ benefits for the scene description, the
> : primary purpose of the POV scene description language?
>
>   Ok, let's then remove identifiers and #while-loops and #macros. They have
> no practical benefit, have they? You can do the same thing without them,
> can't you?

Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
engine!  There are features that have more relative value compared to their
cost while others have a lower relative value compared to their (possibly
very high) cost. Note the "relative".


       Thorsten


[1] "How Programmers Stole the Web" by Bruce Tognazzini
    <http://www.AskTog.com/columns/028WebStealers.html>


____________________________________________________
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

Ken <tyl### [at] pacbellnet> wrote:
: Thre were recursive tree include files around before macros were
: introduced. PTDTree for example.

  My point was that it can't be done with a #while-loop.

  Btw, isn't the include recursion level limited to something like 10 in
povray?

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

>   Btw, isn't the include recursion level limited to something like 10 in
> povray?

And won't a very high recursion level crash it when using a macro and a
stack overflow occurs?


    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:
: And won't a very high recursion level crash it when using a macro and a
: stack overflow occurs?

  I'm not sure, but I think that's a compiler-dependant problem. That is,
it depends how big is the stack the compiler makes the program to use.
Some compilers make a laughably small stack (like 16 kilobytes or so).
  Here (in Solaris with gcc) the stack size is something like 2GB and I
don't remember any recursive macro crashing here.

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

Thorsten Froehlich <tho### [at] trfde> wrote:
: Hmm, you seriously want to call the C++ STL anything else but "spaghetti
: code"?  ;-)

  I don't know. From the point of view of the user of the library it has
a pretty clever and abstract interface and the division into modules looks
good.
  I have never looked into the source code of any STL implementation, though.

: so needed for a C++/Java style implementation allowing references (no
: pointers, pleeeeeeeeeeeease!)?

  References are pointers.
  The syntax for references usually doesn't allow you to make so many things
with them than with pointers, but basically they are the same thing.
  So it doesn't matter if we call them references or pointers. The important
thing is what do we allow and what we don't to do with them.

  In C++ pointers are very free (and thus dangerous) and references are very
strict. For example, you can't assign a new value to a reference. In Java
references are more free than in C++ because you can assign the references
to point to new objects. This is an important feature because without it
it wouldn't be possible to make lists and so on.
  I have always said, that "it's not true at all that there are no pointers
in Java, all the contrary: In Java _everything_ is a pointer".

:>   Just think about the possibilities Include files using common abstract
:> base classes could be used more or less seamlessly together. Clear
:> interfaces will make them easy to use and maintain, and information hiding
:> will help avoiding all namespace trashing problems (there's nothing more
:> annoying than two include files using identifiers with same names).

: For whom?

  From other include files. From the user.

: Great argument!  Who cares if someone can read a POV scene and learn from
: it, why should there be new novice users of POV-Ray?

  So you say that we shouldn't give powerful tools to people who wants them
only because newbies can't read the code?

:> : Would it be fast to parse?
:>
:>   Would it be slower? Does it matter?

: Yes (answering your second question).

  So if it does matter, then we should remove the #macros. They are very slow.
Specially when included. Also #while-loops are usually slow. What about
big triangle meshes and bicubic patches? They are slow to parse so we should
remove them.

  No, I still think that it doesn't matter. Features are not left out because
they are slow to parse.

: Hmm, rejecting a jet engine for a car does not imply rejecting a gasoline
: engine!  There are features that have more relative value compared to their
: cost while others have a lower relative value compared to their (possibly
: very high) cost. Note the "relative".

  Yes, there's a cost in designing a OO-pov language. But that's not a cost
for the user. The users will probably not notice much difference. Someone
may sometimes post a weird OO-pov code in text.scene-files, but they are
usually hard to read anyways ;)

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