If interested here are some of my thoughts on features for the pov4.0
c++
release:

   1. This one is simple and could be implemented now without too much
trouble, but would be very convenient to povers.. we have a union, a
diff.
a ... ect why not a simple group keyword that does not physically
combine the objects just groups them so they can be manipulated as one,
like with translate or scale or something. this info could probably also
used
for calculating bounding slabs.(quicker, more efficiently??)
   2. One should be able to create and delete objects from a scene at
any time.(and a delete group object would recursively remove all the
object contained by that group...)
   3. The pov-core should be like a library, providing basic functions
to other programs. For example, it could define methods like
pov.parser.load_scene_from_file() pov.renderer.trace_scene(), making it
easy for new methods to be added like load_scene_from_binary_file() or
trace_partial_scene() for cluster rendering. these functions in turn
could be called by other
programs,(so that one program might say: load scene, render, write as
jpeg, another as gif, while others might be like modellers, where the
modeler doesn't have to worry about parsing pov-format files, it can
just call load_scene(), maybe even a write_scene(), and
manipulate_scene(), to modify an existing scene(imagine you can make a
change in a pov modeller/editor and then click the render button without
even saving the file and having pov reread and reparse it!!))and the use
would be independent from the
core, which would probably encourage more utilities and generally cool
stuff to be made by and for pov enthusiastic.
note: this would also make it more portable, nothing platform specific
would be included in the core. 
   4. plugable... plugable object types, plugable effects, plugable
cameras.. everything. If this happened, I would even write a
plugger-client/server to connect to the official plug-in site, and offer
all users a easy way to download/install/ any plug-ins.. you could even
have different channels.. ever seen helix-code update???
   5. multiple cameras, why can't I define 10 cameras in one scene, and
then say, pov.renderer.trace_scene(POVCamera camera)
   6. why not give each object, including group objects, and cameras a
name, so it can be easily referenced later(so it can be removed, moved,
scaled, change properties like color...(animator's might like this;>)
   7.  well thats it for now... any opinions?? by the way i don't mean
to be critical of povray, I just wanted to give everybody some stuff to
think about.

Post a reply to this message

In article <399C8823.DD03EB6F@vrml.k12.la.us>, Abe Heckenbach 
<abe### [at] vrmlk12laus> wrote:

> If interested here are some of my thoughts on features for the pov4.0
> c++ release:

I think it should be said again that POV 4.0 will have the source code 
be object-oriented, but the language may be no different than it is.


>    1. This one is simple and could be implemented now without too much
> trouble, but would be very convenient to povers.. we have a union, a 
> diff. a ... ect why not a simple group keyword...
...snip...

Umm, how is this different from union? Pretty much all union does is 
group objects so you can tranform, texture, or CSG all of them at once.


>    2. One should be able to create and delete objects from a scene at
> any time.(and a delete group object would recursively remove all the
> object contained by that group...)

Once an object is in the scene, it should stay there, and stay in the 
same state it was when it was first placed there. If you decide an 
object isn't in the scene, you shouldn't put it there in the first place.


>    3. The pov-core should be like a library, providing basic functions
> to other programs.
...snip...
This sounds an awful lot like the "POV should be/have an API" 
argument...and has been discussed many times. The source code may be 
designed something like this(just for good design practice), but the 
interface may not be available to outside programs.


> note: this would also make it more portable, nothing platform specific
> would be included in the core. 

Organizing the platform-independant core code as separate objects would 
make it more independant, but there still isn't a platform independant 
way of making those functions available to outside programs.


>    4. plugable... plugable object types, plugable effects, plugable
> cameras.. everything. If this happened, I would even write a
> plugger-client/server to connect to the official plug-in site, and offer
> all users a easy way to download/install/ any plug-ins.. you could even
> have different channels.. ever seen helix-code update???

Extremely difficult to do, and practically impossible to do without a 
high cost in speed. The plugins(and the code for dealing with them) 
would have to be cross-platform, so they would either require a compiler 
to be built into the POV application, or they would need to be in a 
byte-code format similar to the way Java is done. Both would be slower 
than a fully optimized compiled version for each platform. If you want 
to modify POV, the best choice is to download the source and make an 
unofficial patch.
And what do you mean by "helix-code update"?


>    5. multiple cameras, why can't I define 10 cameras in one scene, and
> then say, pov.renderer.trace_scene(POVCamera camera)

Umm, where would this line go? In the scene file? I think it would be 
better to stick to the current way of doing it. You can already declare 
multiple cameras and decide which one to use...


>    6. why not give each object, including group objects, and cameras a
> name, so it can be easily referenced later(so it can be removed, moved,
> scaled, change properties like color...(animator's might like this;>)

You can already make a variable, a separate label simply complicates 
things and is inconsistant.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

And what the **** has all this to do with object orientedness?

  It seems to me that most people have a misleading concept on what object
orientedness really means.

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

Abe Heckenbach wrote:

>    6. why not give each object, including group objects, and cameras a
> name, so it can be easily referenced later(so it can be removed, moved,
> scaled, change properties like color...(animator's might like this;>)

This is in the direction of OO-features in the scene language - a popular(?)
topic in these groups. I think what you're thinking of is something like
this:

#declare Foo=difference{
  box{1,-1}
  union{
    sphere{0, 0.5 translate x*1}
    sphere{0, 0.5 translate x*-1}
  }
}

#declare Foo.subobject[1].subobject[0].scale=2;
#declare Foo.subobject[1].subobject[1].location=<-1,1,0>;
#declare Foo.pigment=color{rgb 1};
// etc.

This is exactly the type of features I'd like to see as well - BUT, not for
the price of leaving backwards-compability behind.

(See my longer post in the "Object oriented POV scene language?" thread.)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

Mikael Carneholm wrote:

> (See my longer post in the "Object oriented POV scene language?" thread.)
>

Oops...forgot to mention that it's in povray.programming.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

What would be the advantage of transforming subobjects after the CSG has
been declared?
  I think that internally povray would have to create a whole new object
anyways for this.

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

Warp wrote:

>   What would be the advantage of transforming subobjects after the CSG has
> been declared?
>

I think the main advantage of OO (from my point of view) would be _reading_
the location/rotation/scale etc. of objects, instead of (as in the example):
setting the values. Of course, there are also situations when setting the
values of object attributes should be useful, but this (rather meaningless)
example was what I could come up with at the spur of the moment. :)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

>I think the main advantage of OO (from my point of view) would be
_reading_
>the location/rotation/scale etc. of objects

I don't think that will work.  If I'm not mistaken, POV-Ray builds a
transform matrix for each tranformation and keeps multiplying these, so
in the end you'll be lucky for the program to spit out one matrix in the
end.

-Mike

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: I think the main advantage of OO (from my point of view) would be _reading_
: the location/rotation/scale etc. of objects, instead of (as in the example):
: setting the values.

  Sorry for whining, but you (and apparently everyone else) keep calling
this object oriented although it isn't.
  Yes, this is an essential part of an object oriented language, but it's
not object oriented in itself.
  What you are talking about are modules. A programming language can use
modules without being an OO language (for example modula2 is one of those).
These languages have modules which have member functions and member variables,
public and private parts and so on. This, however, is not yet OO.
  For a programming language to be OO it has to have modules as in any
modular language AND it has to have support for inheritance, dynamic binding
and polymorphism. A program is object oriented when it uses these features
(mainly inheritance and dynamic binding). Else it just uses modules.

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

Warp wrote:

>   Sorry for whining, but you (and apparently everyone else) keep calling
> this object oriented although it isn't.
>   Yes, this is an essential part of an object oriented language, but it's
> not object oriented in itself.
>   What you are talking about are modules. A programming language can use
> modules without being an OO language (for example modula2 is one of those).
> These languages have modules which have member functions and member variables,
> public and private parts and so on. This, however, is not yet OO.
>   For a programming language to be OO it has to have modules as in any
> modular language AND it has to have support for inheritance, dynamic binding
> and polymorphism. A program is object oriented when it uses these features
> (mainly inheritance and dynamic binding). Else it just uses modules.

Who said OO-POV shouldn't allow inheritance and polymorphism? If the examples in
my long post does not look like inheritance and polymorphism to you, I apologize.
But, for clarity, here they are, again:

// A "base class" (object) for our worm:
#declare worm_part1=sphere{
 0, 0.5
 pigment{color rgb 1}
 ref{next}  // tells POV that this object has a reference, called "next"
}

// Inheritance...don't you think, Warp? :)
// IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
"from" better than "like" maybe?)
#declare worm_part2=like worm_part1{
  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 this last block would be polymorphism, don't you think, Warp? Well of
course, we don't call common-named methods with different implementations here (as
the well taught OO student points out), but the <object>.location expression is
referencing different object types with common attribute names.

And another thing: OO in POV should be easy enough for everyone to use - one
should not have to study OO theory in order to use it. That's the reason for the
somewhat "crippled" implementation of OO suggested here.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: // IDENTIFIER = like ANCESTOR, or actually: SUBOBJECT = like SUPEROBJECT (is
: "from" better than "like" maybe?)

  Perhaps the best name would be "is_a".

  1. Inheritance (at least public inheritance) is always an "is a" relation.
