|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello,
just an idea: imagine, that POV language is object-oriented,
so for example sphere can be defined something like:
Sph1=sphere;
Sph1 < rad(1) < cen(<0, 0, 0>;
CSG:
Union1=union < add(Sph1) < add(Sph2);
Global settings:
global_settings < radiosity(on) < background (rgb .5);
'<' means 'send messasge to object'.
Inheritance can be great for making complex custom object,
with they own functionality,
for example beam object, which is able to place itself
between some two points as abstract class and his descendants
with particular shapes, then I can use all beams in place
where I need beams a there is no necessity to make some
#switches.
Any ideas?
Regards
Disnel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vaclav Cermak wrote:
>
> Hello,
>
> just an idea: imagine, that POV language is object-oriented,
This is probably one of the most discussed subject ever in
these groups. I'll suggest you to take a look at the numerous
past discussions about the idea of making POV-Ray's language
more object-oriented.
Fabien.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Fabien already answered you.
I would like to add that although object orientedness would be wonderful
from the point of view of a hardcore programmer (like myself), it would be
of little use to the average user who knows little or nothing about
programming (who are still fighting on understanding how #while-loops and
#macros work...).
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Vaclav Cermak wrote:
>
> just an idea: imagine, that POV language is object-oriented,
> so for example sphere can be defined something like:
Will it render faster?
Will it parse faster?
If not, forget it.
Regards,
John
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <39747AD8.E2567B43@itam.cas.cz>, Vaclav Cermak
<dis### [at] itamcascz> wrote:
> just an idea: imagine, that POV language is object-oriented,
> so for example sphere can be defined something like:
...
> Any ideas?
This has been discussed many times, you might want to look at those
discussions. There was one big one which started out in povray.general.
The biggest problem with your syntax is that it would require a complete
redesign of the POV language, and everyone would have to re-learn it.
This isn't necessary, object-oriented features could be added to the
existing language, and still support old scenes and people writing in
the older style. For one thing, the dot operator is already used to
access the components of vectors and colors, it makes sense to use it to
access member variables and macros. Much more sense than to use the
"less than" operator.
A form of inheritance could be done by having every copy of an object
get independant copies of its parent's members.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <3975A3CF.43674EB9@erols.com>, John VanSickle
<van### [at] erolscom> wrote:
> Will it render faster?
Of course not, it is part of the language.
> Will it parse faster?
Well, the complete rewrite that this particular syntax would require
could easily lead to a much faster parser. Just don't forget about the
fact that a rewrite is already planned. :-)
> If not, forget it.
You seem to have forgotten about ease of use. On the one side, speed is
irrelevant if only a few people can or will use it. On the other, many
things would be much easier/more efficient with some object-oriented
features. It is possible to add these features without forcing everyone
to re-learn the language.
--
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
An idea:
Have a constructor for each object that will initialize it with the
necessary properties.
sphere ballA(<0,1,0>,1);
The object could contain other objects for texturing and have member
functions for transformations.
ballA.finish.specular = 1;
ballA.translate(<0,0,10>);
The destructor could make the object go out of scope so that other
objects could reuse the destructed object's name.
~ballA();
It looks like a total redesign. %-\
Brendan
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Tue, 18 Jul 2000 17:42:16 +0200, Vaclav Cermak wrote:
> just an idea: imagine, that POV language is object-oriented,
> so for example sphere can be defined something like:
[...]
> Any ideas?
The povray scene language is good, because it can be used by professionals as
well as amateurs. Object-orienting things will probably need to break
backward compatability somewhere, and only a handfull of users will actually
understand the benefits of the new OO language.
However; No one has said that you, me, anyone can't write a Pov++ language
which can be "compiled" to simple .pov files. The output pov-source will
probably look horrible, but what the heck.. :-)
/j
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> This has been discussed many times, you might want to look at those
> discussions. There was one big one which started out in povray.general.
I readed something from this very, very long thread.
I remember some ideas from it:
1) Possibility to give a name to object and then use dot operator, like:
sphere {
name "Sphere1"
...
}
....
Sphere1.texture= ....
Persistent animations can be done with it, for example:
Sphere1.persistent=yes
and in next frame:
Sphere1.translate(<somewhere>}
or
Sphere1.delete()
It has backwards compatibility, my first idea not.....
2) No one talked about virtual methods, although its big advantage, I
think.
3) XLM is good idea for sharing POV scene with modellers, converters and
so on, but I think that is very unfortunate for hand-coding.
4) Interesting idea of breaking POV into two parts: parser and renderer,
then can be simply parser for actual POV language, parser for XML...
If we enlarge this concet, an XML emitor can be connected to parser
instead of renderer, for example.
> A form of inheritance could be done by having every copy of an object
> get independant copies of its parent's members
This is true when you don't allow changing objects after they have been
parsed, but I think, that can be one great advantage, mainly in
persistent animations.
Regards
Disnel
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
John VanSickle <van### [at] erolscom> wrote:
: Will it parse faster?
: If not, forget it.
Oh, so then we should remove #while-loops, #macros and even #defines. They
only slow parsing, don't they?
--
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |