|
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <Xns94937169A2BACseed7@news.povray.org>,
ingo <ing### [at] tagpovrayorg> wrote:
> If I want to read and understand those future OO-scenefiles, I'll have to
> learn the new features. "Use" is more than just writing scenes.
And reading and understanding the ugly, complex hacks used to work
around the lack of object oriented features would be easier?
--
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
andrel wrote:
> is better left out. At this point I cannot judge very well because I
> still have no good perception of how an OOPOV would look, but perhaps
There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tom Melly <pov### [at] tomandlucouk> wrote:
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
If it were solely up to me, it would look as much as C++ as possible.
However, it's not up to me. (Fortunately? ;) )
--
#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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tom Melly" <pov### [at] tomandlucouk> wrote in message
news:4033cd07@news.povray.org...
> andrel wrote:
>
> > is better left out. At this point I cannot judge very well because I
> > still have no good perception of how an OOPOV would look, but perhaps
>
> There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
object ColoredSphere (v, c) inherits Sphere
{
pigment
{
color = c
}
}
object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))
show red_sphere
show green_sphere
Off the top of my head, I could see this being useful. You could also do
this:
red_sphere.pigment.color = new Color.White
which you can't do right now.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
cja### [at] earthlinknet says...
> In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> wrote:
>
> > Not me. It would add another layer of complexity that I don't want to have
> > to bother to learn. OO is for programming not a scene description language.
> > If I wanted to learn programming I would do that rather than using POV-Ray.
>
> You only say that because you don't know what it would add. It would not
> add complexity, it would greatly simplify many things.
>
>
I am seriously confused about what it would simplify... SDL already does
most everything that OO stuff can. The one and only thing I can think of
is the ability to over-ride specific attributes, the way you can replace
an existing function in an object with a new one:
#define Motorcycle1 = object {Motorcycle}
object {
Motorcycle1 {
#replace Motorcycle1.Handlebars.texture{blah....}
}
}
So you could start with an entirely prebuilt object and change any single
item in it by directly replacing that item. However, for it to work, each
individual object would need a unique name or you would need to have some
way to index which of the objects in a CSG you are applying the changes
to or adding/removing.
Is the above sort of what you are talking about? Because otherwise I
don't get what OO feature you are talking about that the SDL doesn't
already support in some fashion...
--
void main () {
call functional_code()
else
call crash_windows();
}
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P wrote:
> "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> news:4033cd07@news.povray.org...
>
>>andrel wrote:
>>
>>
>>>is better left out. At this point I cannot judge very well because I
>>>still have no good perception of how an OOPOV would look, but perhaps
>>
>>There's a challenge... Warp? What would, IYHO, a bit of Pov-OO look like?
>
>
> I'm sorry; I know you didn't ask me. I have some ideas of how it could look:
>
>
> object ColoredSphere (v, c) inherits Sphere
> {
> pigment
> {
> color = c
> }
> }
>
> object red_sphere = new ColoredSphere (<1, -2, 3>, new Color(1, 0, 0))
> object green_sphere = new ColoredSphere (<2, -2, 3>, new Color(0, 1, 0))
>
> show red_sphere
> show green_sphere
I do not see why the current syntax with macros does not suffice here.
>
> Off the top of my head, I could see this being useful. You could also do
> this:
>
> red_sphere.pigment.color = new Color.White
Well if it allows you to have an object that is called red_sphere but
is actually white then we are in deep trouble.
Just kidding, I understand what you mean. My first reaction would be
that pigments can be much more complicated than just a simple color.
That is what POV makes exciting. I do not immediately see how you can
handle that complexity in a understandable way. I will think about that
(later).
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Christopher James Huff" <cja### [at] earthlinknet> wrote
> In article <Xns94937169A2BACseed7@news.povray.org>,
> ingo <ing### [at] tagpovrayorg> wrote:
>
> > If I want to read and understand those future OO-scenefiles, I'll have to
> > learn the new features. "Use" is more than just writing scenes.
>
> And reading and understanding the ugly, complex hacks used to work
> around the lack of object oriented features would be easier?
Or understanding entries to the short code contest? ;)
But seriously, I've seen plenty of scene files where I don't have a clue what's
happening, like where they use some feature of pov that I've never seen before.
Sometimes I think it's worth reading the manual to find out what it does,
sometimes I decide I'd rather not know. I don't think OO would make this much
worse.
Though I do think OO would run the risk of getting too far away from the SDL
being a language to describe scenes (objects that are conceptual not visible!?).
--
Tek
www.evilsuperbrain.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I think there's a lot of confusion between OO objects and pov's object {}. I
never intended for the two to be the same thing.
What I need for my scene is the concept of a data structure which can hold a
series of "function" calls (actually macro calls) according to what type of
structure it is. It does not need to be associated with anything renderable.
This just extends the range of possibilities for how pov's macro language can be
used to perform calculations or procedural scene generation, etc.
I can see some uses for having OO objects associated with pov objects, but I
think it would REALLY defeat the point if you are forced to have that
association. For example, you could create a tree using an object that creeps
along the trunk, leaving a trail of spheres, then spawns another object for each
branch, etc... so there would be many more spheres than there are OO objects.
Anyway, just my 2 cents. I'm gonna get on and write my macros :)
--
Tek
www.evilsuperbrain.com
"Patrick Elliott" <sha### [at] hotmailcom> wrote in message
news:MPG.1a9d8de2d9dc8dc39899ad@news.povray.org...
> In article <cjameshuff-9D70B1.13425418022004@news.povray.org>,
> cja### [at] earthlinknet says...
> > In article <4032CB5A.9277B9BA@pacbell.net>, Ken <tyl### [at] pacbellnet>
> > wrote:
> >
> > > Not me. It would add another layer of complexity that I don't want to have
> > > to bother to learn. OO is for programming not a scene description
language.
> > > If I wanted to learn programming I would do that rather than using
POV-Ray.
> >
> > You only say that because you don't know what it would add. It would not
> > add complexity, it would greatly simplify many things.
> >
> >
>
> I am seriously confused about what it would simplify... SDL already does
> most everything that OO stuff can. The one and only thing I can think of
> is the ability to over-ride specific attributes, the way you can replace
> an existing function in an object with a new one:
>
> #define Motorcycle1 = object {Motorcycle}
>
> object {
> Motorcycle1 {
> #replace Motorcycle1.Handlebars.texture{blah....}
> }
> }
>
> So you could start with an entirely prebuilt object and change any single
> item in it by directly replacing that item. However, for it to work, each
> individual object would need a unique name or you would need to have some
> way to index which of the objects in a CSG you are applying the changes
> to or adding/removing.
>
> Is the above sort of what you are talking about? Because otherwise I
> don't get what OO feature you are talking about that the SDL doesn't
> already support in some fashion...
>
> --
> void main () {
> call functional_code()
> else
> call crash_windows();
> }
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"andrel" <a_l### [at] hotmailcom> wrote in message
news:403### [at] hotmailcom...
>
> > "Tom Melly" <pov### [at] tomandlucouk> wrote in message
> > news:4033cd07@news.povray.org...
<snip />
> > red_sphere.pigment.color = new Color.White
> Well if it allows you to have an object that is called red_sphere but
> is actually white then we are in deep trouble.
Heheh :-)
> Just kidding, I understand what you mean. My first reaction would be
> that pigments can be much more complicated than just a simple color.
> That is what POV makes exciting. I do not immediately see how you can
> handle that complexity in a understandable way. I will think about that
> (later).
Could do red_sphere.pigment.image_map.file and stuff too. Any level of
indirection. OO gives smarter people than I the ability to do things I'd
never dream of with it. The more flexible the code can be, the more people
will find ways to do new, interesting stuff.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan P <dan### [at] yahoocom> wrote:
> new ColoredSphere
> new ColoredSphere
> new Color.White
Aaargh! No, no and no.
The fact that you must fill your code with the 'new' keyword in Java does
not mean it's a good thing.
Why force the user to do that? In all those cases the 'new' keyword is
obsolete. It contributes nothing to the code.
--
#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
|
|
| |
| |
|
|
|
|
| |
|
|