The inherited class "is a" base class.
  For example if we have a base class Vehicle and we inherit a class Car from
it and then we inherit a class Opel from it, the "is a" relation is clear:
  Opel is a Car, and Car is a Vehicle.

  2. The "is a" relation means that an instance of the derived class can be
used anywhere an instance of the base class is used. This means that the
derived class must contain all the functionality of the base class.

  The second note is important. Sometimes one can do bad inheritance if only
the first thing is taken into account. For example one could think that
a Circle "is a" Ellipse so one could (wrongly) make an Ellipse base class and
inherit a Circle class from it. However, a Circle does not have the same
functionality as the Ellipse (eg. you can't set two radiuses).

  It is considered bad OO design to inherit from another class only to make
a "copy" of that class with some modification. For example if I have the
class IceCream, which describes a chocolate ice cream and then I inherit
a StrawberryIceCream from it, to make a similar ice cream, but with
strawberry flavor, that's bad OO design.
  The correct way is to make a (possibly abstract) base class IceCream and
then inherit different flavored classes from it, eg. ChocolateIceCream and
StrawberryIceCream. Now there's a true "is a" relation between inherited
and base classes.

  Why do I write all this? Because I didn't like your example:

: #declare worm_part2=like worm_part1{
:   pigment{color rgb 0}  // leaves everything like worm_part1, except the pigment.
: }

  You are making a strawberry ice cream from a chocolate ice cream here :)

: ....and this last block would be polymorphism, don't you think, Warp? Well of
: course, we don't call common-named methods with different implementations here (as
: the well taught OO student points out), but the <object>.location expression is
: referencing different object types with common attribute names.

  That's not polymorphism, it's dynamic binding.
  Yes, a true OO feature.

-- 
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 <399CFECD.630F8C9C@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> I think the main advantage of OO (from my point of view) would be 
> _reading_ the location/rotation/scale etc. of objects...
...snip...

This won't be possible, even with member variables and macros. 
Transformations(scale, rotate, translate, matrix) are all stored in a 
4*4 matrix, and what would "location" mean? The center of the bounding 
box?

BTW, I would prefer a #reference keyword to your ref {} syntax, it could 
be used outside of objects. Maybe a specific members {} block in objects 
would be a good idea, though...
object {...
    members {
        #reference Next = object {...};// a reference
        #declare Velocity = < 1, 5, 0>;// a public variable
        #local Speed = vlength(< 1, 5, 0>);// a protected variable
        #macro GetSpeed() Speed #end // a member macro
    }
}

All objects would already have public transform and material member 
variables and member macros for operating on them(you could arrange all 
objects in a heirarchy, with "object" being the base object, so the 
language is consistent, but of course, these would be hard-coded...). In 
addition to these inherited members, objects would have variables 
specific to them: spheres would have a "center" vector and a "radius" 
float, boxes would have "point_a" and "point_b" vectors...this would 
allow the current syntax to be retained, but make things easy to do with 
the OO syntax.

BTW, I think the biggest advantage of OOP scripting would be things like 
macros and include files that really emulate objects. You could create a 
"lens flare" object, and have as many of these as you wanted, and it 
would be almost completely transparent to the person using the lens 
flares. Or you could do particle systems, tree/plant objects, 
etc...using them could be much easier than with macros and include 
files, especially when you have many of them.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Warp wrote:

> Perhaps the best name would be "is_a".

Errr...it's not what type of relation it is...it's what the keyword in OO-POV should
be!
I know it's an "is a"-relation - just sketching on a suggestion for new syntax! :-)

<lots of basic OO theory snipped>

>   It is considered bad OO design to inherit from another class only to make
> a "copy" of that class with some modification. For example if I have the
> class IceCream, which describes a chocolate ice cream and then I inherit
> a StrawberryIceCream from it, to make a similar ice cream, but with
> strawberry flavor, that's bad OO design.
>   The correct way is to make a (possibly abstract) base class IceCream and
> then inherit different flavored classes from it, eg. ChocolateIceCream and
> StrawberryIceCream. Now there's a true "is a" relation between inherited
> and base classes.
>
>   Why do I write all this? Because I didn't like your example:
>
> : #declare worm_part2=like worm_part1{
> :   pigment{color rgb 0}  // leaves everything like worm_part1, except the pigment.
> : }
>
>   You are making a strawberry ice cream from a chocolate ice cream here :)

Of course, I could have made an abstract base (class) object worm_node, and then
inherited worm_part1 and worm_part2 from that object, but as stated before: OO-POV
should not be java (actually, java is already very good at it - being java, i.e.), and
thus it may not need being as OO correct as java is. In the code above, one is saying:
"worm_part2 is like worm_part1, except it has a different pigment" - and I guess many
users would be irritated if they got an error saying "Not strictly correct OO used at
line nnn" while parsing? AND - POV-Ray has always been known for it's flexible and
(rather) forgiving syntax - let's keep it that way.

If one made multiple inheritance possible I could see your point, but that's not going
to happen (if I get to choose) - because THEN we're really talking bad OO design.


>   That's not polymorphism, it's dynamic binding.
>

Yep, you're right there...I always seem to regard those two as equivalent, even though
there is a difference. Anyway, if the OO POV language also should incorporate object
methods (you never know), they should of course be allowed to work in a polymorphic
way,
if possible.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

Chris Huff wrote:

> Transformations(scale, rotate, translate, matrix) are all stored in a
> 4*4 matrix, and what would "location" mean? The center of the bounding
> box?

