gdalgorithms-list

Re: [Algorithms] Scaling Models

[<ro...@do...>]

Jamie Fowlston  wrote:

>Off the top of my head: to get the normal back, you need to perform the inverse
>scale on it, and renormalise.
>
>

The top of your head is correct.

Re: [Algorithms] Scaling Models

[<ro...@do...>]

Tom Hubina  wrote:

>I don't generally use scales on matrices this way (and the description is 
>atrocious from a math standpoint) so Ron can correct me here as needed, but 
>I seem to recall there being two ways to add a scale to a matrix. For a 
>non-uniform scale you can monkey with the different components to get what 
>ya need, or for a uniform scale you can insert the scale value directly 
>into the lower right corner of the matrix. 

Yes, for the uniform scale this is a trick that works in the context
of the 4x4 matrix, but it doesn't fall out until you do the
projection.  That is, you end up with points that have w != 1 before
projecting.  This is an ugly artifact of the 4x4 homogeneous
formulation, which I detest.  Part of its ugliness is that it doesn't
generalize to the non uniform scale.

>If you're doing a uniform scale, 
>and using homogenous matrices as I've described above you wouldn't need to 
>re-normalize the normal since the uniform scale would be ignored for 
>vectors (since the 4th component is zero). Vectors will still be affected 
>by the more traditional scales, and even if they're uniform, will need to 
>be normalized before they can be used in most lighting and environment 
>mapping situations.
>

And of course, in the case that the transformation contains within it
a non-uniform scale, you are completely wrong unless you
transpose(inverse(the upper 3x3)), before applying it to the normal
vectors. See my response to the original post of this thread.

Re: [Algorithms] Scaling Models

[<ro...@do...>]

Peter Warden  wrote:

>
><snipped stuff about scaling and normals>
>
>Just out of interest, one thing I did a while back when I needed to treat
>both normals and vertex positions uniformly when applying an animation
>matrix to them was set the W component of the normals to 0, whilst leaving
>the W component of the positions at 1. This worked because the animation
>matrix never contained a scale, and I just wanted to not translate the
>normals. Is this a well-known technique that I just haven't run across
>before, and is there any theoretical basis for it?
>

This would be the correct way to treat the w components WHETHER OR NOT
the transformation contains a scale.  It is inherent in the meaning of
"vector".  See my response to the original post of this thread.

Re: [Algorithms] Scaling Models

[<ro...@do...>]

Jim Offerman  wrote:

>I think OpenGL handles normals in the same way (and if I am not mistaken,
>OpenGL also uses some sort of inverse transform on normals, instead of
>feeding them to the 'normal' pipeline, which I presume is to counter the
>effects of scaling etc. on the normals...)
>

Actually it needs to apply the transpose of the inverse of the matrix
to the normals, then renormalize, to be always correct.  But this
would be wasteful in the majority of the cases that the
transformations are orthogonal.  APIs need to have a provision for the
programmer to hint whether of not the transformations are orthgonal. 

RE: [Algorithms] Scaling Models

[Tom H. <to...@3d...>]

At 11:18 AM 7/28/2000 +0100, you wrote:

><snipped stuff about scaling and normals>
>
>Just out of interest, one thing I did a while back when I needed to treat
>both normals and vertex positions uniformly when applying an animation
>matrix to them was set the W component of the normals to 0, whilst leaving
>the W component of the positions at 1. This worked because the animation
>matrix never contained a scale, and I just wanted to not translate the
>normals. Is this a well-known technique that I just haven't run across
>before, and is there any theoretical basis for it?

Yeah, the general term I see used for it is homogenous matrices.

I set up my math libs to work with a class that describes a 4x4 homogenous 
matrix, a class that describes a 1x3 vector and a derived class that 
describes a 1x3 point. The matrix class has overloaded functions for 
multiplication where one takes a point and the other takes a vector. When a 
vector is used, the unspecified fourth component is assumed to be 0. When a 
point is used, the unspecified fourth component is assumed to be 1. In both 
cases the matrix math is simpler than a full transform since the constant 
allow some of the operations to be removed. I also have a 1x4 vector class 
for general transforms.

