 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly wrote:
> this is so trivial there is no reason to change the source code.
>
> --
> http://www.flash.net/~djconnel/
I don't believe it's any less trivial than wanting 4 demensional
vectors added to the source code. I have recently seen requests
for that too. Seems strange in light of the fact you can describe
any point in space with the current 3 demensional coordinate
system currently in use.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ken wrote:
>
> Dan Connelly wrote:
>
> > this is so trivial there is no reason to change the source code.
> >
> > --
> > http://www.flash.net/~djconnel/
>
> I don't believe it's any less trivial than wanting 4 demensional
> vectors added to the source code. I have recently seen requests
> for that too. Seems strange in light of the fact you can describe
> any point in space with the current 3 demensional coordinate
> system currently in use.
You can't apply built in vector ops to homebrew 4d vectors as it is.
This means that you have to do it explicitly with (slow) macros. With
4d position vectors, you can easily program things that use homogenous
coordinates (i.e. rational splines, making homebrew NURBS reasonably
easy). The image map thing is just a matter of an extra line of pov
code, 4d (and more) vectors make whole new capabilities feasible.
Jerry Anning
cle### [at] dhol com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Jerry Anning wrote:
> You can't apply built in vector ops to homebrew 4d vectors as it is.
> This means that you have to do it explicitly with (slow) macros. With
> 4d position vectors, you can easily program things that use homogenous
> coordinates (i.e. rational splines, making homebrew NURBS reasonably
> easy). The image map thing is just a matter of an extra line of pov
> code, 4d (and more) vectors make whole new capabilities feasible.
>
> Jerry Anning
> cle### [at] dholcom
I will concede the point but not my desires.
Ken Tyler
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Dan Connelly <djc### [at] flashnet> wrote:
: And if you want to count characters, just do "translate -0.5" .
"translate-.5"
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
From: Nieminen Mika
Subject: #declare ANY sized vectors (was: Re: Image Map Feature Question/Request)
Date: 16 Nov 1998 05:53:00
Message: <3650040c.0@news.povray.org>
|
|
|
| |
| |
|
|
Ken <tyl### [at] pacbellnet> wrote:
: I don't believe it's any less trivial than wanting 4 demensional
: vectors added to the source code. I have recently seen requests
: for that too.
It should be nice if povray supported ANY sized vectors.
For example, this should be very nice:
poly
{ 7, Poly1*clock+Poly2*(1-clock)
}
Where Poly1 and Poly2 are vectors with 120 components.
This would make a very nice morphing between two poly objects.
--
- Warp. -
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Nov 1998 19:53:21 +0200, Margus Ramst
<mar### [at] peakeduee> wrote:
>Yeah, I also agree that centering image_maps would be logical, but it has never
>annoyed me, so I haven't complained. Getting height_hields to look right is a
>pain anyway, so the translate -.5 thingy kinda doesn't matter. Still, you have a
>point.
Consider what this will do to the people and applications who expect
the current behavior, as well. Also, the only object I am aware of that
appears centered on the origin is the torus. Most objects are created
where you say they should be, and it's only the various modelers that
force them to be created at the origin.
>The other problem is much more important. I don't think it's very difficult (to
>somebody much wiser than me ;)). You shouldn't need any parametric mapping in
>many cases (like applying an image to only one side of a polygon or cylinder).
>This is how I imagine it: if the outside surface is hit by the sample ray,
>calculate the map color; if the inside is hit, don't calculate. This should be a
>sufficient solution in most cases (like the bottle label example).
This doesn't keep it from showing up on the outside surface opposite
the one you thought it would be on. One could predicate it on the
normal of the surface at the point of intersection, however.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Nov 1998 15:30:24 -0500, Nathan Kopp <Nat### [at] Koppcom> wrote:
>You could also get the SuperPatch from Twyst's patchstation, since it includes
>most of my surface-mapping code (I think it is currently lacking the code for
>lathe & sor). If you don't need the lathe/sor stuff, you should probably get
>the superpatch since it has all sorts of other really cool features. :-)
Right, not the lathe and sor patches. Also missing is the cool new
reset children warp. I promise I'll get these into the next version.
>Just remember... these are unofficial versions of POV so don't expect any help
>from the POV Team.
Absolutely true. If there's a problem with the superpatch, bug me. If you
use it and you love it, bug me. If you just think it's a good idea, bug me.
If there's a patch I missed (except motion blur, PVM, POVMan, and most of
the stuff in TMPOV with the possible exception of the julia texture) bug me.
I don't get near enough mail about the superpatch.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Nov 1998 06:10:38 -0800, Ken <tyl### [at] pacbellnet> wrote:
>Dan Connelly wrote:
>
>> I respectfully disagree. The documentation is incredibly clear.
>> A simple "translate <-0.5, -0.5, -0.5>" centers things -- this is
>> so trivial there is no reason to change the source code.
>>
>> --
>> http://www.flash.net/~djconnel/
>
>I respectfully disagree with your respectful disagreement.
>Your simple example is 28 characters long. That's a lot
>of simple typing. Nor does it redily explain the ambiguity.
I respectfully disagree with your characterization of the
situation as an ambiguity, since it's consistent among things
that use images. The real question is why image maps are on
the x-y plane and height fields on the x-z plane. I also
respectfully disagree with your contention that it's 28
characters... "translate -.5" is only 13.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Sun, 15 Nov 1998 23:33:33 -0500, Jerry Anning <cle### [at] dholcom> wrote:
>Ken wrote:
>>
>> Dan Connelly wrote:
>>
>> > this is so trivial there is no reason to change the source code.
>> >
>> > --
>> > http://www.flash.net/~djconnel/
>>
>> I don't believe it's any less trivial than wanting 4 demensional
>> vectors added to the source code. I have recently seen requests
>> for that too. Seems strange in light of the fact you can describe
>> any point in space with the current 3 demensional coordinate
>> system currently in use.
>
>You can't apply built in vector ops to homebrew 4d vectors as it is.
BTW, what is the cross product of two 4d vectors? :)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 16 Nov 1998 11:58:41 -0500, Ron Parker <par### [at] my-dejanewscom> wrote:
>Consider what this will do to the people and applications who expect
>the current behavior, as well. Also, the only object I am aware of that
>appears centered on the origin is the torus. Most objects are created
>where you say they should be, and it's only the various modelers that
>force them to be created at the origin.
Whoops, lathe and sor too. What about TTFs that are created from the
lower left corner?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
