One thing I've been thinking of that could make some things easier (for
beginners as well as for advanced users) is a new object type: a point
object.

syntax is POINT{[POINT IDENTIFIER][POINT LOCATION]}

..where the point identifier is used to name the object for future
reference.

"Why?" some might say - well here's an example:

I made a demo scene for my smoke generation macro, consisting of a
rotating cube with 8 smoke sources (one in each corner). This is how it
could have been done (if there was such an object):

union{
  RoundedCubeObject
  point{point1,<1,1,1>}
  point{point2,<1,1,-1>}
  point{point3,<-1,1,-1>}
  point{point4,<-1,1,1>}
  point{point5,<1,-1,1>}
  point{point6,<1,-1,-1>}
  point{point7,<-1,-1,-1>}
  point{point8,<-1,-1,1>}
  rotate <clock*360,clock*360,clock*360> // affects the point objects as
well
}

With a little OO thrown in, it would then be possible to do this:

#declare obj_pos=point1.location;
#include "SmokeGen.inc"

#declare obj_pos=point2.location;
#include "SmokeGen.inc"

--

#declare obj_pos=point8.location;
#include "SmokeGen.inc"

This way, you don't have to deal with math(which I believe keeps some
users from using POV today).

Instead, I had to make a vector array where the vectors are redeclared
using a rotation identifier and also use vrotate() (which I don't mind
using but beginners might have a hard time using). Quite messy.

Comments?

- 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)

A few weeks ago I almost made a similiar suggestion for a different reason.  I
didn't post it for some reason, not sure why though.

I was going to comment that a point primitive would be a very useful object
for use in meshes and bicubic patches.  We really need something there that
can accept transformations.

This was to compliment a new way of tranforming object; bones.  A bone would
have a start (pivot point) and an end point.  Objects attached to the bone
would inherit it's transformations.  A bone would typically be declared at the
beginning of a scene, then used multiple times on point primitives.

If this sounds stupid, think about this - you have 1000 points that change
rotation and position 100 times over the course of an animation.  They all
rotate and translate the same way, but you need to do specify the same
tranforms for each one, meaning the scene file must contain a million
transformations!

I suppose the same thing could be handled using strings, but I think this is a
lot easier.  It certainly would be nice if there was a way for some quality
animations programs had an easy route to converting to the POV-Ray format.

I'll admit that I haven't thought it all through yet, but you seem to have a
similiar idea, so I thought I'd just throw this one out there.

-Mike

Mikael Carneholm wrote:

> One thing I've been thinking of that could make some things easier (for
> beginners as well as for advanced users) is a new object type: a point
> object.
>
> syntax is POINT{[POINT IDENTIFIER][POINT LOCATION]}
>
> ..where the point identifier is used to name the object for future
> reference.
>
> "Why?" some might say - well here's an example:
>
> I made a demo scene for my smoke generation macro, consisting of a
> rotating cube with 8 smoke sources (one in each corner). This is how it
> could have been done (if there was such an object):
>
> union{
>   RoundedCubeObject
>   point{point1,<1,1,1>}
>   point{point2,<1,1,-1>}
>   point{point3,<-1,1,-1>}
>   point{point4,<-1,1,1>}
>   point{point5,<1,-1,1>}
>   point{point6,<1,-1,-1>}
>   point{point7,<-1,-1,-1>}
>   point{point8,<-1,-1,1>}
>   rotate <clock*360,clock*360,clock*360> // affects the point objects as
> well
> }
>
> With a little OO thrown in, it would then be possible to do this:
>
> #declare obj_pos=point1.location;
> #include "SmokeGen.inc"
>
> #declare obj_pos=point2.location;
> #include "SmokeGen.inc"
>
> --
>
> #declare obj_pos=point8.location;
> #include "SmokeGen.inc"
>
> This way, you don't have to deal with math(which I believe keeps some
> users from using POV today).
>
> Instead, I had to make a vector array where the vectors are redeclared
> using a rotation identifier and also use vrotate() (which I don't mind
> using but beginners might have a hard time using). Quite messy.
>
> Comments?
>
> - Mikael.
>
> -----------------------------------------------------------------
> Mikael Carneholm
> Dep. of Computer Science