Location, as I thought of it, should be one of the common attributes for all
objects. Think java again:

public virtual class POVOBJECT{
  public povVector location, rotation;
}

As you see, one can't create a "povobject", but all objects in the POV 3d
space should be descendants from this class, as all objects in POV can be
rotated and translated. I.e, let's continue with the class declaration for a
sphere:

public class SPHERE extends POVOBJECT{
  public double radius;
  public povMaterial material;
}

Ok, let's create a sphere:

#declare A=sphere{
  0, 0.5
  pigment{ color rgb 1}
}

Right now, A.location=<0,0,0>, and A.rotation=<0,0,0> (as default). If we
change A.location:

#declare A.location=<0,1,0>;  // or by using a method, like
A.translate(<0,1,0>) (?)

..A.location is now <0,1,0>, similar to sphere{ ... translate <0,1,0>}. For
other type of objects, like boxes, it's maybe not a bad idea using the
center of the bounding box. Coming to thinking of it - maybe it's better to
have a "translation" attribute instead, which together with object specific
member attributes could be used to get the data needed:

#declare foo=sphere{
  <0,1,0>,  //let's store this in a sphere-specific attribute called
"origin", which holds the vector where it was originally created.
  0.5
  translate <1,0,0>
}

To retrieve the center of the sphere, one could use foo.origin and
foo.translation: The center of the sphere is now at
foo.origin+foo.translation.

This would work better with other types of objects, as box for example,
where the whereabouts on this box:

#declare foo=box{
  -1,1
  translate <1,1,1>
}

..could be retrieved using foo.corner1, foo.corner2 (or something like that)
together with foo.translation. Cylinders could have .top, .bottom, .radius,
polygons could have .point[] and .point_count etc.

> BTW, I would prefer a #reference keyword to your ref {} syntax, it could
> be used outside of objects. Maybe a specific members {} block in objects
> would be a good idea, though...
> object {...
>     members {
>         #reference Next = object {...};// a reference
>         #declare Velocity = < 1, 5, 0>;// a public variable
>         #local Speed = vlength(< 1, 5, 0>);// a protected variable
>         #macro GetSpeed() Speed #end // a member macro
>     }
> }

Not a bad suggestion, at all. I've been thinking of something similar, i.e.
all (POV) objects can have abstract (non visual) member attributes and
methods:

#declare myMovingThingy=union{
  cylinder{...}
  box{...}
  members{
        #reference Next = object {...};// a reference
        #declare Velocity = < 1, 5, 0>;// a public variable
        #local Speed = vlength(< 1, 5, 0>);// a protected variable
        #macro GetSpeed() Speed #end // a member macro
  }
}

Here, the encapsulation subject is also covered, so I guess Warp is happy
now :)

As said, the subject is open for suggestions..

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

> >    1. This one is simple and could be implemented now without too much
> > trouble, but would be very convenient to povers.. we have a union, a
> > diff. a ... ect why not a simple group keyword...
> ...snip...
> 
> Umm, how is this different from union? Pretty much all union does is
> group objects so you can tranform, texture, or CSG all of them at once.

sorry, my mistake, I was thinking that a union could only be used for
objects physically connected, and that it would be nice to be able to
manipulate a group of objects as one, with out changing the final
image..(though I guess image mapping might look different).

> 
> >    2. One should be able to create and delete objects from a scene at
> > any time.(and a delete group object would recursively remove all the
> > object contained by that group...)
> 
> Once an object is in the scene, it should stay there, and stay in the
> same state it was when it was first placed there. If you decide an
> object isn't in the scene, you shouldn't put it there in the first place.

I meant for animations, interactive 3d, ect. where you would want to
change objects arbitrarily from any point, like switching a virtual
light switch to remove(or just make invalid) a light source, for
example.

