I'm confused here...I have a set of N co-planar points that are the vertices of a polygon. Each point obviously has xyz coordinates and also uv coordinates. Given a new point in x,y,z which is known to be in the plane of the face (and inside the boundary of the vertices), what is it's UV coordinate, assuming that the UV coordinate system has as little warping as possible but is continuous? edit -- my initial guess was to just take the weighted average of the uv coordinates of all the other points based on their distance, but this does not seem to be right.

Assuming that the UV of the Existing points are consistent with each other.

Just pick any 3 of them, and use their UV's to derive a local coordinate plane for the polygon.

Then you just project your new vert onto that plane, and it's coords are the UV...


If the existing UVs are Not consistent with one another - not a regular UV grid.
...then im not sure...
How about you do the same thing, but instead use the 3 verts Nearest to the new one to define the coordinate plane?
each new vert will need to find a new plane and new set of 3 nearest neighbors
-this ensures local continuity

add a new constraint- if more than one newVert is within the same 'neighborhood' then the one nearest to the center must be placed first; and the second guy must consider a new neighborhood where that first newVert counts as an Existing vert
-that should ensure things stay smooth; think of it as tesselation


***
heck, maybe you do what you suggested, buy instead weight them by inverse distance squared?

Well here's what happens when I use normalized inverse distance, or inverse distance squared, weighting:


Definitely not looking good! Here's my implementation:

int numFaceVerts = (int)vert_inds.size(), i;texpt.set(0.0f, 0.0f);float weight, sumWeight=0.0f;for(i=0; i<numFaceVerts; ++i){        weight = 1.0f/pow(calcDist(pos, parent->verts[ vert_inds ]), 2.0f);	texpt += parent->tverts*weight;	sumWeight += weight;}texpt /= sumWeight;

There's no guarantee what the texture verts would be, it's for a rendering engine, it should probably make the same decisions Max would make.

Maybe the local coord plane really is what I should do..

Quote:If the existing UVs are Not consistent with one another - not a regular UV grid.
...then im not sure...
How about you do the same thing, but instead use the 3 verts Nearest to the new one to define the coordinate plane?

I'll try this next. I think it might work well...but I am not really sure exactly what you mean tp project into a coordinate plane. How would I project? What would be the basis I am projecting into?

Quote:
add a new constraint- if more than one newVert is within the same 'neighborhood' then the one nearest to the center must be placed first; and the second guy must consider a new neighborhood where that first newVert counts as an Existing vert
-that should ensure things stay smooth; think of it as tesselation

This doesn't ensure continuity it ensures stochastic error propagation! but since I need to evaluate at all visible pixel points in the plane this would be very costly so thats not going to happen.

Ok, is this right?

1) Pick the closest 3 vertices (Va, Vb, Vc)

2) Define 2D basis B={b0,b1}

b0 = Vb - Va
b1 = b0 x (Vc - Va)

3) Project point P into this basis via multiplying by inverse of B

B^(-1)*P = Puv

4) Project Va,Vb,Vc into basis B as well (Ua, Ub, Uc)

5) Compute rate of change of U in b0 by the 2 points (Ub.x - Ua.x)

6) Compute rate of change of V in b1 by the points (Uc.y - Ua.y)

too many variables...im getting confused. Im thinking I should have an equation for a line in b0 and in b1 that i can useto get u and v..

That's very close! This is what I had in mind, almost identical to yours:

1) Pick three closest vertices's Va, Vb, Vc.

2) Create a 2D basis M = {b0,b1} in world-space.
b0 = Va - Vb
b1 = Vc - Vb

3) Solve for new point P in system M.

[ xM ] = [ b0x b1x ]-1 * [ Px - Vax ][ yM ]   [ b0y b1y ]     [ Py - Vay ]

4) Create a 2D basis N = {b0,b1} in UV-space.
b0 = Va - Vb
b1 = Vc - Vb

5) Plug in the solved coordinates (xM,yM) to get the new UV-coordinates for point P.

PUV = xM * [ b0x ]  +  yM * [ b1x ] + [ Vax ]          [ b0y ]          [ b1y ] + [ Vay ]

The only difference between the basis you create in (1) and in (4) is that in the first one you use world-coordinates (X,Y,Z), and in the second one you use texture-space coordinates UV. Note that you really only need (X,Y) and can ignore Z. And I apologize for the wacky ASCII math, some of it didn't align very well [totally]

I almost forget, since you're performing matrix inversion there are the usual degenerate cases - row(s) of all 0's, column(s) of all 0's, or linear dependence of either - which are an artifact of ignoring Z. You can "upgrade" to a full 3D basis with b2 = b0 x b1 to solve this problem, and just ignore zM.

[Edited by - Zipster on September 20, 2006 11:41:50 PM]

Cool, I will look over this tommorrow morning.

Although you will ignore Z when solving for the coordinates of the point in the basis, you made a mistake of ignoring Z in the computation of the basis because it affects it there.

What was your reason for not choosing an orthogonal basis? I'm not sure if that will work properly.

Ironically, I have already written the code to transform any point into the plane's basis, which I wrote as part of the process for checking point-in-plane, but I later found a much easier way to check that and almost deleted these funcs...good thing I didn't.

Quote:Original post by stuh505
Although you will ignore Z when solving for the coordinates of the point in the basis, you made a mistake of ignoring Z in the computation of the basis because it affects it there.

A plane can be described using two vectors, no matter the dimension. If we know that the point we're solving for is already on the plane, then there's no reason why we need more than those two vectors to solve for it. The problem is that the vectors might have more than two dimensions. The logical conclusion is to project them down to two dimensions by treating all the variable beyond X and Y as 0 (or in other words just ignoring them). For the most part that works, unless any of the coefficients for those variables are 0 in the plane equation, in which case projection won't work. So in all honestly I'd probably just use a 3D basis to solve for the point from the start, to avoid any problems like this.

Quote:Original post by stuh505
What was your reason for not choosing an orthogonal basis? I'm not sure if that will work properly.

By definition a basis only needs to be linearly independent so that it can span the entire space. Orthogonality is a nice property to have but all the math works out either way.

[Edited by - Zipster on September 21, 2006 2:35:41 AM]