>
> http://www.studenter.hb.se/~arch
> E-mail: sa9### [at] idautbhbse
>
>   ------------------------------------------------------------------------
>
>   Mikael Carneholm <sa9### [at] idautbhbse>
>   Student

>   IDA
>
>   Mikael Carneholm
>   Student            <sa9### [at] idautbhbse>

>   IDA
>                      Netscape Conference Address
>                      Netscape Conference DLS Server
>   Additional Information:
>   Last Name   Carneholm
>   First Name  Mikael
>   Version     2.1

Post a reply to this message

Mikael Carneholm wrote:
> 
> One thing I've been thinking of that could make some things easier (for
> beginners as well as for advanced users) is a new object type: a point
> object.
>

First of all, a point is a 0-dimension object...
I guess you would then ask for a line (straight)
and then some more complicated lines (bezier in a plane, total free in
3d space)
That would give some 1-dimension object.
And the fractal gurus will come and ask some 1.65-dimensions fractals
up to the dreaded true 2-dimension plane object... (not the pov plane)
And then a sponge primitive
 
> syntax is POINT{[POINT IDENTIFIER][POINT LOCATION]}
> 
> ..where the point identifier is used to name the object for future
> reference.

Your point looks like a vector.
#declare POINT_IDENTIFIER = POINT_LOCATION;

> 
> "Why?" some might say - well here's an example:
> 
> I made a demo scene for my smoke generation macro, consisting of a
> rotating cube with 8 smoke sources (one in each corner). This is how it
> could have been done (if there was such an object):
> 
> union{
>   RoundedCubeObject
>   point{point1,<1,1,1>}
>   point{point2,<1,1,-1>}
>   point{point3,<-1,1,-1>}
>   point{point4,<-1,1,1>}
>   point{point5,<1,-1,1>}
>   point{point6,<1,-1,-1>}
>   point{point7,<-1,-1,-1>}
>   point{point8,<-1,-1,1>}
>   rotate <clock*360,clock*360,clock*360> // affects the point objects as
> well
> }

Well, you did have a look at vrotate (Vector Functions)
#declare point1=<1,1,1>;
#declare point2=<1,1,-1>;

and so on...
 
> With a little OO thrown in, it would then be possible to do this:
> 
> #declare obj_pos=point1.location;
> #include "SmokeGen.inc"
> 
#declare obj_pos = vrotate (point1, <clock*360,clock*360,clock*360> );
#include ...


> 
> This way, you don't have to deal with math(which I believe keeps some
> users from using POV today).

Well, you actually do not have to deal with math, 
you have to read the manual :-) 
(and that's something hard! the manual is quiet big to remember
everything )

> 
> Instead, I had to make a vector array where the vectors are redeclared
> using a rotation identifier and also use vrotate() (which I don't mind
> using but beginners might have a hard time using). Quite messy.
> 
> Comments?

Why a vector array in your case ? 

I sincerely does not feel the need for an object that you cannot see...
and the vector is already present.

Post a reply to this message

"J. Grimbert" wrote:

> First of all, a point is a 0-dimension object...
> I guess you would then ask for a line (straight)
> and then some more complicated lines (bezier in a plane, total free in
> 3d space)
> That would give some 1-dimension object.
> And the fractal gurus will come and ask some 1.65-dimensions fractals
> up to the dreaded true 2-dimension plane object... (not the pov plane)
> And then a sponge primitive

Nope. But a point is such a basic "primitive" that it's a good idea to include
it. A sponge though, is not a very basic primitive. Or is it? As useful as a
teapot maybe..

> Your point looks like a vector.
> #declare POINT_IDENTIFIER = POINT_LOCATION;
>