> 
> >    3. The pov-core should be like a library, providing basic functions
> > to other programs.
> ...snip...
> This sounds an awful lot like the "POV should be/have an API"
> argument...and has been discussed many times. The source code may be
> designed something like this(just for good design practice), but the
> interface may not be available to outside programs.
> 
there are over 20,000 messages in this newsgroups, so there is no way I
could just read them all to see if the topic had been discussed.  I
really think this is an important thing to have, it allows it to be very
versatile and modular, and independent of application, one person might
want to used it to render a singe frame, another might want to take his
hand at a movie :), (I have a lot of ideas with raytracing that would be
alot easier to try if it was like this, for right now I'm  actually
writing my own ray tracer because it easier than making changes all
across what like 90,000 lines of code that povray currently is!!

> > note: this would also make it more portable, nothing platform specific
> > would be included in the core.
> 
> Organizing the platform-independant core code as separate objects would
> make it more independant, but there still isn't a platform independant
> way of making those functions available to outside programs.

huh?? I don't know what you mean by that. if you provide a platform
independent method called trace_scene(POVScene,POVCamera), any other
c/c++ program can call it and do what every it wants with it(likely
platform specific like some kind of gui.)

> 
> >    4. plugable... plugable object types, plugable effects, plugable
> > cameras.. everything. If this happened, I would even write a
> > plugger-client/server to connect to the official plug-in site, and offer
> > all users a easy way to download/install/ any plug-ins.. you could even
> > have different channels.. ever seen helix-code update???
> 
> Extremely difficult to do, and practically impossible to do without a
> high cost in speed. The plugins(and the code for dealing with them)
> would have to be cross-platform, so they would either require a compiler
> to be built into the POV application, or they would need to be in a
> byte-code format similar to the way Java is done. Both would be slower
> than a fully optimized compiled version for each platform. If you want
> to modify POV, the best choice is to download the source and make an
> unofficial patch.

This one would be difficult... if not impossible, but I was thinking
something like.. you can have a patch/plugin fetcher that connect to a
plugin site, and allows you to download any plugin you want, and install
it. you could have different channels for different types of patches AND
platforms, so you only get ones available to your platform...

> And what do you mean by "helix-code update"?
> 

if your a linux fan, them you know what gnome is, helix-code is
basically gnome with alot of extras, one of which is an updater that
fetches new patchs/releases/extras and has multiple channels. I've been
told M$ has something similar now,win-update or something..

> >    5. multiple cameras, why can't I define 10 cameras in one scene, and
> > then say, pov.renderer.trace_scene(POVCamera camera)
> 
> Umm, where would this line go? In the scene file? I think it would be
> better to stick to the current way of doing it. You can already declare
> multiple cameras and decide which one to use...
> 
I haven't tried any animations yet, I didn't realize you could have more
than one camera,.. but I think it would be cool to create multiple
cameras, each with a name(like "ViewFromSky") and then say
trace_scene(scene, getCamera(scene, "ViewFromSky")


> >    6. why not give each object, including group objects, and cameras a
> > name, so it can be easily referenced later(so it can be removed, moved,
> > scaled, change properties like color...(animator's might like this;>)
> 
> You can already make a variable, a separate label simply complicates
> things and is inconsistant.
> 
Imagine you have a virtual dog, if you have names for everything, you
could say: translate (dog.front_left_leg, control_point_2, <0,0,0>), to
move objects, and subobjects arbitrary.

> --
> Christopher James Huff
> Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
> TAG: chr### [at] tagpovrayorg, http://tag.povray.org/
> 
> <><

these are just ideas, apparently not even good ones... the only reason
I'm even interested in povray is because its the best damn raytracer
I've seen yet! and it's flaws are more than made up for by what it can
do. I am a fan/supporter of the open-source community and wish to see
povray become a raytracer that everyone wants to use(over commercial
crap)..

pleas edont be offended by anything I say, I didn't mean to criticize
povray..

Abe

Post a reply to this message

In article <399DAE0A.2AC32A30@vrml.k12.la.us>, Abe Heckenbach 
<abe### [at] vrmlk12laus> wrote:

> sorry, my mistake, I was thinking that a union could only be used for
> objects physically connected, and that it would be nice to be able to
> manipulate a group of objects as one, with out changing the final
> image..(though I guess image mapping might look different).

Image mapping and texturing would be exactly the same.


> I meant for animations, interactive 3d, ect. where you would want to
> change objects arbitrarily from any point, like switching a virtual
> light switch to remove(or just make invalid) a light source, for
> example.

The best way(in my opinion, the right way) to do this is to use 
persistant *variables* that are added to the scene each frame. The scene 
would be cleared each frame, so you wouldn't see any difference, but the 
code would be simpler(you wouldn't have to make sure you aren't 
duplicating an object already in the scene), and there isn't as much of 
a problem of different incompatible ways of referring to an object.


> there are over 20,000 messages in this newsgroups, so there is no way I
> could just read them all to see if the topic had been discussed. 

Specifically, search in povray.general and the more recent discussions 
in povray.programming.


> I really think this is an important thing to have, it allows it to be 
> very versatile and modular, and independent of application, one 
> person might want to used it to render a singe frame, another might 
> want to take his hand at a movie :),

You can already use POV for both stills and movies...


> (I have a lot of ideas with raytracing that would be alot easier to 
> try if it was like this, for right now I'm  actually writing my own 
> ray tracer because it easier than making changes all across what like 
> 90,000 lines of code that povray currently is!!

What are these ideas that require a new raytracer? What changes would 
you have to make in order to use a scene file that an API wouldn't 
require?
These are the usual arguments for an API, some of the arguments against 
it are:
It isn't needed, you can already access all of POV's features through 
the scene description language.
It isn't cross-platform, you would have to write different code to 
expose these APIs for every port.
It makes it less obvious to the user that POV is the program doing the 
work.

Some of the platforms(Mac and Windows) already have limited API's, 
basically enough to tell POV to render a specific scene with certain 
settings, and this is all that is necessary. Also, it doesn't belong as 
a core feature, but a platform-specific feature.

BTW, good luck on your raytracer...I hope you release the source(and if 
you do, that you keep platform dependant code isolated from the rest of 
the code). :-)


> huh?? I don't know what you mean by that. if you provide a platform
> independent method called trace_scene(POVScene,POVCamera), any other
> c/c++ program can call it and do what every it wants with it(likely
> platform specific like some kind of gui.)

No. You have to go through special work to allow other programs to use 
the function...and there isn't a platform independant way to do this.


> This one would be difficult... if not impossible, but I was thinking
> something like.. you can have a patch/plugin fetcher that connect to a
> plugin site, and allows you to download any plugin you want, and install
> it. you could have different channels for different types of patches AND
> platforms, so you only get ones available to your platform...

Making POV-Ray dependant on an internet connection? No thanks...
And it still has the problems of accessing the plugins in a 
cross-platform way, speed, etc.


> if your a linux fan, them you know what gnome is, helix-code is
> basically gnome with alot of extras, one of which is an updater that
> fetches new patchs/releases/extras and has multiple channels. I've been
> told M$ has something similar now,win-update or something..

I'm interested in Linux, but I don't have much experience with it, and 
haven't heard about this. I wouldn't know about any M$ project 
either...I don't use Windows. Look at my headers, e-mail address, and 
web site. :-)


> I haven't tried any animations yet, I didn't realize you could have more
> than one camera,.. but I think it would be cool to create multiple
> cameras, each with a name(like "ViewFromSky") and then say
> trace_scene(scene, getCamera(scene, "ViewFromSky")

#declare ViewFromSky = camera {...}
#declare ViewFromGround = camera {...}
...
camera {ViewFromSky}

Or do you mean rendering more than one image at once?
I think the .pov file should stick to scene description as much as 
possible...but maybe another type of file could be useful...something 
more friendly and powerful than .ini files, which controls the rendering 
process, and can pass information to the POV file through variables.


> Imagine you have a virtual dog, if you have names for everything, you
> could say: translate (dog.front_left_leg, control_point_2, <0,0,0>), to
> move objects, and subobjects arbitrary.

How does this conflict with using a variable?
#declare Dog =
object {...
    members {
        #declare FrontLeftLeg = object {...};
        #declare ControlPoint2 = < 0, 1, 2>;
        #macro GetCurrentState() ... #end
    }
};

Dog.FrontLeftLeg.translate(...);
#set Dog.ControlPoint2 = vtransform(Dog.ControlPoint2, ...);

object {Dog.GetCurrentState()}

Notice the #set command...this is just something I think should be 
added, it would only modify existing variables and would not create a 
new one. I have had many times when this would make things easier to 
read and prevent a bug or two...oh, and the vtransform() function is 
something new in MegaPOV. The GetCurrentState() macro would take the 
current condition of the dog and return a union object.
The members{...} block would be to retain backwards compatability...you 
can already place declarations within objects, having them suddenly 
become members of the object in the new version wouldn't be very 
user-friendly. :-)


> these are just ideas, apparently not even good ones... the only reason
> I'm even interested in povray is because its the best damn raytracer
> I've seen yet! and it's flaws are more than made up for by what it can
> do. I am a fan/supporter of the open-source community and wish to see
> povray become a raytracer that everyone wants to use(over commercial
> crap)..

Your ideas are not "crap"...I doubt anyone will know what OOPOV will 
look like until it actually exists. :-)
BTW, POV-Ray is *not* open source, though that seems to be a common 
misconception...the main difference is in the licensing. The POV-Team 
wishes to keep more control over their work than open-sourcing would 
allow, which they have every right to. They do make the source available 
and allow distribution of modified versions, though, so they (and the 
community) get some of the same benefits of open source without many of 
its problems.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <399DAE0A.2AC32A30@vrml.k12.la.us> , Abe Heckenbach 
<abe### [at] vrmlk12laus>  wrote:

> huh?? I don't know what you mean by that. if you provide a platform
> independent method called trace_scene(POVScene,POVCamera), any other
> c/c++ program can call it and do what every it wants with it(likely
> platform specific like some kind of gui.)

No, it is not.  Different platforms have different methods of making
functions available to outside programs.  This usually requires changing the
source code in some way.  One simple change might be that all the compiler
requires is an compiler specific option to export, i.e. something line
"#export on".  But it might also require some special conventions to
overcome the way how different compilers manage function calls, i.e. the
'popular'  "CDECL" declaration of functions...

To make it short, neither the C nor the C++ standard says anything about
making functions available to outside programs.  In consequence, there is no
standard way to make extern function calls cross-platform easily. *


     Thorsten


* Yes, there are some frameworks that try to overcome this, but this is not
the point here - they are not available anywhere (unlike a good C compiler)!

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
:> Perhaps the best name would be "is_a".

: Errr...it's not what type of relation it is...it's what the keyword in OO-POV should
be!
: I know it's an "is a"-relation - just sketching on a suggestion for new syntax! :-)

  Well, what would be better keyword that one that describes the type of
relation it computes?

: and I guess many
: users would be irritated if they got an error saying "Not strictly correct OO used
at
: line nnn" while parsing?

  Well, they may get irritated, but in my opinion is better to teach correct
OO programming from the very beginning than trying to correct bad habits
afterwards :)

