 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <397F0286.85776D5C@itam.cas.cz>, Disnel <dis### [at] itam cascz>
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
Personal homepage:
http://www.studenter.hb.se/~arch
E-mail:
sa9### [at] idautbhbse
Post a reply to this message
|
|
| |
| |
|
|
From: Matthew Webster
Subject: Re: Object oriented POV scene language?
Date: 26 Oct 2000 17:11:20
Message: <39f89df8@news.povray.org>
|
|
|
| |
| |
|
|
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
|
|
| |
| |
|
|
|
|
| |
|
|
