In article <38CBB90F.7C4AC93F@pacbell.net>, lin### [at] povrayorg 
wrote:

> Name one scenario where you would need to do this with an object of
> this complexity.

A forest of trees and/or other plants. A fleet of space ships. A flock 
of birds or a school of fish. A garden scene.
Oh, you said *one* scenario. Sorry. :-)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Chris Huff wrote:
> 
> In article <38CBB90F.7C4AC93F@pacbell.net>, lin### [at] povrayorg
> wrote:
> 
> > Name one scenario where you would need to do this with an object of
> > this complexity.
> 
> A forest of trees and/or other plants. A fleet of space ships. A flock
> of birds or a school of fish. A garden scene.
> Oh, you said *one* scenario. Sorry. :-)

Now correct me if I am wrong here but Warp wants the texture to NOT
translate along with the object. Now if I were to make a complex
tropical fish with multiple textures I can tell you right now I
would want my textures to stay where I put them. If you don't you
will have textures lining up in all the wrong places. With trees
you might have leaf textures where bark is supposed to be and with
a fleet of space ships you might have glass where the hull texture
is supposed to be. I don't understand your examples at all.

-- 
Ken Tyler -  1300+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <38CBC0EF.C3BD1DA5@pacbell.net>, lin### [at] povrayorg 
wrote:

> Now correct me if I am wrong here but Warp wants the texture to NOT
> translate along with the object. Now if I were to make a complex
> tropical fish with multiple textures I can tell you right now I
> would want my textures to stay where I put them. If you don't you
> will have textures lining up in all the wrong places. With trees
> you might have leaf textures where bark is supposed to be and with
> a fleet of space ships you might have glass where the hull texture
> is supposed to be. I don't understand your examples at all.

With a tree, the leaves would be separate textures from the bark. Moving 
the tree without moving the textures would mean that the colors of the 
leaves would change, and the bark would be different for each tree, but 
they would still look like trees(with nearly identical shapes, but the 
different colorations would disguise much of that).
With space ships, glass would have a different texture than the hull 
plates. Each ship would have different sets of hull plates and other 
features, but each texture would be applied where it is supposed to be.
With fish, the same goes. Different fish would have different patterns 
of colors, but the textures would be applied in the same place.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Precisely.
I found it useful (applying textures *after* certain transforms) in making a
variety of wood planks, all consisting of the same 'type' of wood, marble,
what have you, but this is absolutely essential to camoflage patterns and
the like.
  It used to come handy in halo-type flames, as well.

Grim
gri### [at] isonet

Post a reply to this message

"Chris Huff" wrote:

> Yes, I want to make many(Like 100 or so) different versions of it, each
> scaled, rotated, and with a matrix transform in addition to being
> translated. Can you do that too? :-)

A workaround : make your object a macro like #macro
myObject(currentTransform).

I hope this helps,


Philippe

Post a reply to this message

In article <38ce5f44@news.povray.org>, "Philippe Debar" 
<phi### [at] hotmailcom> wrote:

> A workaround : make your object a macro like #macro
> myObject(currentTransform).
> 
> I hope this helps,

Yes, that is possible, and I often do my objects this way so I can 
incorporate other randomized elements for a little more realism. But a 
way to translate an object and not it's texture, some kind of flag for 
the transform {} blocks, would still be useful sometimes. It would 
require you to use the transform {} block to enclose your 
transformations, but this might be a good idea anyway...and it would 
only be for a few small cases that you would want to do this.

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

As I wrote : a workaround.

Post a reply to this message

Chris Huff <chr### [at] yahoocom> writes:

> In article <38ce5f44@news.povray.org>, "Philippe Debar" 
> <phi### [at] hotmailcom> wrote:
> 
> > A workaround : make your object a macro like #macro
> > myObject(currentTransform).
> > 
> > I hope this helps,
> 
> Yes, that is possible, and I often do my objects this way so I can 
> incorporate other randomized elements for a little more realism. But a 
> way to translate an object and not it's texture, some kind of flag for 
> the transform {} blocks, would still be useful sometimes. It would 
> require you to use the transform {} block to enclose your 
> transformations, but this might be a good idea anyway...and it would 
> only be for a few small cases that you would want to do this.

IMHO it would be more "clean" to introduce a way to invert a transformation.
As far as I know, the inverse matrix is already calculated internally.
(The struct TRANSFORM has the two members "matrix" and "inverse".) 
So, the implementation should be easy.

Then you would get the desired effect like this:

#declare Trans = transform { translate .. rotate .... }
#declare InvTrans = transform { invert_transform Trans }
object { ... texture { ... transform{InvTrans} } transform {Trans} }

Just my 0.02 Euro
Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message

In article <qqm### [at] schlattfmiuni-konstanzde>, Thomas 
Willhalm <tho### [at] willhalmde> wrote:

> IMHO it would be more "clean" to introduce a way to invert a 
> transformation.
> As far as I know, the inverse matrix is already calculated internally.
> (The struct TRANSFORM has the two members "matrix" and "inverse".) 
> So, the implementation should be easy.
> 
> Then you would get the desired effect like this:
> 
> #declare Trans = transform { translate .. rotate .... }
> #declare InvTrans = transform { invert_transform Trans }
> object { ... texture { ... transform{InvTrans} } transform {Trans} }

While I agree that something like this would be useful(as a matter of 
fact, I have been considering it for my next project), I don't see how 
it helps in pretextured objects. If your example is used, you don't even 
need inverse_transform, you could write it like this:

#declare Trans = transform { translate .. rotate .... }
object { ... transform {Trans} texture { ... } }

However, many times, an object is composed of many parts with different 
textures, your solution requires that everything be #declared and 
assembled separately.

Really, I think a way to access CSG sub-objects and their 
textures/transformations/interiors/flags through a dot notation would be 
the best and most elegant way to do things. MegaPOV has taken some steps 
toward this already. Some way to attach variables and macros to objects 
would also be very useful.

-- 
Christopher James Huff - Personal e-mail: chr### [at] yahoocom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/

Post a reply to this message

Chris Huff <chr### [at] yahoocom> writes:

> In article <qqm### [at] schlattfmiuni-konstanzde>, Thomas 
> Willhalm <tho### [at] willhalmde> wrote:
> 
> > IMHO it would be more "clean" to introduce a way to invert a 
> > transformation.
> > As far as I know, the inverse matrix is already calculated internally.
> > (The struct TRANSFORM has the two members "matrix" and "inverse".) 
> > So, the implementation should be easy.
> > 
> > Then you would get the desired effect like this:
> > 
> > #declare Trans = transform { translate .. rotate .... }
> > #declare InvTrans = transform { invert_transform Trans }
> > object { ... texture { ... transform{InvTrans} } transform {Trans} }
> 
> While I agree that something like this would be useful(as a matter of 
> fact, I have been considering it for my next project), 

:-)

> I don't see how 
> it helps in pretextured objects. If your example is used, you don't even 
> need inverse_transform, you could write it like this:

You're right. Perhaps I should use more pretextured objects, since I didn't
really understand the problem...

Thomas

-- 
http://thomas.willhalm.de/ (includes pgp key)

Post a reply to this message