: AND - POV-Ray has always been known for it's flexible and
: (rather) forgiving syntax - let's keep it that way.

  Well, C++ is very flexible and forgiving. I like C++ because of that, but
it has the bad concecuence of teaching bad habit to beginners :)
  And I'm not saying that povray's syntax should be stricter. I really like
the fact that I can write this:

light_source { <1,2,3>, rgb <1,1,1> }

  this:

light_source { <1,2,3>, <1,1,1> }

  or this:

light_source { <1,2,3>1 }

  or even this:

light_source { x+y*2+z*3, x }

-- 
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 povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
: Location, as I thought of it, should be one of the common attributes for all
: objects. Think java again:

: public virtual class POVOBJECT{
:   public povVector location, rotation;
: }

  Now you forget one thing: That takes memory. And povray is not very well
known when speaking about low memory consumption. Let's not make the matter
even worse.

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

"Abe Heckenbach" <abe### [at] vrmlk12laus> wrote...
> If interested here are some of my thoughts on features for the pov4.0
> c++
> release:

In my opinion, you have a lot of good ideas.  In fact, many of them have
even been discussed by the POV-Team already.  Unfortunately, most of them
would be quite difficult, if not currently impossible, to implement in way
that keeps POV platform independent.  However, that doesn't mean that we
should give up on these ideas.  But for now we (the POV-Team members) need
to focus our efforts on POV 3.5.  If members of the POV community want to
research these topics and do some testing, that would be great.  When we get
to work on POV 4.0, I would be interested in knowing what you all find out.

Disclaimer: I speak for myself as a member of the POV-Team, but not on
behalf of the Team.

-Nathan Kopp

Post a reply to this message

| How does this conflict with using a variable?
| #declare Dog =
| object {...
|     members {
|         #declare FrontLeftLeg = object {...};
|         #declare ControlPoint2 = < 0, 1, 2>;
|         #macro GetCurrentState() ... #end
|     }
| };
| 
| Dog.FrontLeftLeg.translate(...);
| #set Dog.ControlPoint2 = vtransform(Dog.ControlPoint2, ...);
| 
| object {Dog.GetCurrentState()}

Umm...  Chris, you can already modify existing variables.
#declare A = 435435/2423423^23
//Varia code
#declare A=A+anythingyouwant.

Or did you mean something else?

H.E. Day
<><

Post a reply to this message

In article <01c00a5c$cc13e9e0$8e7889d0@daysix>, "H. E. Day" 
<Pov### [at] aolcom> wrote:

> Umm...  Chris, you can already modify existing variables.
> #declare A = 435435/2423423^23
> //Varia code
> #declare A=A+anythingyouwant.
> 
> Or did you mean something else?

I mean something else, I know you can modify variables. :-)
#set would *only* modify existing variables, if you tried to #set a 
nonexistant identifier, an error would be produced. I have sometimes had 
a simple typo produce an entirely new variable when I was trying to 
modify an existing one, using #set would have prevented that bug(since 
an error would have been produced identifying the code which would cause 
a problem).
Basically, #declare and #local would create variables(and behave exactly 
as they do now, preserving backwards compatibility), #set would modify 
the most local variable with the given name. It would make easier to 
read scene code(it makes it obvious where the variable is created and 
where it is only modified) and find bugs.
It shouldn't be difficult to do, but I can't make much sense of the 
parsing code.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Mikael Carneholm wrote:

>Abe Heckenbach wrote:
>
>>    6. why not give each object, including group objects, and cameras
>>    a 
>> name, so it can be easily referenced later(so it can be removed,
>> moved, scaled, change properties like color...(animator's might like
>> this;>) 
>
>This is in the direction of OO-features in the scene language - a
>popular(?) topic in these groups.

This might be interesting:
http://virtualphoton.pc.cc.cmu.edu/projects/visual/
http://cil.andrew.cmu.edu/projects/visual/vpythonprog.htm

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message

On 19 Aug 2000 20:38:33 -0400, Warp wrote:
>In povray.general Mikael Carneholm <sa9### [at] idautbhbse> wrote:
>: Location, as I thought of it, should be one of the common attributes for all
>: objects. Think java again:
>
>: public virtual class POVOBJECT{
>:   public povVector location, rotation;
>: }
>
>  Now you forget one thing: That takes memory. And povray is not very well
>known when speaking about low memory consumption. Let's not make the matter
>even worse.

Then think:

public virtual class POVOBJECT{
  public povVector getLocation(), getRotation();
}

That doesn't take extra memory per object and is also cleaner from
an OO point of view. The methods could compute their values from the
transformation matrix for most objects.

	hp

-- 
   _  | Peter J. Holzer    | Nicht an Tueren mangelt es,
|_|_) | Sysadmin WSR       | sondern an der Einrichtung (aka Content).
| |   | hjp### [at] wsracat      |    -- Ale### [at] univieacat
__/   | http://www.hjp.at/ |       zum Thema Portale in at.linux

Post a reply to this message

In povray.general Peter J. Holzer <hjp### [at] sikituwsracat> wrote:
: That doesn't take extra memory per object and is also cleaner from
: an OO point of view. The methods could compute their values from the
: transformation matrix for most objects.

  How do you compute the location, scale and rotation of an object from its
transformation matrix?
  AFAIK there's more than one way to get any specific transformation matrix.

  The problem becomes clearer when you think about sheared objects.

-- 
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 <399D6B3D.51EACD7E@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> Location, as I thought of it, should be one of the common attributes 
> for all objects.
...snip...

Still, what *is* the location? A sphere has a center, but what is the 
center of a cone? The middle of the bounding box? The center of gravity?
What is the "location" of an infinite plane? A complex mesh or CSG?
Each object should have it's own variables available, but a single 
"location" variable for all of them isn't possible. Maybe a 
GetLocation() method for all objects in the finite object portion of the 
heirarchy, but you still have to define the location of an arbitrary 
object.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <slr### [at] tealhhjpat>, 
hjp### [at] SiKituwsracat (Peter J. Holzer) wrote:

> That doesn't take extra memory per object and is also cleaner from
> an OO point of view. The methods could compute their values from the
> transformation matrix for most objects.

Warp is right, matrices store many transforms in order, and there are 
usually a very large or infinite number of possible 
rotations/translations/scales to get to a specific point.
And what would the "object rotation" mean? The direction of the z axis 
in degrees? I think you are thinking of the sum of all rotations, which 
I don't think you can easily extract from a matrix which also stores 
translations, scaling, and arbitrary matrix transforms. Just make the 
matrix available, the user can override the rotate() methods to save 
each rotation in a vector if they want.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Fri, 18 Aug 2000 11:15:57 +0200, Mikael Carneholm wrote:
>Warp wrote:
>
>>   What would be the advantage of transforming subobjects after the CSG has
>> been declared?
>>
>
>I think the main advantage of OO (from my point of view) would be _reading_
>the location/rotation/scale etc. of objects, instead of (as in the example):
>setting the values. 

