 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
| 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] aol com> 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
|
|
| |
| |
|
|
|
|
| |
|
|