It sure does. But you can't union{} a bunch of declarations and affect the
locations of the declared vectors by putting them inside a union and then
translate/rotate the whole union.

> Well, you actually do not have to deal with math,
> you have to read the manual :-)
> (and that's something hard! the manual is quiet big to remember
> everything )

I can assure you I'm not the type of guy that doesn't read the docs. And I
don't think the purpose of the manual is to memorize the whole thing, I belive
most users (me included) just use it to check some syntax once in a while -
but only when necessary.

>
> Why a vector array in your case ?

Because it's more convenient.

>
> I sincerely does not feel the need for an object that you cannot see...
> and the vector is already present.

Argument: You reduce the amount of code necessary to do certain operations.
Let's say you have a spaceship with some lightsources on which you want to use
some lens flare effect; due to the "limitation" today, you have to have
separtate declarations for each vector and it's translation. If there was a
point primitive, you could declare MySpaceShip=union{ImportedMesh + some
points} and then translate it as a unit - which is much more natural, as
that's how we percieve an object when we see it even if it's a complex object.

NewsMessage.SignWithNameOnly("Mikael")

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


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

Post a reply to this message

Mikael Carneholm wrote:
> 
> "J. Grimbert" wrote:
> 
> > First of all, a point is a 0-dimension object...
> > I guess you would then ask for a line (straight)
> > and then some more complicated lines (bezier in a plane, total free in
> > 3d space)
> > That would give some 1-dimension object.
> > And the fractal gurus will come and ask some 1.65-dimensions fractals
> > up to the dreaded true 2-dimension plane object... (not the pov plane)
> > And then a sponge primitive
> 
> Nope. But a point is such a basic "primitive" that it's a good idea to include
> it. A sponge though, is not a very basic primitive. Or is it? As useful as a
> teapot maybe..
> 

Well, a point object does not exist. It's an abstraction for maybe an
atom.
Moreover, using the "object" term would be very misleading...
My generalisation from the point to the sponge was just to show
what may happen once you've agree to provide a point object. 
You will have trouble refusing an elementary line (also an abstraction)
and so on.

Oh, what about a klein bottle primitive ?  (just kidding)

> > Your point looks like a vector.
> > #declare POINT_IDENTIFIER = POINT_LOCATION;
> >
> 
> It sure does. But you can't union{} a bunch of declarations and affect the
> locations of the declared vectors by putting them inside a union and then
> translate/rotate the whole union.
> 

Ok, now, there is really a need here.
But the point object is not the solution.

What is needed is probably more something like array operator.
After all, pov have :
 rotate and translate for objects
 vrotate and + for vectors

We may probably get a nice enhancement with something like
 arotate and atranslate for array of vector

#declare new_array = arotate(old_array, B );

and 
#declare new_array = atranslate(old_array, B);

BTW, we could also need some scaling:
#declare new_array = ascale(old_array, B);

> > Well, you actually do not have to deal with math,
> > you have to read the manual :-)
> > (and that's something hard! the manual is quiet big to remember
> > everything )
> 
> I can assure you I'm not the type of guy that doesn't read the docs. And I
> don't think the purpose of the manual is to memorize the whole thing, I belive
> most users (me included) just use it to check some syntax once in a while -
> but only when necessary.

Well, I believe you read the manual (vrotate is not self evident).
But I have even problem just to remember all the possibilities from the
various sections:
 object, pattern, vectors, light, camera and so on.

Some months ago, there was a challenge about giving 'from head' all the
available patterns.
It was very difficult!

> 
> >
> > Why a vector array in your case ?
> 
> Because it's more convenient.
> 
> >
> > I sincerely does not feel the need for an object that you cannot see...
> > and the vector is already present.
> 
> Argument: You reduce the amount of code necessary to do certain operations.
> Let's say you have a spaceship with some lightsources on which you want to use
> some lens flare effect; due to the "limitation" today, you have to have
> separtate declarations for each vector and it's translation. If there was a
> point primitive, you could declare MySpaceShip=union{ImportedMesh + some
> points} and then translate it as a unit - which is much more natural, as
> that's how we percieve an object when we see it even if it's a complex object.
> 