I don't generally use scales on matrices this way (and the description is 
atrocious from a math standpoint) so Ron can correct me here as needed, but 
I seem to recall there being two ways to add a scale to a matrix. For a 
non-uniform scale you can monkey with the different components to get what 
ya need, or for a uniform scale you can insert the scale value directly 
into the lower right corner of the matrix. If you're doing a uniform scale, 
and using homogenous matrices as I've described above you wouldn't need to 
re-normalize the normal since the uniform scale would be ignored for 
vectors (since the 4th component is zero). Vectors will still be affected 
by the more traditional scales, and even if they're uniform, will need to 
be normalized before they can be used in most lighting and environment 
mapping situations.

Tom

Re: [Algorithms] Scaling Models

[Jim O. <j.o...@in...>]

I think OpenGL handles normals in the same way (and if I am not mistaken,
OpenGL also uses some sort of inverse transform on normals, instead of
feeding them to the 'normal' pipeline, which I presume is to counter the
effects of scaling etc. on the normals...)

Jim Offerman

Innovade
- designing the designer
----- Original Message -----
From: "Peter Warden" <Pet...@vi...>
To: <gda...@li...>
Sent: Friday, July 28, 2000 12:18 PM
Subject: RE: [Algorithms] Scaling Models


>
> <snipped stuff about scaling and normals>
>
> Just out of interest, one thing I did a while back when I needed to treat
> both normals and vertex positions uniformly when applying an animation
> matrix to them was set the W component of the normals to 0, whilst leaving
> the W component of the positions at 1. This worked because the animation
> matrix never contained a scale, and I just wanted to not translate the
> normals. Is this a well-known technique that I just haven't run across
> before, and is there any theoretical basis for it?
>
> Peter Warden
> Visual Sciences
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list
>

RE: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Tony C. <to...@mi...>]

>There we go, that's the nice mathematical definition.  A curve
>
>f:R -> R^d
>
>(for a curve in d-dimensional space)
>is Gn if there exists any remapping function
>
>g:R -> R
>
>(constraints on g below) such that
>
>f(g()) is Cn
>
>That means that C0 and G0 are the same.  I suspect
>g must be 'reflexive' or whatever the math word is,
>where it maps all values to unique other values,
>and therefore is invertible.  I think g must also be C0
>but not necessarily C1...

The word you probably want is "bijection" which implies that for each value
y in R there exists one and only one x such that g(x) = y.

All is clear now.

Thanks,

Tony Cox - DirectX Luminary
Windows Gaming Developer Relations Group
http://msdn.microsoft.com/directx 

Re: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Charles B. <cb...@cb...>]

At 12:40 PM 7/28/2000 +0200, you wrote:
>Geometric continuity:
>"A curve is said to be Gr if there exists a regular reparametrization after
>which it is Cr"
>So what about C0 and G0 ?

There we go, that's the nice mathematical definition.  A curve

f:R -> R^d

(for a curve in d-dimensional space)
is Gn if there exists any remapping function

g:R -> R

(constraints on g below) such that

f(g()) is Cn

That means that C0 and G0 are the same.  I suspect
g must be 'reflexive' or whatever the math word is,
where it maps all values to unique other values,
and therefore is invertible.  I think g must also be C0
but not necessarily C1...


--------------------------------------
Charles Bloom           www.cbloom.com

Re: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Lorenzo P. <lp...@ti...>]

> >> I don't thing there is any meaning of "G0".
> >For two segment curves it means they join together, G0 is "geometric
> >continuity".
> >If directions (but non necessarily the magnitudes)  of the two segments'
> >tangent vectors are equal at joing point, the curve has G1.
> >For more details check out Foley Van-dam. 480-483
>
> Are you sure? That is saying that G0 == C0, which makes me slightly
> uncomfortable given than Gn!=Cn for n>0.

I'm sure that Gn!=Cn for n>1 ... but I'm confused about C0 and G0.
did you check the reference ? there's another from "Curves and surfaces for
computer aided geometric design" Farin's one. page 183