I don't understand this mindset.  If you need to know what transformations
have been applied to object foo at some point in the future, keep track of
what transformations you've applied.  What's so hard about that?

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Sun, 20 Aug 2000 11:08:18 -0500, Chris Huff wrote:
>I don't think you can easily extract from a matrix which also stores 
>translations, scaling, and arbitrary matrix transforms. Just make the 
>matrix available, the user can override the rotate() methods to save 
>each rotation in a vector if they want.

You might be surprised.  Except for the arbitrary transforms (which make
the problem different, but possibly not much more difficult) it's relatively 
easy to decompose a matrix into rotations, scales, and translates.  I wrote
the whole mess up for someone in c.g.r.r. a few years ago; I think I might
still have it in my outbox.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In povray.general Ron Parker <ron### [at] povrayorg> wrote:
: You might be surprised.  Except for the arbitrary transforms (which make
: the problem different, but possibly not much more difficult) it's relatively 
: easy to decompose a matrix into rotations, scales, and translates.  I wrote
: the whole mess up for someone in c.g.r.r. a few years ago; I think I might
: still have it in my outbox.

  How do you decompose a matrix transformation which causes shearing to
rotations, scales and translates?
  For example think about this:

scale <1,.5,.8>
rotate <30,45,20>
scale <.8,.25,.5>
translate <2,3,4>
rotate <15,20,80>

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

Chris Huff wrote:

> Still, what *is* the location? A sphere has a center, but what is the
> center of a cone? The middle of the bounding box? The center of gravity?
> What is the "location" of an infinite plane? A complex mesh or CSG?
> Each object should have it's own variables available, but a single
> "location" variable for all of them isn't possible. Maybe a
> GetLocation() method for all objects in the finite object portion of the
> heirarchy, but you still have to define the location of an arbitrary
> object.
>

I apologize if I was unclear about this. Your previous post made me realize
that it's better to have object type specific attributes (like .origin for
sphere, .top & .bottom for cylinder, .corner1 & .corner2 for box, .normal
and .distance for plane, etc.)  which relate to the initial values given
when the object was created, and then separate .translation and .rotation
attributes (alt. getTranslation() & getRotation() methods). Collecting
information about an objects whereabouts should then be no problem - if the
.translation and .rotation attributes correspond to the respective values in
the transformation matrix of the object. Again, an example:

#declare ABox = box{
  <-1,-1,-1>,
  <1,1,1>
  translate <5,1,0>
}

Then:

ABox.corner1 = <-1,-1,-1>
ABox.corner2 = <1,1,1>
ABox.translation = <5,1,0>

...which means the exact position of "corner1" can be retrieved by

#declare corner1_pos = ABox.corner1 + ABox.translation;

I think this makes more sense, as an object always is created with some
parameters, and then translated/rotated various amounts. It should thus be
quite logical to collect info about an object my reversing the creation
process; think of it as setting the values at creation and getting the same
values at a later point.

Btw, check the VPython pages that ingo found:

http://virtualphoton.pc.cc.cmu.edu/projects/visual/
http://cil.andrew.cmu.edu/projects/visual/vpythonprog.htm

Not very far from POV-Script actually - except that it is object oriented,
of course.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

"Mikael Carneholm" <sa9### [at] idautbhbse> wrote in message
news:39A11AD5.5A347EF4@ida.utb.hb.se...

> I apologize if I was unclear about this. Your previous post made me
realize
> that it's better to have object type specific attributes (like .origin for
> sphere, .top & .bottom for cylinder, .corner1 & .corner2 for box, .normal
> and .distance for plane, etc.)  which relate to the initial values given
> when the object was created, and then separate .translation and .rotation
> attributes (alt. getTranslation() & getRotation() methods). Collecting
> information about an objects whereabouts should then be no problem - if
the
> .translation and .rotation attributes correspond to the respective values
in
> the transformation matrix of the object. Again, an example:
>
> #declare ABox = box{
>   <-1,-1,-1>,
>   <1,1,1>
>   translate <5,1,0>
> }
>
> Then:
>
> ABox.corner1 = <-1,-1,-1>
> ABox.corner2 = <1,1,1>
> ABox.translation = <5,1,0>
>
> ...which means the exact position of "corner1" can be retrieved by
>
> #declare corner1_pos = ABox.corner1 + ABox.translation;
>
> I think this makes more sense, as an object always is created with some
> parameters, and then translated/rotated various amounts. It should thus be
> quite logical to collect info about an object my reversing the creation
> process; think of it as setting the values at creation and getting the
same
> values at a later point.
>

Such an approach might work for simple primitives, but would fail on
anything more complex - how do you define a sensible reference point for a
blob? In addition, this is forcing a model onto POV that POV does not
actually use. Even if it was only implemented on simple primitives, it would
potentially lead new users astray.

Besides, your code could be rewritten as (I think):

#declare ABoxC1 = <-1,-1,-1>;
#declare ABoxC2 = <1,1,1>;
#declare ABoxTran = <5,1,0>;

#declare ABox = box{ ABoxC1, ABoxC2 translate ABoxTran }

#declare corner1_pos = ABoxC1 + ABoxTran;

Post a reply to this message

Ron Parker wrote:

> I don't understand this mindset.  If you need to know what transformations
> have been applied to object foo at some point in the future, keep track of
> what transformations you've applied.  What's so hard about that?

The main issue is the extremely hard extra work load ;-)

Well, there are situations when it just should be very convenient to be able to
collect info about an object by accessing the attributes of it. An example is in
a situation when you're writing an include file, and you want to access the
objects in the users file, without having to force the user to declare separate
values for camera locations, light source transformations etc. It's just a
question of simplicity and convenience.

An example - compare this:

camera{ location <0,1,-10>  look_at 0 }
#declare foo = light_source{ <50,50,-100> color rgb 1 }

...to this:

#declare camera_lookat = <0,1,-10>;
#declare object_position = <50,50,-100>;
camera{ location <0,1,-10>  look_at camera_lookat }
#declare foo = light_source{ object_position color rgb 1 }

Much less work needed to retrieve the look_at of the camera and the location of
foo using camera.look_at and foo.origin later in the file as provided in the fist
case, don't you agree? Much less work needed by the user, i.e....more user
friendly, to use a popular phrase... :)

Making POV-Ray (even) more user friendly at the same time as you're providing a
more powerful scripting language can't really be a bad thing, can it?

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

In article <39A123A1.5B90BD85@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

> Making POV-Ray (even) more user friendly at the same time as you're providing
> a more powerful scripting language can't really be a bad thing, can it?

Just wondering, what do you think is faster:

- Selecting a menu item in a menu (the menu bar is at the top of the screen)
- Using a keyboard shortcut


    Thorsten

Post a reply to this message

On 21 Aug 2000 05:28:18 -0400, Warp wrote:
>In povray.general Ron Parker <ron### [at] povrayorg> wrote:
>: You might be surprised.  Except for the arbitrary transforms (which make
>: the problem different, but possibly not much more difficult) it's relatively 
>: easy to decompose a matrix into rotations, scales, and translates.  I wrote
>: the whole mess up for someone in c.g.r.r. a few years ago; I think I might
>: still have it in my outbox.
>
>  How do you decompose a matrix transformation which causes shearing to
>rotations, scales and translates?
>  For example think about this:
>
>scale <1,.5,.8>
>rotate <30,45,20>
>scale <.8,.25,.5>
>translate <2,3,4>
>rotate <15,20,80>

