OK, and there is probably nothing wrong about it.

But I wonder if it would be possible to write a macro which does the
following:
1. Translate the Object which is specified by a parameter to the Origin
(with whatever point one chooses for the non-existing origin of the object)
2. Rotate or scale or whatever the Object by a specified (through a
parameter) amount
3. Translate the Object back to its place

It might be useful or not :-), but I don't know if it is possible to find
out where a Object is, say you have a sphere at <10,0,10>. Is it possible to
get this vector from the "sphere-statement" (without declaring it
previously)? Did not here about something like this yet.

Marc-Hendrik

Post a reply to this message

On Thu, 6 Jul 2000 20:58:49 +0200, Marc-Hendrik Bremer wrote:
>OK, and there is probably nothing wrong about it.
>
>But I wonder if it would be possible to write a macro which does the
>following:
>1. Translate the Object which is specified by a parameter to the Origin
>(with whatever point one chooses for the non-existing origin of the object)
>2. Rotate or scale or whatever the Object by a specified (through a
>parameter) amount
>3. Translate the Object back to its place

If you look through some (really) old posts on povray.windows you'll find 
some reference to macros that do what you want and more.  The post says 
they don't work due to a bug, but the bug's been fixed in 3.1g.  Here's
the relevant headers from the most useful post in the thread, but it's 
educational to read the whole thread (except the flamewar parts.)

From: par### [at] my-dejanewscom (Ron Parker)
Newsgroups:   povray.windows
Subject: Re: Local Transformations
Message-ID: <36962501.0@news.povray.org>
Date: 8 Jan 1999 10:32:17 -0500
Xref: news.povray.org povray.windows:2401

>It might be useful or not :-), but I don't know if it is possible to find
>out where a Object is, say you have a sphere at <10,0,10>. Is it possible to
>get this vector from the "sphere-statement" (without declaring it
>previously)? Did not here about something like this yet.

That doesn't make sense.  Where is a box?  Where is a complex mesh object?
Where is an isosurface that simulates an asteroid field?  Where is 
union {sphere{0,1} sphere {20,1}}?  (I think you'll find that this is covered
in more detail in the other thread, too.)

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

Post a reply to this message

"Warp" <war### [at] tagpovrayorg> wrote in message
news:<3964c652@news.povray.org>...
> Tom Melly <tom### [at] tomandluf9couk> wrote:
> : When you scale an object, all that POV does is to move all parts of the
> : object from their origin to their origin*scale.
>
>   Well, this is the impression you get, but strictly speaking it's not
true.
>   Povray doesn't move anything (it doesn't _add_ anything to the location
of
> the object).
>   Objects do NOT have origin. Povray does NOT know where the origin of an
> object is.
>   Ok, ok, let me take that back. Povray does know where the origin of an
> object is: It's at the global origin (ie. coordinates <0,0,0>). What I
meant
> was that in povray's inner world there's no such a thing as "object
origin".
>   Objects are basically mathematical functions with a matrix
transformation
> applied to it. Mathematical functions do not have "origins" except the one
> at <0,0,0>.

I realise this; however, it was explanations like this that confused the
hell out of me when I first started using POV ;) Actually, if you re-read
what I was said, you will see that we agree - just some of my terminology
differs (yours is more correct). For example, I in no way refer to objects
having an "origin" in the sense of "center". By "origin", I mean "the place
occupied by any point of an object before it is transformed", rather than
one absolute. In my examples I tried to make it plain that only that point
of an object whose origin (in my sense) resided at <0,0,0> before scaling
would remain in the same place (<0,0,0>). Even the text you posted from my
original post makes this clear ("all parts").

As for the rest, as I've said I can't find anything that really contradicts
in any fundamental way anything I wrote. More accurate, yes - but I'm not
sure how helpful matrixes are in newusers. "Move" may not be an accurate
word when talking about scaling, but it can be a helpful model when first
understanding transformations.

The trouble with learning to ray-trace is that you start with your standard
tiled floor reflecting sphere schtick, you get cocky, try modelling a
teapot, and suddenly your handle is in Havana. All you did was translate it
1 unit right (the problem is that that was before you scaled it by 500).

Post a reply to this message