Geometric continuity:
"A curve is said to be Gr if there exists a regular reparametrization after
which it is Cr"
So what about C0 and G0 ?

TIA,
    Lorenzo Pallara

RE: [Algorithms] Scaling Models

[Peter W. <Pet...@vi...>]

<snipped stuff about scaling and normals>

Just out of interest, one thing I did a while back when I needed to treat
both normals and vertex positions uniformly when applying an animation
matrix to them was set the W component of the normals to 0, whilst leaving
the W component of the positions at 1. This worked because the animation
matrix never contained a scale, and I just wanted to not translate the
normals. Is this a well-known technique that I just haven't run across
before, and is there any theoretical basis for it?

Peter Warden
Visual Sciences

RE: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Tony C. <to...@mi...>]

>> I don't thing there is any meaning of "G0".
>For two segment curves it means they join together, G0 is "geometric
>continuity".
>If directions (but non necessarily the magnitudes)  of the two segments'
>tangent vectors are equal at joing point, the curve has G1. 
>For more details check out Foley Van-dam. 480-483

Are you sure? That is saying that G0 == C0, which makes me slightly
uncomfortable given than Gn!=Cn for n>0.

Tony Cox - DirectX Luminary
Windows Gaming Developer Relations Group
http://msdn.microsoft.com/directx 

Re: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Lorenzo P. <lp...@ti...>]

> I don't thing there is any meaning of "G0".
For two segment curves it means they join together, G0 is "geometric
continuity".
If directions (but non necessarily the magnitudes)  of the two segments'
tangent vectors are equal at joing point, the curve has G1. 
For more details check out Foley Van-dam. 480-483

Lorenzo Pallara

Re: [Algorithms] Scaling Models

[Davide P. <da...@pr...>]

> If you set a scaling matrix as part of the transformation pipeline what
> happens to the normals?
> I currently use D3D\OpenGL to do the transformation but use my own
lighting
> code. If I set a scaling factor to each of the 3 axes the angles of most
of
> the faces in the model will change (unless the scaling factor is the same
> for all three axes). An extreme example is when XSc=ZSc=1.0f; YSc=0.0f;
All
> normals will either become 0,0,0 (for triangles with a normal
perpendicular
> to the Yaxis) or 0,1,0 for all other normals.
>
> Rebuilding the normal list is not an option as the models are shared
> multiple times with different scalings.
>
> Anybody else encountered this problem? And how does D3D\OpenGL cater for
> this?

There is a very nice doc on opengl site called :

Avoiding 19 Common OpenGL Pitfalls

oglpitfall.pdf

Written by Mark J. Kilgard that cover this topic.


Davide Pirola
www.prograph.it
www.protonic.net

[Algorithms] OBBs & Max

[<Nik...@ao...>]

I'm resending this message to the list, because oddly it showed up with the 
wrong subject and from the wrong person when reading it with AOL mail (I'm 
not sure if it was just a problem with AOL, or with the list), but I 
apologize for those of you who are receiving this post twice.

Recently, I've been creating an OBB collision detection system for my engine, 
and I loosely used the RAPID library as a guide when creating my own 
functions.  The data that I use originates from 3D Studio Max 3.1.  I have 
been having much difficulty with the accuracy of the system, so I attempted 
to use the RAPID library itself to see if that functioned correctly.  
However, the RAPID library is giving the same results as my own, it 
inaccurately reports collision with even the most simple models (such as two 
boxes, in which only one has rotation).  Is there a problem with the library, 
or with Max?  The data I am receiving from Max displays correctly when 
rendered with D3D (in the exporter I change the coordinate system from Max's 
to D3D's).  Could this change in coordinate systems be the problem?  In this 
transformation, I change the order of the vertices on each face, and I flip 
rows 2 and 3 in the transformation matrix, along with the y & z coordinates 
in the matrix and the vertices.   Also, when a box is created in Max, it is 
defined with the center being at the bottom of the box, and the rotation and 
translation matrix compensate for this (depending on where the pivot point is 
located), to make the scene look correct.   (As I mentioned earlier, the when 
I render this data in D3D, it looks exactly like what it did in Max, in 
addition, the collision detection is accurate if neither model is rotated.  
Any help would be appreciated.

Thanks,
Nik...@ao...

RE: [Algorithms] Scaling Models

[John W. <jo...@de...>]

I sat down after I sent the message and came to the conclusion that in the 
general case I'd have to scale the normals too and perform a normalization 
per normal which is completely out of the question as the impact on the 
performance will be too excessive.

I'm either going to do one of two things.
1) Ignore it and live with the slightly wrong lighting. I don't let the 
relative scales differ by too much as I don't trust the Mip-LOD functions 
when you get high U:V coverage ratios, so the effect shouldn't be too 
noticeable if at all.

2) make a copy of each model and recalculate the normals. The models which 
get scaled are quite low poly so the extra memory shouldn't be too much of 
a problem. I was planning to do this anyway to maximize the number of pols 
in the static VBs.

