Spider jumps in. Decloaked.

Ok, I've kept myself out of this thread too long .-)

Actually, some very good ideas has come, but the OO scripting is one oof my
favourites(and translucency:-)

Here goes.


Roland Mas wrote:
> 
> Mikael Carneholm <sa9### [at] idautbhbse> writes:
> 
> > This is already pretty close to OO scripting!  (SomeSphere is the
> > "class" and it is instanced with object{})
> 
> Sure.  Why change that?
Good.

 
> > Now, what we can't do with the current version is this:
> >
> > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> 
> #declare SomeSphere = object { SomeSphere translate y }
> Does exactly it.
Sure, but you can't do 
#declare SomeSphere.position.y = SomeSphere.position.x;
#declare SomeSphere.position.x = SomeSphere.position.z;

without a biiig hazzle.
 

> > #declare SomeSphere.radius=1.5;
> 
> I'm not sure it really cannot be done.
yes, but to change an objects propertised based on it's current properties.
that's where the OO mode will come in as a GREAT aid.
 
> > #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};
> 
> #declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
> Does exactly it.
yes, but if I want a nifty shader done on the object depending on its position?
That would turn out pretty nasty(Sure, use a texture, but that woudln't suit in
all cases. (ie. the whole objects pigment depends on it y value(gradient y) )
 
> Anyway, what's the use of all that?  Want to have another sphere,
> redeclare it.  Or better, if it's another sphere, use another object.
It's not another sphere. It's the SAME sphere. That's the point with oo. 


> --
>                                                          Roland Mas

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Spider <spi### [at] bahnhofse> writes:

> > > Now, what we can't do with the current version is this:
> > >
> > > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> > 
> > #declare SomeSphere = object { SomeSphere translate y }
> > Does exactly it.
> Sure, but you can't do 
> #declare SomeSphere.position.y = SomeSphere.position.x;
> #declare SomeSphere.position.x = SomeSphere.position.z;

True, even if I can't see the use of such a thing.

> yes, but if I want a nifty shader done on the object depending on
> its position?  That would turn out pretty nasty(Sure, use a texture,
> but that woudln't suit in all cases. (ie. the whole objects pigment
> depends on it y value(gradient y) )

I'm afraid I don't understand that sentence.

> > Anyway, what's the use of all that?  Want to have another sphere,
> > redeclare it.  Or better, if it's another sphere, use another object.
> It's not another sphere. It's the SAME sphere. That's the point with
> oo. 

If it's the same, why did you declare it wrongly in the first place?
Declare it with the correct parameters...
-- 
Roland Mas

It would be hard to be deader without special training.
  -- Theatre of Cruelty (Terry Pratchett)

Post a reply to this message

On Wed, 14 Apr 1999 14:05:41 +0200, Spider <spi### [at] bahnhofse> wrote:
>> > Now, what we can't do with the current version is this:
>> >
>> > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>> 
>> #declare SomeSphere = object { SomeSphere translate y }
>> Does exactly it.
>Sure, but you can't do 
>#declare SomeSphere.position.y = SomeSphere.position.x;
>#declare SomeSphere.position.x = SomeSphere.position.z;
>
>without a biiig hazzle.

I've said it before and I'll say it again: if you need access
to the position of the sphere, put it in a variable when you know
it, then use the variable later.  Yes, this is simplistic.  Yes,
it's not as sexy as having lots of dots (the most-used word of 1997
was dot, after all.)

>> Anyway, what's the use of all that?  Want to have another sphere,
>> redeclare it.  Or better, if it's another sphere, use another object.
>It's not another sphere. It's the SAME sphere. That's the point with oo. 

There's no use to moving the spheres around unless you have the ability 
to save the scene for use in the next frame.  If that's what you want
to do, you already have semi-persistent variables with the read/write 
stuff, though in principle I'm opposed to persistent variables anyway, 
since they sorta kill any scalability-across-a-network an animation 
might have had.

Post a reply to this message

Roland Mas wrote:
Ok, here I go again :-)
 
> Spider <spi### [at] bahnhofse> writes:
> 
> > > > Now, what we can't do with the current version is this:
> > > >
> > > > #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
> > >
> > > #declare SomeSphere = object { SomeSphere translate y }
> > > Does exactly it.
> > Sure, but you can't do
> > #declare SomeSphere.position.y = SomeSphere.position.x;
> > #declare SomeSphere.position.x = SomeSphere.position.z;
> 
> True, even if I can't see the use of such a thing.
Ok, but it was the point that was meant. The possibility to access an objects
current position without having to use a variable for each value. I know I am
lazy, but I still want to be able to do this:
light_source {
  location camera.location
  colour rgb 1
  shadowless
  spotlight
  point_at camera.look_at
  radius...
}
Without declaring the variables 
#declare scCameraLocation = <-1200, 105, 1000>;
#declare scCameralookAt = <...>;