Ron Parker schrieb in Nachricht ...
[...]
>From: par### [at] my-dejanewscom (Ron Parker)
>Newsgroups:   povray.windows
>Subject: Re: Local Transformations
>Message-ID: <36962501.0@news.povray.org>
>Date: 8 Jan 1999 10:32:17 -0500
>Xref: news.povray.org povray.windows:2401
>


Very interesting (that "Who is Thorsten Froehlich"-part was great :-)).

[...]
>That doesn't make sense.  Where is a box?  Where is a complex mesh object?
>Where is an isosurface that simulates an asteroid field?  Where is
>union {sphere{0,1} sphere {20,1}}?  (I think you'll find that this is
covered
>in more detail in the other thread, too.)


You are of course right and I get the point. But if you would define any
point related to the object  (say
<(maxx-minx)/2,(maxy-miny)/2,(maxz-minz)/2>) and return this if the function
Whereis{Object} is called, it would make some thinks easier (not much, but
sometimes it may help).

You could achieve this with the megapov-keywords min_extend and max_extend,
if I get this right. How accurate are the bounding boxes of the 'primitive'
pov-primitives like spheres, boxes, cones, cylinders? Is the object
'centered' in there. I know this is not a accurate term, 'course where is
the center? What I mean is: would min_extend.x and max_extend.x return -1
and 1 for a sphere{0,1}, a box{-1,1}, a cone {<-1,0,0>,1,<1,0,0>,2}?

I'm just curios, hope I do not annoy anyone :-)

Marc-Hendrik

Post a reply to this message

On Thu, 6 Jul 2000 22:24:08 +0200, Marc-Hendrik Bremer wrote:
>You could achieve this with the megapov-keywords min_extend and max_extend,
>if I get this right. How accurate are the bounding boxes of the 'primitive'
>pov-primitives like spheres, boxes, cones, cylinders? Is the object
>'centered' in there. I know this is not a accurate term, 'course where is
>the center? What I mean is: would min_extend.x and max_extend.x return -1
>and 1 for a sphere{0,1}, a box{-1,1}, a cone {<-1,0,0>,1,<1,0,0>,2}?

The keywords are min_extent and max_extent (t, not d.)  I wrote the
implementation, so I should know. 

They're generally pretty accurate for simple primitives, and in the four
cases you mentioned the object is centered in there.  If you have rotated
the objects, the bounding box gets larger rather than rotating, so there's
likely to be some space for them to rattle around in the box. 

CSG objects are likely to overbound, and some objects are just plain 
unbounded (poly springs to mind.)  I think it's probably better to just 
know what you want the center of the object to be and keep it in mind while 
you're designing it, then do any scales or rotations before translating 
it to the final location.  If you find it easier to work in terms of 
local or global transforms, (e.g. you want to rotate the table after you
translate it where you need it) then use the macros I posted in that other 
thread. (Remember to read the followup; it fixes an error.)
  
-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Thanks, I think I will just use the 'normal' way.

Marc-Hendrik

Post a reply to this message

Chris Huff wrote:
> "by a number smaller or greater than zero"
> "smaller" == "less than" == "below"
> :-)

:-(

markus

Post a reply to this message

Marc-Hendrik Bremer <Mar### [at] t-onlinede> wrote:
: But I wonder if it would be possible to write a macro which does the
: following:
: 1. Translate the Object which is specified by a parameter to the Origin
: (with whatever point one chooses for the non-existing origin of the object)
: 2. Rotate or scale or whatever the Object by a specified (through a
: parameter) amount
: 3. Translate the Object back to its place

  Quite trivial, I think:

#macro LocalTransform(LocalOrigin, Transformation)
  translate -LocalOrigin
  transform { Transformation }
  translate LocalOrigin
#end

  The same for individual transformations (rotate, scale) if wished

: out where a Object is, say you have a sphere at <10,0,10>. Is it possible to
: get this vector from the "sphere-statement" (without declaring it
: previously)? Did not here about something like this yet.

  As I said, objects do not have local origins.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Yes, reading more carefully I realize that I misunderstood a bit what
you were saying. I apologize if I offended you in any way.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

just testing a reply ... new account ... will delete asap

Post a reply to this message