I use the API to do the Local->Screen xforms but all the lighting xforms is 
completely in software so HW TnL isn't hampered. The API never sees the 
normals, I pass verts through in LVERTEX format. I was just wondering what 
D3D\OpenGL would do if I passed the normals through which is why I didn't 
mail to those groups. Thanks for the HW TnL warning though.


JohnW

-----Original Message-----
From:	Tom Hubina [SMTP:to...@3d...]
Sent:	27 July 2000 21:15
To:	gda...@li...
Subject:	Re: [Algorithms] Scaling Models

At 05:06 PM 7/27/2000 +0100, you wrote:
>If you set a scaling matrix as part of the transformation pipeline what
>happens to the normals?
>I currently use D3D\OpenGL to do the transformation but use my own 
lighting
>code. If I set a scaling factor to each of the 3 axes the angles of most 
of
>the faces in the model will change (unless the scaling factor is the same
>for all three axes). An extreme example is when XSc=ZSc=1.0f; YSc=0.0f; 
All
>normals will either become 0,0,0 (for triangles with a normal 
perpendicular
>to the Yaxis) or 0,1,0 for all other normals.
>
>Rebuilding the normal list is not an option as the models are shared
>multiple times with different scalings.
>
>Anybody else encountered this problem? And how does D3D\OpenGL cater for
>this?

In GL the normals are scaled and rotated by the modelview matrix
(homogenous matrix stuff ... translations are ignored). GL allows you to
normalize the transformed normals with:

glEnable(GL_NORMALIZE);

This does come with an added per-normal cost, but on T&L cards like the
GeForce, the operation is done by the hardware so you don't lose the
ability to use hardware transforms. I don't know if there is a similar
operation under DX, but it seems likely.

Something just dawned on me though, you use the API do the transforms, but
you do your own lighting ... If you're querying the API for the results of
the transformations you're really going to ruin performance on hardware T&L 

cards. If you don't need the transformed coordinates to do your lighting,
then you probably don't need to send normals to the API at all. They're
only used for lighting and some of the texture coordinate generation modes
(spherical I think).

Specific OpenGL and Direct3D issues should be taken to their respective
mailing lists.

Tom



_______________________________________________
GDAlgorithms-list mailing list
GDA...@li...
http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

Re: [Algorithms] Scaling Models

[Tom H. <to...@3d...>]

At 05:06 PM 7/27/2000 +0100, you wrote:
>If you set a scaling matrix as part of the transformation pipeline what
>happens to the normals?
>I currently use D3D\OpenGL to do the transformation but use my own lighting
>code. If I set a scaling factor to each of the 3 axes the angles of most of
>the faces in the model will change (unless the scaling factor is the same
>for all three axes). An extreme example is when XSc=ZSc=1.0f; YSc=0.0f; All
>normals will either become 0,0,0 (for triangles with a normal perpendicular
>to the Yaxis) or 0,1,0 for all other normals.
>
>Rebuilding the normal list is not an option as the models are shared
>multiple times with different scalings.
>
>Anybody else encountered this problem? And how does D3D\OpenGL cater for
>this?

