 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In povray.general Mikael Carneholm <sa9### [at] ida utbhbse> wrote:
: // IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
: "from" better than "like" maybe?)
Perhaps the best name would be "is_a".
1. Inheritance (at least public inheritance) is always an "is a" relation.
The inherited class "is a" base class.
For example if we have a base class Vehicle and we inherit a class Car from
it and then we inherit a class Opel from it, the "is a" relation is clear:
Opel is a Car, and Car is a Vehicle.
2. The "is a" relation means that an instance of the derived class can be
used anywhere an instance of the base class is used. This means that the
derived class must contain all the functionality of the base class.
The second note is important. Sometimes one can do bad inheritance if only
the first thing is taken into account. For example one could think that
a Circle "is a" Ellipse so one could (wrongly) make an Ellipse base class and
inherit a Circle class from it. However, a Circle does not have the same
functionality as the Ellipse (eg. you can't set two radiuses).
It is considered bad OO design to inherit from another class only to make
a "copy" of that class with some modification. For example if I have the
class IceCream, which describes a chocolate ice cream and then I inherit
a StrawberryIceCream from it, to make a similar ice cream, but with
strawberry flavor, that's bad OO design.
The correct way is to make a (possibly abstract) base class IceCream and
then inherit different flavored classes from it, eg. ChocolateIceCream and
StrawberryIceCream. Now there's a true "is a" relation between inherited
and base classes.
Why do I write all this? Because I didn't like your example:
: #declare worm_part2=like worm_part1{
: pigment{color rgb 0} // leaves everything like worm_part1, except the pigment.
: }
You are making a strawberry ice cream from a chocolate ice cream here :)
: ....and this last block would be polymorphism, don't you think, Warp? Well of
: course, we don't call common-named methods with different implementations here (as
: the well taught OO student points out), but the <object>.location expression is
: referencing different object types with common attribute names.
That's not polymorphism, it's dynamic binding.
Yes, a true OO feature.
--
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 <399CFECD.630F8C9C@ida.utb.hb.se>, sa9### [at] idautbhbse
wrote:
> I think the main advantage of OO (from my point of view) would be
> _reading_ the location/rotation/scale etc. of objects...
...snip...
This won't be possible, even with member variables and macros.
Transformations(scale, rotate, translate, matrix) are all stored in a
4*4 matrix, and what would "location" mean? The center of the bounding
box?
BTW, I would prefer a #reference keyword to your ref {} syntax, it could
be used outside of objects. Maybe a specific members {} block in objects
would be a good idea, though...
object {...
members {
#reference Next = object {...};// a reference
#declare Velocity = < 1, 5, 0>;// a public variable
#local Speed = vlength(< 1, 5, 0>);// a protected variable
#macro GetSpeed() Speed #end // a member macro
}
}
All objects would already have public transform and material member
variables and member macros for operating on them(you could arrange all
objects in a heirarchy, with "object" being the base object, so the
language is consistent, but of course, these would be hard-coded...). In
addition to these inherited members, objects would have variables
specific to them: spheres would have a "center" vector and a "radius"
float, boxes would have "point_a" and "point_b" vectors...this would
allow the current syntax to be retained, but make things easy to do with
the OO syntax.
BTW, I think the biggest advantage of OOP scripting would be things like
macros and include files that really emulate objects. You could create a
"lens flare" object, and have as many of these as you wanted, and it
would be almost completely transparent to the person using the lens
flares. Or you could do particle systems, tree/plant objects,
etc...using them could be much easier than with macros and include
files, especially when you have many of them.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Warp wrote:
> Perhaps the best name would be "is_a".
Errr...it's not what type of relation it is...it's what the keyword in OO-POV should
be!
I know it's an "is a"-relation - just sketching on a suggestion for new syntax! :-)
<lots of basic OO theory snipped>
> It is considered bad OO design to inherit from another class only to make
> a "copy" of that class with some modification. For example if I have the
> class IceCream, which describes a chocolate ice cream and then I inherit
> a StrawberryIceCream from it, to make a similar ice cream, but with
> strawberry flavor, that's bad OO design.
> The correct way is to make a (possibly abstract) base class IceCream and
> then inherit different flavored classes from it, eg. ChocolateIceCream and
> StrawberryIceCream. Now there's a true "is a" relation between inherited
> and base classes.
>
> Why do I write all this? Because I didn't like your example:
>
> : #declare worm_part2=like worm_part1{
> : pigment{color rgb 0} // leaves everything like worm_part1, except the pigment.
> : }
>
> You are making a strawberry ice cream from a chocolate ice cream here :)
Of course, I could have made an abstract base (class) object worm_node, and then
inherited worm_part1 and worm_part2 from that object, but as stated before: OO-POV
should not be java (actually, java is already very good at it - being java, i.e.), and
thus it may not need being as OO correct as java is. In the code above, one is saying:
"worm_part2 is like worm_part1, except it has a different pigment" - and I guess many
users would be irritated if they got an error saying "Not strictly correct OO used at
line nnn" while parsing? AND - POV-Ray has always been known for it's flexible and
(rather) forgiving syntax - let's keep it that way.
If one made multiple inheritance possible I could see your point, but that's not going
to happen (if I get to choose) - because THEN we're really talking bad OO design.
> That's not polymorphism, it's dynamic binding.
>
Yep, you're right there...I always seem to regard those two as equivalent, even though
there is a difference. Anyway, if the OO POV language also should incorporate object
methods (you never know), they should of course be allowed to work in a polymorphic
way,
if possible.
----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Chris Huff wrote:
> Transformations(scale, rotate, translate, matrix) are all stored in a
> 4*4 matrix, and what would "location" mean? The center of the bounding
> box?
Location, as I thought of it, should be one of the common attributes for all
objects. Think java again:
public virtual class POVOBJECT{
public povVector location, rotation;
}
As you see, one can't create a "povobject", but all objects in the POV 3d
space should be descendants from this class, as all objects in POV can be
rotated and translated. I.e, let's continue with the class declaration for a
sphere:
public class SPHERE extends POVOBJECT{
public double radius;
public povMaterial material;
}
Ok, let's create a sphere:
#declare A=sphere{
0, 0.5
pigment{ color rgb 1}
}
Right now, A.location=<0,0,0>, and A.rotation=<0,0,0> (as default). If we
change A.location:
#declare A.location=<0,1,0>; // or by using a method, like
A.translate(<0,1,0>) (?)
..A.location is now <0,1,0>, similar to sphere{ ... translate <0,1,0>}. For
other type of objects, like boxes, it's maybe not a bad idea using the
center of the bounding box. Coming to thinking of it - maybe it's better to
have a "translation" attribute instead, which together with object specific
member attributes could be used to get the data needed:
#declare foo=sphere{
<0,1,0>, //let's store this in a sphere-specific attribute called
"origin", which holds the vector where it was originally created.
0.5
translate <1,0,0>
}
To retrieve the center of the sphere, one could use foo.origin and
foo.translation: The center of the sphere is now at
foo.origin+foo.translation.
This would work better with other types of objects, as box for example,
where the whereabouts on this box:
#declare foo=box{
-1,1
translate <1,1,1>
}
..could be retrieved using foo.corner1, foo.corner2 (or something like that)
together with foo.translation. Cylinders could have .top, .bottom, .radius,
polygons could have .point[] and .point_count etc.
> BTW, I would prefer a #reference keyword to your ref {} syntax, it could
> be used outside of objects. Maybe a specific members {} block in objects
> would be a good idea, though...
> object {...
> members {
> #reference Next = object {...};// a reference
> #declare Velocity = < 1, 5, 0>;// a public variable
> #local Speed = vlength(< 1, 5, 0>);// a protected variable
> #macro GetSpeed() Speed #end // a member macro
> }
> }
Not a bad suggestion, at all. I've been thinking of something similar, i.e.
all (POV) objects can have abstract (non visual) member attributes and
methods:
#declare myMovingThingy=union{
cylinder{...}
box{...}
members{
#reference Next = object {...};// a reference
#declare Velocity = < 1, 5, 0>;// a public variable
#local Speed = vlength(< 1, 5, 0>);// a protected variable
#macro GetSpeed() Speed #end // a member macro
}
}
Here, the encapsulation subject is also covered, so I guess Warp is happy
now :)
As said, the subject is open for suggestions..
----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > 1. This one is simple and could be implemented now without too much
> > trouble, but would be very convenient to povers.. we have a union, a
> > diff. a ... ect why not a simple group keyword...
> ...snip...
>
> Umm, how is this different from union? Pretty much all union does is
> group objects so you can tranform, texture, or CSG all of them at once.
sorry, my mistake, I was thinking that a union could only be used for
objects physically connected, and that it would be nice to be able to
manipulate a group of objects as one, with out changing the final
image..(though I guess image mapping might look different).
>
> > 2. One should be able to create and delete objects from a scene at
> > any time.(and a delete group object would recursively remove all the
> > object contained by that group...)
>
> Once an object is in the scene, it should stay there, and stay in the
> same state it was when it was first placed there. If you decide an
> object isn't in the scene, you shouldn't put it there in the first place.
I meant for animations, interactive 3d, ect. where you would want to
change objects arbitrarily from any point, like switching a virtual
light switch to remove(or just make invalid) a light source, for
example.
>
> > 3. The pov-core should be like a library, providing basic functions
> > to other programs.
> ...snip...
> This sounds an awful lot like the "POV should be/have an API"
> argument...and has been discussed many times. The source code may be
> designed something like this(just for good design practice), but the
> interface may not be available to outside programs.
>
there are over 20,000 messages in this newsgroups, so there is no way I
could just read them all to see if the topic had been discussed. I
really think this is an important thing to have, it allows it to be very
versatile and modular, and independent of application, one person might
want to used it to render a singe frame, another might want to take his
hand at a movie :), (I have a lot of ideas with raytracing that would be
alot easier to try if it was like this, for right now I'm actually
writing my own ray tracer because it easier than making changes all
across what like 90,000 lines of code that povray currently is!!
> > note: this would also make it more portable, nothing platform specific
> > would be included in the core.
>
> Organizing the platform-independant core code as separate objects would
> make it more independant, but there still isn't a platform independant
> way of making those functions available to outside programs.
huh?? I don't know what you mean by that. if you provide a platform
independent method called trace_scene(POVScene,POVCamera), any other
c/c++ program can call it and do what every it wants with it(likely
platform specific like some kind of gui.)
>
> > 4. plugable... plugable object types, plugable effects, plugable
> > cameras.. everything. If this happened, I would even write a
> > plugger-client/server to connect to the official plug-in site, and offer
> > all users a easy way to download/install/ any plug-ins.. you could even
> > have different channels.. ever seen helix-code update???
>
> Extremely difficult to do, and practically impossible to do without a
> high cost in speed. The plugins(and the code for dealing with them)
> would have to be cross-platform, so they would either require a compiler
> to be built into the POV application, or they would need to be in a
> byte-code format similar to the way Java is done. Both would be slower
> than a fully optimized compiled version for each platform. If you want
> to modify POV, the best choice is to download the source and make an
> unofficial patch.
This one would be difficult... if not impossible, but I was thinking
something like.. you can have a patch/plugin fetcher that connect to a
plugin site, and allows you to download any plugin you want, and install
it. you could have different channels for different types of patches AND
platforms, so you only get ones available to your platform...
> And what do you mean by "helix-code update"?
>
if your a linux fan, them you know what gnome is, helix-code is
basically gnome with alot of extras, one of which is an updater that
fetches new patchs/releases/extras and has multiple channels. I've been
told M$ has something similar now,win-update or something..
> > 5. multiple cameras, why can't I define 10 cameras in one scene, and
> > then say, pov.renderer.trace_scene(POVCamera camera)
>
> Umm, where would this line go? In the scene file? I think it would be
> better to stick to the current way of doing it. You can already declare
> multiple cameras and decide which one to use...
>
I haven't tried any animations yet, I didn't realize you could have more
than one camera,.. but I think it would be cool to create multiple
cameras, each with a name(like "ViewFromSky") and then say
trace_scene(scene, getCamera(scene, "ViewFromSky")
> > 6. why not give each object, including group objects, and cameras a
> > name, so it can be easily referenced later(so it can be removed, moved,
> > scaled, change properties like color...(animator's might like this;>)
>
> You can already make a variable, a separate label simply complicates
> things and is inconsistant.
>
Imagine you have a virtual dog, if you have names for everything, you
could say: translate (dog.front_left_leg, control_point_2, <0,0,0>), to
move objects, and subobjects arbitrary.
> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
>
> <><
these are just ideas, apparently not even good ones... the only reason
I'm even interested in povray is because its the best damn raytracer
I've seen yet! and it's flaws are more than made up for by what it can
do. I am a fan/supporter of the open-source community and wish to see
povray become a raytracer that everyone wants to use(over commercial
crap)..
pleas edont be offended by anything I say, I didn't mean to criticize
povray..
Abe
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <399DAE0A.2AC32A30@vrml.k12.la.us>, Abe Heckenbach
<abe### [at] vrmlk12laus> wrote:
> sorry, my mistake, I was thinking that a union could only be used for
> objects physically connected, and that it would be nice to be able to
> manipulate a group of objects as one, with out changing the final
> image..(though I guess image mapping might look different).
Image mapping and texturing would be exactly the same.
> I meant for animations, interactive 3d, ect. where you would want to
> change objects arbitrarily from any point, like switching a virtual
> light switch to remove(or just make invalid) a light source, for
> example.
The best way(in my opinion, the right way) to do this is to use
persistant *variables* that are added to the scene each frame. The scene
would be cleared each frame, so you wouldn't see any difference, but the
code would be simpler(you wouldn't have to make sure you aren't
duplicating an object already in the scene), and there isn't as much of
a problem of different incompatible ways of referring to an object.
> there are over 20,000 messages in this newsgroups, so there is no way I
> could just read them all to see if the topic had been discussed.
Specifically, search in povray.general and the more recent discussions
in povray.programming.
> I really think this is an important thing to have, it allows it to be
> very versatile and modular, and independent of application, one
> person might want to used it to render a singe frame, another might
> want to take his hand at a movie :),
You can already use POV for both stills and movies...
> (I have a lot of ideas with raytracing that would be alot easier to
> try if it was like this, for right now I'm actually writing my own
> ray tracer because it easier than making changes all across what like
> 90,000 lines of code that povray currently is!!
What are these ideas that require a new raytracer? What changes would
you have to make in order to use a scene file that an API wouldn't
require?
These are the usual arguments for an API, some of the arguments against
it are:
It isn't needed, you can already access all of POV's features through
the scene description language.
It isn't cross-platform, you would have to write different code to
expose these APIs for every port.
It makes it less obvious to the user that POV is the program doing the
work.
Some of the platforms(Mac and Windows) already have limited API's,
basically enough to tell POV to render a specific scene with certain
settings, and this is all that is necessary. Also, it doesn't belong as
a core feature, but a platform-specific feature.
BTW, good luck on your raytracer...I hope you release the source(and if
you do, that you keep platform dependant code isolated from the rest of
the code). :-)
> huh?? I don't know what you mean by that. if you provide a platform
> independent method called trace_scene(POVScene,POVCamera), any other
> c/c++ program can call it and do what every it wants with it(likely
> platform specific like some kind of gui.)
No. You have to go through special work to allow other programs to use
the function...and there isn't a platform independant way to do this.
> This one would be difficult... if not impossible, but I was thinking
> something like.. you can have a patch/plugin fetcher that connect to a
> plugin site, and allows you to download any plugin you want, and install
> it. you could have different channels for different types of patches AND
> platforms, so you only get ones available to your platform...
Making POV-Ray dependant on an internet connection? No thanks...
And it still has the problems of accessing the plugins in a
cross-platform way, speed, etc.
> if your a linux fan, them you know what gnome is, helix-code is
> basically gnome with alot of extras, one of which is an updater that
> fetches new patchs/releases/extras and has multiple channels. I've been
> told M$ has something similar now,win-update or something..
I'm interested in Linux, but I don't have much experience with it, and
haven't heard about this. I wouldn't know about any M$ project
either...I don't use Windows. Look at my headers, e-mail address, and
web site. :-)
> I haven't tried any animations yet, I didn't realize you could have more
> than one camera,.. but I think it would be cool to create multiple
> cameras, each with a name(like "ViewFromSky") and then say
> trace_scene(scene, getCamera(scene, "ViewFromSky")
#declare ViewFromSky = camera {...}
#declare ViewFromGround = camera {...}
...
camera {ViewFromSky}
Or do you mean rendering more than one image at once?
I think the .pov file should stick to scene description as much as
possible...but maybe another type of file could be useful...something
more friendly and powerful than .ini files, which controls the rendering
process, and can pass information to the POV file through variables.
> Imagine you have a virtual dog, if you have names for everything, you
> could say: translate (dog.front_left_leg, control_point_2, <0,0,0>), to
> move objects, and subobjects arbitrary.
How does this conflict with using a variable?
#declare Dog =
object {...
members {
#declare FrontLeftLeg = object {...};
#declare ControlPoint2 = < 0, 1, 2>;
#macro GetCurrentState() ... #end
}
};
Dog.FrontLeftLeg.translate(...);
#set Dog.ControlPoint2 = vtransform(Dog.ControlPoint2, ...);
object {Dog.GetCurrentState()}
Notice the #set command...this is just something I think should be
added, it would only modify existing variables and would not create a
new one. I have had many times when this would make things easier to
read and prevent a bug or two...oh, and the vtransform() function is
something new in MegaPOV. The GetCurrentState() macro would take the
current condition of the dog and return a union object.
The members{...} block would be to retain backwards compatability...you
can already place declarations within objects, having them suddenly
become members of the object in the new version wouldn't be very
user-friendly. :-)
> these are just ideas, apparently not even good ones... the only reason
> I'm even interested in povray is because its the best damn raytracer
> I've seen yet! and it's flaws are more than made up for by what it can
> do. I am a fan/supporter of the open-source community and wish to see
> povray become a raytracer that everyone wants to use(over commercial
> crap)..
Your ideas are not "crap"...I doubt anyone will know what OOPOV will
look like until it actually exists. :-)
BTW, POV-Ray is *not* open source, though that seems to be a common
misconception...the main difference is in the licensing. The POV-Team
wishes to keep more control over their work than open-sourcing would
allow, which they have every right to. They do make the source available
and allow distribution of modified versions, though, so they (and the
community) get some of the same benefits of open source without many of
its problems.
--
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 <399DAE0A.2AC32A30@vrml.k12.la.us> , Abe Heckenbach
<abe### [at] vrmlk12laus> wrote:
> huh?? I don't know what you mean by that. if you provide a platform
> independent method called trace_scene(POVScene,POVCamera), any other
> c/c++ program can call it and do what every it wants with it(likely
> platform specific like some kind of gui.)
No, it is not. Different platforms have different methods of making
functions available to outside programs. This usually requires changing the
source code in some way. One simple change might be that all the compiler
requires is an compiler specific option to export, i.e. something line
"#export on". But it might also require some special conventions to
overcome the way how different compilers manage function calls, i.e. the
'popular' "CDECL" declaration of functions...
To make it short, neither the C nor the C++ standard says anything about
making functions available to outside programs. In consequence, there is no
standard way to make extern function calls cross-platform easily. *
Thorsten
* Yes, there are some frameworks that try to overcome this, but this is not
the point here - they are not available anywhere (unlike a good C compiler)!
____________________________________________________
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 povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
:> Perhaps the best name would be "is_a".
: Errr...it's not what type of relation it is...it's what the keyword in OO-POV should
be!
: I know it's an "is a"-relation - just sketching on a suggestion for new syntax! :-)
Well, what would be better keyword that one that describes the type of
relation it computes?
: and I guess many
: users would be irritated if they got an error saying "Not strictly correct OO used
at
: line nnn" while parsing?
Well, they may get irritated, but in my opinion is better to teach correct
OO programming from the very beginning than trying to correct bad habits
afterwards :)
: AND - POV-Ray has always been known for it's flexible and
: (rather) forgiving syntax - let's keep it that way.
Well, C++ is very flexible and forgiving. I like C++ because of that, but
it has the bad concecuence of teaching bad habit to beginners :)
And I'm not saying that povray's syntax should be stricter. I really like
the fact that I can write this:
light_source { <1,2,3>, rgb <1,1,1> }
this:
light_source { <1,2,3>, <1,1,1> }
or this:
light_source { <1,2,3>1 }
or even this:
light_source { x+y*2+z*3, x }
--
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 povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: Location, as I thought of it, should be one of the common attributes for all
: objects. Think java again:
: public virtual class POVOBJECT{
: public povVector location, rotation;
: }
Now you forget one thing: That takes memory. And povray is not very well
known when speaking about low memory consumption. Let's not make the matter
even worse.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Abe Heckenbach" <abe### [at] vrmlk12laus> wrote...
> If interested here are some of my thoughts on features for the pov4.0
> c++
> release:
In my opinion, you have a lot of good ideas. In fact, many of them have
even been discussed by the POV-Team already. Unfortunately, most of them
would be quite difficult, if not currently impossible, to implement in way
that keeps POV platform independent. However, that doesn't mean that we
should give up on these ideas. But for now we (the POV-Team members) need
to focus our efforts on POV 3.5. If members of the POV community want to
research these topics and do some testing, that would be great. When we get
to work on POV 4.0, I would be interested in knowing what you all find out.
Disclaimer: I speak for myself as a member of the POV-Team, but not on
behalf of the Team.
-Nathan Kopp
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
