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

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

Ron Parker wrote:

> I don't get near enough mail about the superpatch.

  I have been waiting for you to finish the updated documentation
before downloading your superpatch version. Once this occurs
expect email :)

Ken Tyler

Post a reply to this message

Ron Parker wrote:
> Whoops, lathe and sor too.  What about TTFs that are created from the
> lower left corner?

... and superelipsoids, of course, which raises the question of why
superellipsoids are symmetric in x and y while almost everything else
is symmetric in x and z.

It's clear the only consistency in POV is there is no consistency.
It's like UNIX and basically every other piece-meal project.... the
inconsistency just adds to its attractive character.

> what's the cross-product of two 4-d vectors?

Good question!  I expect it would take 3 vectors to yield a cross
product :

y_i = a_j b_k c_l e_ijkl

(a, b, c are 4-vectors, e is a matrix)

where e_ijkl = 0 for and two elements of {i,j,k,l} equal,
+1, or -1 in other cases.

But cross products of 3-d vectors don't yield vectors, but pseudovectors,
as the result depends on handedness.  Either this or my physics background
is too faded for such details.

Dan
-- 
http://www.flash.net/~djconnel/

Post a reply to this message