In GL the normals are scaled and rotated by the modelview matrix 
(homogenous matrix stuff ... translations are ignored). GL allows you to 
normalize the transformed normals with:

glEnable(GL_NORMALIZE);

This does come with an added per-normal cost, but on T&L cards like the 
GeForce, the operation is done by the hardware so you don't lose the 
ability to use hardware transforms. I don't know if there is a similar 
operation under DX, but it seems likely.

Something just dawned on me though, you use the API do the transforms, but 
you do your own lighting ... If you're querying the API for the results of 
the transformations you're really going to ruin performance on hardware T&L 
cards. If you don't need the transformed coordinates to do your lighting, 
then you probably don't need to send normals to the API at all. They're 
only used for lighting and some of the texture coordinate generation modes 
(spherical I think).

Specific OpenGL and Direct3D issues should be taken to their respective 
mailing lists.

Tom

Re: [Algorithms] Scaling Models

[Jamie F. <j.f...@re...>]

Off the top of my head: to get the normal back, you need to perform the inverse
scale on it, and renormalise.

Pass on the D3D / OpenGL gubbins, never used either :)

Jamie


John White wrote:

> If you set a scaling matrix as part of the transformation pipeline what
> happens to the normals?
> I currently use D3D\OpenGL to do the transformation but use my own lighting
> code. If I set a scaling factor to each of the 3 axes the angles of most of
> the faces in the model will change (unless the scaling factor is the same
> for all three axes). An extreme example is when XSc=ZSc=1.0f; YSc=0.0f; All
> normals will either become 0,0,0 (for triangles with a normal perpendicular
> to the Yaxis) or 0,1,0 for all other normals.
>
> Rebuilding the normal list is not an option as the models are shared
> multiple times with different scalings.
>
> Anybody else encountered this problem? And how does D3D\OpenGL cater for
> this?
>
> ----
> John White
> Senior Software Engineer
> Deep Red Games Ltd.
> jo...@de...
>
> Privileged/Confidential Information may be contained in this message.  If
> you are not the addressee indicated in this message (or responsible for
> delivery of the message to such person), you may not copy or deliver this
> message to anyone.  In such case, you should destroy this message and
> kindly notify the sender by reply email. Please advise immediately if you
> or your employer does not consent to Internet email for messages of this
> kind.  Opinions, conclusions and other information in this message that do
> not relate to the official business of my firm shall be understood as
> neither given nor endorsed by it.
>
> _______________________________________________
> GDAlgorithms-list mailing list
> GDA...@li...
> http://lists.sourceforge.net/mailman/listinfo/gdalgorithms-list

[Algorithms] Scaling Models

[John W. <jo...@de...>]

If you set a scaling matrix as part of the transformation pipeline what 
happens to the normals?
I currently use D3D\OpenGL to do the transformation but use my own lighting 
code. If I set a scaling factor to each of the 3 axes the angles of most of 
the faces in the model will change (unless the scaling factor is the same 
for all three axes). An extreme example is when XSc=ZSc=1.0f; YSc=0.0f; All 
normals will either become 0,0,0 (for triangles with a normal perpendicular 
to the Yaxis) or 0,1,0 for all other normals.

Rebuilding the normal list is not an option as the models are shared 
multiple times with different scalings.

Anybody else encountered this problem? And how does D3D\OpenGL cater for 
this?

----
John White
Senior Software Engineer
Deep Red Games Ltd.
jo...@de...

Privileged/Confidential Information may be contained in this message.  If 
you are not the addressee indicated in this message (or responsible for 
delivery of the message to such person), you may not copy or deliver this 
message to anyone.  In such case, you should destroy this message and 
kindly notify the sender by reply email. Please advise immediately if you 
or your employer does not consent to Internet email for messages of this 
kind.  Opinions, conclusions and other information in this message that do 
not relate to the official business of my firm shall be understood as 
neither given nor endorsed by it.

Re: [Algorithms] "N-Patches" (ATI/DX8 triangle bezier heuristic)

[Conor S. <cs...@tp...>]