It's been a while.  I think there were additional constraints on the solution.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Thorsten Froehlich wrote:

> Just wondering, what do you think is faster:
>
> - Selecting a menu item in a menu (the menu bar is at the top of the screen)
> - Using a keyboard shortcut

This is not comp.os.microsoft.windows.forgetting.keyboard.interaction - please post
to the proper group.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

In article <39A13586.CD67AD69@ida.utb.hb.se> , Mikael Carneholm 
<sa9### [at] idautbhbse>  wrote:

>> Just wondering, what do you think is faster:
>>
>> - Selecting a menu item in a menu (the menu bar is at the top of the screen)
>> - Using a keyboard shortcut
>
> This is not comp.os.microsoft.windows.forgetting.keyboard.interaction - please
> post to the proper group.

:-)   I am still curious what you think is faster ... I won't start a flame
war for either answer, just would like to know.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Tom Melly wrote:

> Such an approach might work for simple primitives, but would fail on
> anything more complex - how do you define a sensible reference point for a
> blob?

I don't think anything is impossible - until proven, of course. My suggestion
for blob as well as CSG objects or other complex objects is the use of a
.subobject[] property, along with a .subobject_count. An example:

#declare ABlob = blob {
    threshold .65
    sphere { <.5,0,0>, .8, 1 pigment {Blue} }
    sphere { <-.5,0,0>,.8, 1 pigment {Pink} }
    finish { phong 1 }
  }

The blob object lends itself nicely to OO, like this:

ABlob
    -subobject_count
    -subobject[0]
        -type //sphere or cylinder
        -origin  // as it is a sphere
        -radius
        -strength
        -pigment
    -subobject[1]
        ..
    -finish

(If some of the blob items had been a cylinder, there had been .top and .bottom
properties of subobject[0] instead of .origin.)

This means we can access our blob as in this example:

#declare i=0;
#while(i<ABlob.subobject_count - 1)
    #if(ABlob.subobject[i].type=0)    // type 0 = sphere, 1 = cylinder
        // do something using subobject[i].origin
    #else
        // do something using subobject[i].top, subobject[i].bottom
    #end
    #declare ABlob.subobject[i].radius = ABlob.subobject[i].radius + 1;
    #declare ABlob.subobject[i].strength = ABlob.subobject[i].strength + i / 10;

    #declare i=i+1;
#end

A CSG example:

#declare ACSG = difference{
    box{1,-1}
    difference{
        sphere{0, 1}
        plane{y, 0}
        translate <1,0,0>
    }
}

ACSG
    -subobject_count
    -subobject[0]    //the box
    -subobject[1]    //the sphere - plane difference
        -subobject_count
        -subobject[0]    // the sphere
        -subobject[1]    // the plane

We could now access the plane down in the hierarchy by

ACSG.subobject[1].subobject[1]

Similar for meshes, unions of bicubic patches, etc.

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

"Mikael Carneholm" <sa9### [at] idautbhbse> wrote in message
news:39A14052.36F8CD0F@ida.utb.hb.se...
> Tom Melly wrote:
>
> > Such an approach might work for simple primitives, but would fail on
> > anything more complex - how do you define a sensible reference point for
a
> > blob?
>
> I don't think anything is impossible - until proven, of course. My
suggestion
> for blob as well as CSG objects or other complex objects is the use of a
> .subobject[] property, along with a .subobject_count. An example:
>

<snip>

Hmm, well, yes... So blobs would need seperate syntax to handle
spherical/cylindrical components, and you still don't have an origin for the
blob as a whole. I guess I might be more positive if I understood how you
thought this would help POV. I don't do much pov-animation - is that where
you would see it as more useful? Still, while playing this game, I would
have thought that if one was going to settle for an arbitary "origin" for
all objects, the best point would be the first vector specified for the
object. So, for a blob, it would be the first point of the first component,
whether cylindrical or spherical.

BTW, and I've only played with this in my head, but I'm wondering if one
could take a perl-like approach to OOP in POV and bolt OOP on with some
well-written include files ( a bit unfair on perl, but you know what I
mean... probably). Hmm, the more I think about it, the more possible it
sounds. Probably falls into the catagory of "interesting but stupid", but
might be fun to play with.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> You might be surprised.  Except for the arbitrary transforms (which 
> make the problem different, but possibly not much more difficult) 
> it's relatively easy to decompose a matrix into rotations, scales, 
> and translates.  I wrote the whole mess up for someone in c.g.r.r. a 
> few years ago; I think I might still have it in my outbox.

But can you decompose the matrix into the *same* set of transforms which 
produced it?
My understanding is that there are often an infinite number of 
solutions. Getting the "orientation" might be useful, but what else 
would be possible?

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <39a127d9$1@news.povray.org>, "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> Just wondering, what do you think is faster:
> 
> - Selecting a menu item in a menu (the menu bar is at the top of the 
> screen)
> - Using a keyboard shortcut

Keyboard shortcut(assuming you already know the shortcuts). Otherwise, 
you have to use the menu(or keep the manual open).

Writing a particle system or other complex coding in POV-Script versus 
OOPov-Script: OOPOV-Script.

Learning the basics of using the above: neither.(the basics are exactly 
the same)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Tom Melly wrote:

> Hmm, well, yes... So blobs would need seperate syntax to handle
> spherical/cylindrical components, and you still don't have an origin for the
> blob as a whole.

Well, since blobs are made of the objects it consists of,  shouldn't one be able
to access the whole by accessing it's parts?

A little abstract maybe, but look at this:

3A={
    A1
    A2
    A3
}

If you remove A1, A2 and A3, then what's left of 3A? All 3A is is completely
defined by it's parts A1, A2 and A3, i.e

3A = A1+A2+A3.

Thus, to do something to 3A, you can just as well do something to it's parts A1,
A2 & A3, since they define 3A!

If you say a blob should have an origin, how do you define the origin - since
the object itself does not is nothing but a function between it's primitive
parts? It's primitive parts have origins though, so if it's the position of the
blob you're after you can use the positions of it's parts!


> I guess I might be more positive if I understood how you
> thought this would help POV. I don't do much pov-animation - is that where
> you would see it as more useful?

That's a good example of where it could come in handy, yes.

> Still, while playing this game, I would
> have thought that if one was going to settle for an arbitary "origin" for
> all objects, the best point would be the first vector specified for the
> object.

A common "location", "position", "origin" or whatever you want to call it is not
worth discussing. How do you define the location of a mesh or a union of
disjoint primitives? Accessing the values used to construct the objects together
with the objects .translation and .rotation vectors is a much better idea, and
you can probably achieve the same results that way.

> BTW, and I've only played with this in my head, but I'm wondering if one
> could take a perl-like approach to OOP in POV and bolt OOP on with some
> well-written include files ( a bit unfair on perl, but you know what I
> mean... probably).

As the current language is as good as any language can be at describing
primitives, I don't see any reason for changing that. Added OO is all that's
needed, so let's keep the other parts as it is.

> Hmm, the more I think about it, the more possible it
> sounds. Probably falls into the catagory of "interesting but stupid", but
> might be fun to play with.

Since when is something that's useful stupid?

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

Chris Huff wrote:

> Writing a particle system or other complex coding in POV-Script versus
> OOPov-Script: OOPOV-Script.
>
> Learning the basics of using the above: neither.(the basics are exactly
> the same)
>

