 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ron Parker <ron### [at] povray org> wrote:
:> Those member functions were pretty obviously inherited from "sphere".
: You're confusing objects with classes here.
As I said in another article, there are lots and lots of
misunderstandings... :)
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <slr### [at] fwicom>,
Ron Parker <ron### [at] povrayorg> wrote:
> > Those member functions were pretty obviously inherited from "sphere".
>
> You're confusing objects with classes here.
No, though I might have misunderstood Jan's example. I was assuming the
complete lack of classes.
http://www.google.com/search?hl=en&q=prototype+based+object+oriented
http://www.cetus-links.org/oo_self.html
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jan Walzer <jan### [at] lzernet> wrote:
: Reality is: _I_ (read that this means Me, and only Me) don't care, if SDL
: resembles OO by the definition, or not... Maybe it would be enough, to stay
: modular...
In fact, the povray SDL has currently very poor means of achieving good
modularity.
You can't make modules (classes, structs, whatever) with public interfaces
and private attributes and implementations, you can't construct your own
abstract data types, you can't make objects (ie instances of these data
types) and so on. You can't even construct the most basic types of dynamic
data containers (eg. lists, trees and so on; and yes, I know about arrays,
but they are currently just too clumsy and inefficient as *dynamic* data
containers).
able to dynamically allocate them (and having references to these allocated
objects) would be an enormous step in versatility and modularity. Structures
and references cover most of the features needed for user-defined abstract
data types (although without interfaces they are still not very modular).
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christopher James Huff <chr### [at] maccom> wrote:
:> There is nothing to stop the embedding of an existing OO language ( like
:> Ruby ) into the POV GUI with POV libraries or bindings to some form of POV
:> API. This meta scripting language could drive the GUI and external
:> utilities as well as be embedded into the POV SDL files.
: Well, there is one thing: licensing. The current POV license is pretty
: restrictive (though for very good reasons).
I think that what he proposed was not embedding *povray* into a language
interpreter, but the other way around, ie. embedding a language interpreter
*into* povray. That is, just make a patch for another scripting language
support.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c587c08@news.povray.org>, Warp <war### [at] tagpovrayorg>
wrote:
> I think that what he proposed was not embedding *povray* into a language
> interpreter, but the other way around, ie. embedding a language interpreter
> *into* povray. That is, just make a patch for another scripting language
> support.
He said "as well as be embedded into the POV SDL files".
Though I suppose you could do both...embed another language in the
script, have another program go through, execute that code, replace it
with POV code, and then pass the result on to POV-Ray.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c585ac5$1@news.povray.org>,
"Tom Bates" <tho### [at] shawca> wrote:
> I still, however, have hoped to find a ray-tracer or graphics tool
> that has the OO features that I planned for my own rewrite. I've
> even considered writing a parser that would take an OO syntax
> and generate standard POV code from it (once I have time for
> something like that).
Have you looked at my CSDL project? It will have a library that does
just that.
--
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Nice! What do I have to do to have a go at this stuff?
Christopher James Huff wrote:
>
> Hmm, I just couldn't resist converting this to CSDL (or at least,
> something that resembles what CSDL eventually will be):
[code]
> --
> Christopher James Huff <chr### [at] maccom>
> POV-Ray TAG e-mail: chr### [at] tagpovrayorg
> TAG web site: http://tag.povray.org/
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I don't think that it's possible to make the SDL completely OO. OOP is too
complex to be used in the POV-Ray SDL. An example: When creating an object,
several elements must be created: pigment, finish, texture, ... But who
creates them? Does the user have to call MyObject.add_finish? This wouldn't
be logical. An object has a finish, whether it's created by the user or not.
POV-Ray had to have a lot of pre-defined classes which provide all those
features.
Also, the POV-Ray parser is not very fast. OOP would make parsing even
slower. Why not creating scenes with an external program (like moray)?
Although pseudo-OOP would be a good idea (to acces elements like
MyObject.Part1.finish.phong).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Looks like CSDL might be the future. Not that it'll stop us hand-coding
everything, but it's nice to have the option
Felix Wiemann wrote:
> I don't think that it's possible to make the SDL completely OO. OOP is too
> complex to be used in the POV-Ray SDL.
> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower. Why not creating scenes with an external program (like moray)?
> Although pseudo-OOP would be a good idea (to acces elements like
> MyObject.Part1.finish.phong).
--
signature{
"Grey Knight" contact{ email "gre### [at] yahoocom" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Felix Wiemann" <Fel### [at] gmxnet> wrote in message
news:3c594865@news.povray.org...
> I don't think that it's possible to make the SDL completely OO. OOP is too
> complex to be used in the POV-Ray SDL. An example: When creating an
object,
> several elements must be created: pigment, finish, texture, ... But who
> creates them? Does the user have to call MyObject.add_finish? This
wouldn't
> be logical. An object has a finish, whether it's created by the user or
not.
> POV-Ray had to have a lot of pre-defined classes which provide all those
> features.
That's why you use object constructors :)
> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower. Why not creating scenes with an external program (like moray)?
> Although pseudo-OOP would be a good idea (to acces elements like
> MyObject.Part1.finish.phong).
True. Maybe speed optimizations for the parser?
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
