 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] yahoo com" }
site_of_week{ url "http://digilander.iol.it/jrgpov" }
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Felix Wiemann" <Fel### [at] gmxnet> wrote in message
news:3c594865@news.povray.org...
> I don't think that it's possible to make the SDL completely OO. OOP is too
> complex to be used in the POV-Ray SDL. An example: When creating an
object,
> several elements must be created: pigment, finish, texture, ... But who
> creates them? Does the user have to call MyObject.add_finish? This
wouldn't
> be logical. An object has a finish, whether it's created by the user or
not.
> POV-Ray had to have a lot of pre-defined classes which provide all those
> features.
That's why you use object constructors :)
> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower. Why not creating scenes with an external program (like moray)?
> Although pseudo-OOP would be a good idea (to acces elements like
> MyObject.Part1.finish.phong).
True. Maybe speed optimizations for the parser?
...Chambers
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Felix Wiemann <Fel### [at] gmxnet> wrote:
: Although pseudo-OOP would be a good idea (to acces elements like
: MyObject.Part1.finish.phong).
What is "pseuso-OOP" and what does it have to do with getting individual
components of a module/structure?
--
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3c594865@news.povray.org> , "Felix Wiemann"
<Fel### [at] gmxnet> wrote:
> Also, the POV-Ray parser is not very fast. OOP would make parsing even
> slower.
Sorry to say, but you don't know what your are talking about. The parser
isn't slow, memory allocation for objects is slow. It has been a topic in
these groups more than once.
Please note that 4.0 has been a topic of pointless discussion more than once
as what you say or don't say will not be considered for 4.0 in the first
place. This has been made clear in various official statements. For example:
From: "Chris Cason"
Newsgroups: povray.announce.frequently-asked-questions
Subject: POV-Team Status Report - September 1, 2000
Date: Sun, 3 Sep 2000 22:29:58 +1100
Message-ID: <39b2364b@news.povray.org>
Xref: news.povray.org povray.announce.frequently-asked-questions:40
Thorsten
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That's why you use object constructors :)
But these constructors had to be pre-defined by POV-Ray, I meant.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> What is "pseuso-OOP" and what does it have to do with getting
> individual components of a module/structure?
You're right, "pseudo-OOP" is not the right word, better is "using of
structs".
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <tom### [at] tomandlucouk> wrote in message
news:3c57d5a1@news.povray.org...
> Just out of curiousity....
Pardon me for speaking out of turn, because most of the people contributing
to this thread seem pretty on the ball with their languages, but doesn't POV
has a basic sort of inheritance anyway?
#local MySphere1=sphere {0 1 pigment {rgb 1}}
#local MySphere2=object {MySphere1 pigment {rgb 0}}
MySphere1 and MySphere2 come out different. If you want cascading changes
similar to classes why not have something like:
#local MySphere2=object {MySphere1 inherit {all | include {some things or a
#declared collection of things} | exclude {other things or a #declared
collection of things} }
I know this kind of inheritance doesn't work for things like mesh2 objects
and their textures, but I think something like the above would make for more
friendly, and tighter, script than the other hypothetical examples posted in
this thread.
Or am I talking tosh?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Thu, 31 Jan 2002 19:12:28 -0000, Alan Holding wrote:
> Pardon me for speaking out of turn, because most of the people contributing
> to this thread seem pretty on the ball with their languages, but doesn't POV
> has a basic sort of inheritance anyway?
Yes, sort of, but not in the way you use the term when speaking of OO.
POV can't have inheritance because it doesn't really have classes, and
you can't talk about inheritance without using the notion of a class.
--
#macro R(L P)sphere{L F}cylinder{L P F}#end#macro P(V)merge{R(z+a z)R(-z a-z)R(a
-z-z-z a+z)torus{1F clipped_by{plane{a 0}}}translate V}#end#macro Z(a F T)merge{
P(z+a)P(z-a)R(-z-z-x a)pigment{rgbf 1}hollow interior{media{emission 3-T}}}#end
Z(-x-x.2x)camera{location z*-10rotate x*90normal{bumps.02scale.05}}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alan Holding <tro### [at] tiscalicouk> wrote:
: #local MySphere2=object {MySphere1 inherit {all | include {some things or a
: #declared collection of things} | exclude {other things or a #declared
: collection of things} }
This is the wrong concept of inheritance.
Inheritance is not "make an object including some features of another
object and excluding other features, or changing some of the features".
Inheritance is spezialization. A base class is a more generic concept
and an inherited class is specialization, ie. a more concrete version of
that concept. The inherited class is, by all means, a base class (with
some additions, implementations or specializations).
For example, we could have a base class called 'Vehicle' which is a
generic concept. Then we could specialize a more concrete class 'Car' from
it. A 'Car' is a 'Vehicle' by all means. 'Car' knows and supports everything
'Vehicle' does. Everything that uses an object of the 'Vehicle' can use an
object of type 'Car'.
--
#macro N(D)#if(D>99)cylinder{M()#local D=div(D,104);M().5,2pigment{rgb M()}}
N(D)#end#end#macro M()<mod(D,13)-6mod(div(D,13)8)-3,10>#end blob{
N(11117333955)N(4254934330)N(3900569407)N(7382340)N(3358)N(970)}// - Warp -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