I think I'm in love.

;-)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

In article <39A11AD5.5A347EF4@ida.utb.hb.se>, sa9### [at] idautbhbse 
wrote:

> I think this makes more sense, as an object always is created with 
> some parameters, and then translated/rotated various amounts. It 
> should thus be quite logical to collect info about an object my 
> reversing the creation process; think of it as setting the values at 
> creation and getting the same values at a later point.

You left out "matrix" and "scale" transforms.
What do you propose? Saving a certain group of points, so the 
orientation of the object could be obtained? Say, origin(which would be 
<0,0,0>), x, y, and z, which would be transformed with the object and 
retrievable later? This seems inefficient, why not just make the 
transform available, and transform vectors yourself?
Or do you want to add rotations and translations to member variables, so 
you can have the total rotation and translation applied to the object? 
How useful would this be?

I think you can do all you need by simply making the transformation 
matrix available to the user. If the user needs more, they can create a 
new object and override the rotate(), translate(), etc. methods 
themselves to do what they want.


> Btw, check the VPython pages that ingo found:
> 
> http://virtualphoton.pc.cc.cmu.edu/projects/visual/
> http://cil.andrew.cmu.edu/projects/visual/vpythonprog.htm
> 
> Not very far from POV-Script actually - except that it is object 
> oriented, of course.

This does look kind of interesting...especially this part: "We hope to 
have a Macintosh version by August 2000." :-)
However, it looks like it would be a pretty big adjustment from 
POV-Script. And it would need a bit of adjustment to fit with POV...it 
seems designed to do dynamic realtime animations, while POV does frames. 
And it looks like all objects are drawn, no matter what, I would prefer 
at least a draw() method so I can have objects which aren't drawn.
But it looks nice and efficient, just 12 lines...

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Thorsten Froehlich wrote:

> :-)   I am still curious what you think is faster ... I won't start a flame
> war for either answer, just would like to know.
>

Since my hands are resting on the keyboard and I only use the mouse when surfing or
when modelling in some 3d program, my answer is of course: the keyboard. Another way
to answer that question: I only use the mouse when I have to. :)

----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

Chris Huff wrote:

> You left out "matrix" and "scale" transforms.

I know...for simplicity I only mentioned translation and rotation.

> I think you can do all you need by simply making the transformation
> matrix available to the user. If the user needs more, they can create a
> new object and override the rotate(), translate(), etc. methods
> themselves to do what they want.

This is probably exactly what I'm looking for. That is, if the values used
to create the object are available also (like the first vector in the sphere
expression, the float value determining the radius, etc.). Note that
"origin" only applies to that first vector parameter in spheres and light
sources...(from what I currently can recall) - other objects use other
construction parameters, like the box with it's two vectors that probably
best could be called .corner1 & .corner2, or something like that. All that
should be object specific, as said before.

> However, it looks like it would be a pretty big adjustment from
> POV-Script. And it would need a bit of adjustment to fit with POV...it
> seems designed to do dynamic realtime animations, while POV does frames.
> And it looks like all objects are drawn, no matter what, I would prefer
> at least a draw() method so I can have objects which aren't drawn.
> But it looks nice and efficient, just 12 lines...
>

I don't want VPython to be the new OO POV-Script - but VPython could be seen
as an example of how nice and efficient it should be...nothing else.


----------------------------------------------------
Mikael Carneholm, B.Sc.
Dep. of Computer Science and Business Administration
UCB (University College of Borås) Sweden

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

Post a reply to this message

Ron Parker wrote:
> 
> On 21 Aug 2000 05:28:18 -0400, Warp wrote:
> >In povray.general Ron Parker <ron### [at] povrayorg> wrote:
> >: You might be surprised.  Except for the arbitrary transforms (which make
> >: the problem different, but possibly not much more difficult) it's relatively
> >: easy to decompose a matrix into rotations, scales, and translates.  I wrote
> >: the whole mess up for someone in c.g.r.r. a few years ago; I think I might
> >: still have it in my outbox.
> >
> >  How do you decompose a matrix transformation which causes shearing to
> >rotations, scales and translates?
> >  For example think about this:
> >
> >scale <1,.5,.8>
> >rotate <30,45,20>
> >scale <.8,.25,.5>
> >translate <2,3,4>
> >rotate <15,20,80>
> 
> It's been a while.  I think there were additional constraints on the solution.

Most algorithms to decompose matrices begin by assuming that the component
transforms were done in a particular order.  This generally works because the
predominant habit among modellers is to scale first, rotate second, and translate
third.  The resulting matrix can always be broken down into the original three
transforms (with a caveat in regards to rotation).

Note that the translate could have been the second or even the first
transform actually applied; however, simple examination of the resulting
matrix cannot reveal whether this is so.

Likewise, if shearing is present, there is no way to tell when or how it was
done.  Consequently the decomposing algorithm must make assumptions, which
may be wrong.

The only time one can make a useful guess at the order of operations is when
the matrix under consideration is a slight modification of a matrix whose
original transforms are already known.  Evn then it can be tricky.

Regards,
John

Post a reply to this message

In article <39A27BD2.C662EFED@erols.com>, John VanSickle 
<van### [at] erolscom> wrote:

> Most algorithms to decompose matrices begin by assuming that the 
> component transforms were done in a particular order.  This generally 
> works because the predominant habit among modellers is to scale 
> first, rotate second, and translate third.  The resulting matrix can 
> always be broken down into the original three transforms (with a 
> caveat in regards to rotation).

Ouch, I often rotate after translating or alternate rotation and 
scaling...I don't think this would work well. And how does it deal with 
things like rotations around an arbitrary axis? (which is a transform I 
have considered adding)
This does seem too unreliable, and the user could always override the 
macros to do what they want, like saving the transforms as they are 
applied.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Tue, 22 Aug 2000 10:21:49 -0500, Chris Huff wrote:
>Ouch, I often rotate after translating or alternate rotation and 
>scaling...I don't think this would work well. And how does it deal with 
>things like rotations around an arbitrary axis? (which is a transform I 
>have considered adding)

Provided that no skewing took place (that is, that you get three orthogonal 
vectors when you transform three orthogonal vectors) it deals quite well.
It just doesn't give you the results you may have expected.  

For example, 

translate x rotate 45*y 

is equivalent to 

rotate 45*y translate <sqrt(.5),0,-sqrt(.5)>

Similarly, 

rotate 45*y around_point x // if such a syntax existed

would be equivalent to

rotate 45*y translate <1-sqrt(.5),0,sqrt(.5)>

BTW, the transform you mentioned would probably be better implemented as 
a macro, but I think it's been done.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> BTW, the transform you mentioned would probably be better implemented as 
> a macro, but I think it's been done.

It has been done as a macro. There are three transforms I am 
considering: 

axis_rotate AMOUNT, AXIS  Rotates around a specified axis.

directional_scale AMOUNT, DIRECTION  Scales in a certain direction(like 
in the LiquidSpray include and the particle_stretch feature in my 
particle_system patch).

coordinate_system X, Y, Z  Takes three vectors for the new directions of 
each axis. This would make operations like shearing a lot easier.

These could all be done with macros, but might be nice if available 
built-in. Rotate, scale, and translate could also be done as macros(and 
maybe they would have been if macros had existed at the beginning), all 
that is really necessary is the matrix transform.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message