Well, I would rather have a set of array functions than misusing the
union.
You will still have to duplicate the transformation (once for the
objects,
and once for the array), but that would be better than now.
(and adding vectors to the array would not request any new duplication)

Now, I cannot believe that I now agree that there is something missing
in pov. Or is is already somewhere in the manual ?

Post a reply to this message

"J. Grimbert" wrote:

> You will still have to duplicate the transformation (once for the
> objects,
> and once for the array), but that would be better than now.
>

Nope - just one transformation for the whole union:
union{
  SpaceShip
  lots of points
  rotate some
  translate some
}

Note: I'm sure there are other situations where this objects(primitive?) could be
useful. Just waiting for other users to reply and say they want it too :)

- Mikael.

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


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

Post a reply to this message

On Mon, 17 May 1999 15:05:20 +0200, Mikael Carneholm wrote:
>It sure does. But you can't union{} a bunch of declarations and affect the
>locations of the declared vectors by putting them inside a union and then
>translate/rotate the whole union.

Um... even if there were a "point" object, it would be a huge change to
have POV modify the #declared version (the prototype) when an instantiation 
of it is transformed.  If you did do that, the next thing you'd have is 
people doing this:

  #declare MySphere=sphere {0 1}
  union { MySphere sphere {x,1} translate 2*x pigment{color red 1}}
  object {MySphere translate y pigment {color green 1}}

and then wondering why the green sphere is at <0,1,0> instead of
<2,1,0>.

Post a reply to this message

Mikael Carneholm wrote:
> 
> "J. Grimbert" wrote:
> 
> > You will still have to duplicate the transformation (once for the
> > objects,
> > and once for the array), but that would be better than now.
> >
> 
> Nope - just one transformation for the whole union:
> union{
>   SpaceShip
>   lots of points
>   rotate some
>   translate some
> }
As I stated earlier, you would be misusing (abusing ?) the Union.
BTW, why not a Merge ? or any other CSG ?
IMHO, union is only a CSG, using it for something else is not good.

Moreover, Ron Parker wrote:
=>
=> Um... even if there were a "point" object, it would be a huge change
to
=> have POV modify the #declared version (the prototype) when an
instantiation 
=> of it is transformed.  If you did do that, the next thing you'd have
is 
=>people doing this:

=>  #declare MySphere=sphere {0 1}
=>  union { MySphere sphere {x,1} translate 2*x pigment{color red 1}}
=>  object {MySphere translate y pigment {color green 1}}

=> and then wondering why the green sphere is at <0,1,0> instead of
=> <2,1,0>.




> 
> Note: I'm sure there are other situations where this objects(primitive?) could be
> useful. Just waiting for other users to reply and say they want it too :)
> 

I would keep with my idea of array functions. It would be easily done
(as soon as I can get a working source of 3.1e installed, I will 
have a look at the parser to add the three functions... 
and dig a little in the array thing...
yet another floating patch... How can it be officially integrated ?)

BTW, have somebody any better idea for the name than
arotate/ascale/atranslate ?
(better ask now than do it and have to change it later ...)

Post a reply to this message

Come to think of it, trim curves might be nice for bicubic patches or for
NURBS if they are ever implemented.

-Mike

> I guess you would then ask for a line (straight)
> and then some more complicated lines (bezier in a plane, total free in
> 3d space)

Post a reply to this message

How about a "points" attribute for objects?

sphere {  <1,5,7>, 6
    texture stuff
    interior stuff
    points {
        #declare pointA = < 1,1,8>;
        ...
    }
}
The vectors declared in the points {...} attribute would be accessible
like any other vectors, I'm sure there would be some way of having them
be accessed through the object itself, but that would require that each
object be named.
You could use any object, with this, and avoid invisible primitives.

Post a reply to this message