> >joint, but it would suddenly change speed (which it wouldn't do with
> >C1).  G1 or G2 is really what we care about for graphics, C1 and C2
> >are unecessarily strong constraints.
>
> Unless you're doing chrome mapping in which case you'd see the anomaly as
> the object moved..

Unless of course the hardware calculated normals on a per point basis for
re-texture coord calculation. Which I imagine they do :)

Conor Stokes

RE: [Algorithms] C1 vs G1 (Was: "N-Patches")

[Tony C. <to...@mi...>]

>I don't thing there is any meaning of "G0".  In equations,
>C(n) and G(n) conditions for connecting parametric lines
>are:
>
>let V(u) be a vector-valued function of the scalar parameter u,
>with u in [0,1]
>similarly for W(u).
>
>Then C0/G0 is V(1) = W(0)
>
>C1 is V'(1) = W'(0)
>
>where a prime (') indicates differentiation with respect to the
>parameter, and V'(1) implicitly means
>
>  [ d/du V(u) ] @ u=1
>
>Then G1 is
>
>Normalize[ V'(1) ] = Normalize[ W'(0) ]
>
>Similarly for Cn, just do n differentiations.

I'm just trying to get a picture in my head of this. I've always used a
somewhat more general definition of what C(n) continutity means:

For a function f:A->B where A and B are metric spaces:

f is C(n) continuous at y <=> f is n-times differentiable at y and the nth
derivative is continuous.

I think what you're saying is the same thing as what I'm saying. I'd just
like the neatness of being able to say G(n) means C(n-1) continuous with the
added condition that the n-1th derivative satisfies the condition I gave for
G0 continuity (with the obvious norm induced on B via the metric).

I guess the difference is that my background is in pure maths, where we
would use a more general definition of C(n) continuity (anything that
involves talking about a specific range of a finite-dimensional parameter
space seems a little sloppy to me), but where I never came across the G(n)
beast. Whereas the G(n) concept is clearly useful in computer graphics
(which I'm guessing is your background) in relation to parametric surfaces
so that is the way you wind up defining it.

Tony Cox - DirectX Luminary
Windows Gaming Developer Relations Group
http://msdn.microsoft.com/directx 

[Algorithms] OBBs & Max

[<Nik...@ao...>]

Recently, I've been creating an OBB collision detection system for my engine, 
and I loosely used the RAPID library as a guide when creating my own 
functions.  The data that I use originates from 3D Studio Max 3.1.  I have 
been having much difficulty with the accuracy of the system, so I attempted 
to use the RAPID library itself to see if that functioned correctly.  
However, the RAPID library is giving the same results as my own, it 
inaccurately reports collision with even the most simple models (such as two 
boxes, in which only one has rotation).  Is there a problem with the library, 
or with Max?  The data I am receiving from Max displays correctly when 
rendered with D3D (in the exporter I change the coordinate system from Max's 
to D3D's).  Could this change in coordinate systems be the problem?  In this 
transformation, I change the order of the vertices on each face, and I flip 
rows 2 and 3 in the transformation matrix, along with the y & z coordinates 
in the matrix and the vertices.   Also, when a box is created in Max, it is 
defined with the center being at the bottom of the box, and the rotation and 
translation matrix compensate for this (depending on where the pivot point is 
located), to make the scene look correct.   (As I mentioned earlier, the when 
I render this data in D3D, it looks exactly like what it did in Max, in 
addition, the collision detection is accurate if neither model is rotated.  
Any help would be appreciated.

Thanks,
Nik...@ao...

[Algorithms] how to unsub by email

[Chen G. <Che...@ub...>]

I will begin a new job next month, so I want to unsub this maillist for
a while, could anyone tell me how to unsub it by email ?
Brian, could you remove me from this list?

Chen Gang

RE: [Algorithms] "N-Patches" (ATI/DX8 triangle bezier heuristic)

[Jason M. (A. Technologies) <v-j...@mi...>]

Charles writes:

> I worked on this for
> a while, and decided it wasn't such a hot thing to do, because
> you can't even guarantee G1 continuity

    One key aspect of N-Patches that we haven't explained well (and which
invariably generates these kinds of questions) is that normals for the new
vertices are computed by either linear or quadratic interpolation.   That
is, while the position of the surface is not G1, the normals are, which is
as good as being C1 for rendering purposes (both lighting and environment
mapping).  Since we're not machining automobile fenders, but, rather,
rendering video games, we have found this to be an acceptable approximation.
Indeed, it is what will allow this patch type to be implemented in Silicon
in the near term.

> So, first of all, I remember hearing that this heuristic was
> invented by the wise Charles Loop.  Is that correct?

    He had some input into the process.  Specifically, the denominators in
the equation for generating the middle control point from the other 8
control points was tuned by him.  That equation:

           middle = (SumOfBorderPoints/4) - (SumOfOriginalVertices/6)

     Aside from that, this is an ATI-developed scheme.  People have done
similar tricks in the past, but the N-Patch mechanism for generating the
edge control points (refer to the GDC slides Charles references) is novel as
far as we are aware.

> Are there any papers on this?

   Not yet.  We're working on that.

   I'm really pleased to see so much interest in using these primitives.
Please be ready to take advantage of these by understanding and coding for
them now.  Feel free to send any further questions my way.

   On a related note, while the tools exist to edit polygonal meshes, tool
vendors have not allowed you to edit normals directly.  With N-Patches
coming along, I think this would be an outstanding enhancement to your
authoring tools (in addition to providing an N-Patch modifier or previewer).
If you're of like mind, petition your tool vendor today.  While we are able
to write N-Patch previewer plug-ins (let me know if you want the binary and
source for the MAX plug-in we've written), the lack of native support for
actual vertex normals in the tools is what hinders normal-editing
functionality, thus the impetus is on the tool vendors to help the community
out in this way.  Do lobby them if this is something you care about.

              -JasonM at ATI

RE: [Algorithms] "N-Patches" (ATI/DX8 triangle bezier heuristic)

[Jason M. (A. Technologies) <v-j...@mi...>]

    Check out the "Character Animation Techniques for Accelerated HW" ppt
from GDC.  I'll weigh in on this topic soon.  It's great to see so much
interest in this surface.

                  -JasonM at ATI




> -----Original Message-----
> From: Kelmenson, Dan [mailto:Dan...@br...]
> Sent: Wednesday, July 26, 2000 2:13 PM
> To: 'gda...@li...'
> Subject: RE: [Algorithms] "N-Patches" (ATI/DX8 triangle bezier
> heuristic)
> 
> 
> Which link is this referring to?  I couldn't find any link on that page
that
> seems to be the article you are referring to.
> 
> > -----Original Message-----
> > From: Charles Bloom [mailto:cb...@cb...]
> > 
> > Well, ATI's posted this on their website, so I guess we
> > can talk about it freely now.
> > 
> > http://www.ati.com/na/pages/resource_centre/dev_rel/devrel.html
> > 
> > I don't give a hoot about the DX8 implementation of this, I
> > want to talk about the algorithm of making a curved triangle
> > only using its vertices and normals.  I worked on this for
> > a while, and decided it wasn't such a hot thing to do, because
> > you can't even guarantee G1 continuity, so I abandonded
> > it and moved on to butterfly subdivision, where continuity 
> > can be gauranteed.
> > 

RE: [Algorithms] "N-Patches" (ATI/DX8 triangle bezier heuristic)

[Kelmenson, D. <Dan...@br...>]

Which link is this referring to?  I couldn't find any link on that page that
seems to be the article you are referring to.

> -----Original Message-----
> From: Charles Bloom [mailto:cb...@cb...]
> 
> Well, ATI's posted this on their website, so I guess we
> can talk about it freely now.
> 
> http://www.ati.com/na/pages/resource_centre/dev_rel/devrel.html
> 
> I don't give a hoot about the DX8 implementation of this, I
> want to talk about the algorithm of making a curved triangle
> only using its vertices and normals.  I worked on this for
> a while, and decided it wasn't such a hot thing to do, because
> you can't even guarantee G1 continuity, so I abandonded
> it and moved on to butterfly subdivision, where continuity 
> can be gauranteed.
>