and so on..

And the other places it would be nice in can be a include file accessing the
camera postition for placing items, (like a lens-flare) as well as light_sources
positions. (now here is a hazzle, how to access the RIGHT light_source ? add
them in an array? Give them a name identifier?

> > yes, but if I want a nifty shader done on the object depending on
> > its position?  That would turn out pretty nasty(Sure, use a texture,
> > but that woudln't suit in all cases. (ie. the whole objects pigment
> > depends on it y value(gradient y) )
> I'm afraid I don't understand that sentence.
If you take a look at my world macro, the boxes have an height value. 
if I take  this a few steps further, and want to give more objects a pigment
depending on the distance from the camera, I'd either have to declare all the
object points in variables(arrays) or start adding vlength(pos-campos)
everywhere. This is just one use that hits me now.

> 
> > > Anyway, what's the use of all that?  Want to have another sphere,
> > > redeclare it.  Or better, if it's another sphere, use another object.
> > It's not another sphere. It's the SAME sphere. That's the point with
> > oo.
> 
> If it's the same, why did you declare it wrongly in the first place?
> Declare it with the correct parameters...
But that's the nasty point...
It may not be possible to do so at all, but to have to go with #declares, yes.
say I want to use simpsons method to integrate a point on a curve. (it's a
recursive algorithm, using the last values for computing) 
just one idea for use.

-- 
//Spider
        [ spi### [at] bahnhofse ]-[ http://www.bahnhof.se/~spider/ ]
What I can do and what I could do, I just don't know anymore
                "Marian"
        By: "Sisters Of Mercy"

Post a reply to this message

Ronald L. Parker wrote in message >Someone else obviously is... see
>http://www.gnu.org/software/panorama/panorama.html
>

I agree wholly about the compatibility issue. Panorama might be the greatest
raytracer in the world, but as it uses a completely different scene
language, I cannot use ANY POV-Ray code/macro/snippet etc... so this ends
the question.

About the syntax issue: one might preprocess an OO scene language into the
POV-Ray one, adding a new language without harning back compatability. By
the way, C++ started just a C preprocessor. When the raytracing community
eventually settles on a POV-Ray++ language (you heard it here first ;-)  )
then it can be embedded in the official program.

In the past i have written posting which have generated quite a good deal of
flames. I was not meaning to steal anybody code (I am a programmer and I do
not like thieves) or messing around. I was proposing extensions which might
give raise to improvements WITHIN the overall accepted framework of POV.

a.c### [at] iolit

Post a reply to this message

On Tue, 27 Apr 1999 12:10:11 +0200, Alessandro Coppo <a.c### [at] iolit> wrote:
>
>Ronald L. Parker wrote in message >Someone else obviously is... see
>>http://www.gnu.org/software/panorama/panorama.html
>>
>
>I agree wholly about the compatibility issue. Panorama might be the greatest
>raytracer in the world, but as it uses a completely different scene
>language, I cannot use ANY POV-Ray code/macro/snippet etc... so this ends
>the question.

You must have missed the part where it mentioned that someone is writing
a POV-script frontend for it.

Post a reply to this message

Spider wrote:

> Ok, but it was the point that was meant. The possibility to access an objects
> current position without having to use a variable for each value. I know I am
> lazy, but I still want to be able to do this:
> light_source {
>   location camera.location
>   colour rgb 1
>   shadowless
>   spotlight
>   point_at camera.look_at
>   radius...
> }
> Without declaring the variables
> #declare scCameraLocation = <-1200, 105, 1000>;
> #declare scCameralookAt = <...>;

> and so on..

Nice to see someone else who has realised the usefulness of OO scripting. As I said:
what I miss most when writing include files for POV-Ray, is the possibility to
access attributes of different objects like the camera, a lightsource or whatever.
What's more, I'd like to be able to access the current frame number, the initial
clock, the final clock etc - i.e, all the INI file settings. So I think a keyword
for the next version of POV would be 'accessible' as in 'all attributes are now
accessible'.

- Mikael.

-----------------------------------------------------------------
Mikael Carneholm
Dep. of Computer Science


http://www.studenter.hb.se/~arch
E-mail: sa9### [at] idautbhbse

Post a reply to this message

Attachments:
Download 'us-ascii' (1 KB)

Ron Parker wrote in message <3725e41b.0@news.povray.org>...
>You must have missed the part where it mentioned that someone is writing
>a POV-script frontend for it.

From what I know, the real problem is that Panorama engine does not support
many features of POV e.g. I think that there is nothing comparable to all
the media bells and whistles (VERY beatiful and VERY slow).

Anyway, I again advise NOT to select a new language for version 4 but to
experiment with preprocessors and frontends. When there will be a general
agreement, add the new language.

Alessandro Coppo
a.c### [at] iolit

Post a reply to this message

On 13 Apr 1999 18:57:55 +0200, rol### [at] casimirrezelenstfr (Roland
Mas) wrote:

>Mikael Carneholm <sa9### [at] idautbhbse> writes:
>
>> This is already pretty close to OO scripting!  (SomeSphere is the
>> "class" and it is instanced with object{})
>
>Sure.  Why change that?

?? Surely the scripting in POV 3.1 is pretty similar to that in 3.0,
or even the first version of POV scripting. why did they change it? To
improve on it's functionality.

>> Now, what we can't do with the current version is this:
>> 
>> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>
>#declare SomeSphere = object { SomeSphere translate y }
>Does exactly it.

Not quite, I suspect. Isuspect the OOP example would change the
position property of the pre-defined object "SomeSphere" (which could
of course consist of googillions of sphere and/or other objects rather
than just 1 sphere) rather than creating a new object. Where memory is
tight or the object complex (or both) it might well be preferable to
adjust the properties of the object rather than declaring a whole new
object, or keeping texture, location, object etc. etc. seperate and
only combining them at "object placement time" (far more complex and
liable to user error IMO).

>> #declare SomeSphere.radius=1.5;
>
>I'm not sure it really cannot be done.

As long as the SomeSphere object is just a single sphere, seems easy
enough to do in POV script as is.

>> #declare SomeSphere.pigment=pigment{color rgb<0,0,1>};
>
>#declare SomeSphere = object { SomeSphere pigment{color rgb<0,0,1>} }
>Does exactly it.

Again, I could be wrong but I suspect the OOP line is modifying the
properties of an existing object where you are specifying how to
create an object with such-and-so properties (providing, IIRC, that it
isn't already textured/coloured).

>Anyway, what's the use of all that?  Want to have another sphere,
>redeclare it.  Or better, if it's another sphere, use another object.

Not necessarily ideal. Take making an asteroid out hundreds of
randomly jittered sperical blob components as an example. Simly
adjusting the texture might make a cloud of asteroids easier to do
than re-declaring each asteroid - especially if (for any reason) each
asteroid is meant to be identical in actual shape (oh it can be done -
but tedious for the modeller and computer alike).

Pov already has some dot notation. I'm not particularly familiar with
the POV scene description language, or very adept with it, but I'm
sure I've seen .x, .y, and .z used to retreive co-ordinate
information. What's the political argument against extending this
(already present) style of object data access?


Cheers,

Cliff Bowman
Why not pay my 3D Dr Who site a visit at
http://www.geocities.com/Area51/Dimension/7855/
PS change ".duffnet" to ".net" if replying via e-mail

Post a reply to this message

On Wed, 12 May 1999 18:26:41 GMT, Cliff Bowman wrote:

>>> #declare SomeSphere.position=SomeSphere.position+<0,1,0>;
>>
>>#declare SomeSphere = object { SomeSphere translate y }
>>Does exactly it.
>
>Not quite, I suspect. Isuspect the OOP example would change the
>.position property of the pre-defined object "SomeSphere" 

...

>it might well be preferable to
>adjust the properties of the object rather than declaring a whole new
>object

You're not declaring a whole new object.  Since you're putting it in
the same place, the old one gets destroyed and the new one takes its
place.  The only thing that might be optimized better is the fact that
while the object {...} block is open, there are two copies of the object
in memory.


>Not necessarily ideal. Take making an asteroid out hundreds of
>randomly jittered sperical blob components as an example. Simly
>adjusting the texture might make a cloud of asteroids easier to do
>than re-declaring each asteroid - especially if (for any reason) each
>asteroid is meant to be identical in actual shape (oh it can be done -
>but tedious for the modeller and computer alike).

For this were macros invented.

Post a reply to this message