UVW's in COFFEE - desperate plea

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/03/2003 at 23:40, xxxxxxxx wrote:

User Information:
Cinema 4D Version:   7.3
Platform:    Mac ; Mac OSX ;
Language(s) :   C.O.F.F.E.E ;

---------
Ok, I'm writing a COFFEE plugin to dump vertex coordinates, normals, and texture uv coordinates into a custom format for use in an opengl app I'm writing.

My problem is with the UVWTag being sort of unreliable. When I'm writing the four UV coordinate sets for each poly to a text file, I get incorrect mapping when it loads in my opengl app. However, this ONLY seems to happen when I use a UVW tag that was generated by the "Generate UVW Coordinates" menu command in C4D (i.e. not the one that just shows up when I make an object editable).

So specifically my question is this:

How should I access the UVWTag data to best get global UV texture coordinates for each polygon vertex? Currently I'm retrieving them something like this:

  
var uvw_tag = current_object->GetFirstTag(); //or whatever, but I make sure 'uvw_tag' is a UVWTag.  
var uvw_data = uvw_tag->GetData();  
  
//and to access uvw's for a polygon number 'n':  
uvw_data[ 3*n + 0 ] //for first vertex  
uvw_data[ 3*n + 1 ] //for second vertex  
uvw_data[ 3*n + 2 ] //for third vertex  
uvw_data[ 3*n + 3 ] //for fourth vertex  
  
//this code is sort of based off of an example in the COFFEE docs

So somehow I'm thinking its not quite that straightforward? If there's a better way I'm all ears. Could the problem perhaps lie with polygons that are triangles? Like would the UVW tag not store duplicate UVW coordinates for a poly that has verts 3 and 4 identical? I tried a workaround to correct for that, but it made things even worse. Feel free to explain things to me in language that you might use with a dim, hearing impaired child: I'm experienced with OpenGL but very new to COFFEE.

BTW - I hope this isn't a really dumb question, but what is the 'W' in UVW mapping? I understand the implication of U and V (taking a 2d object, like a texture, and applying it to a 3d surface) but what on earth is the W there for? When I access it in coffee, its always 0... so as of the moment I just ignore W and only use U and V in my opengl app, since opengl just wants 2d texture coordinates for 2d textures (makes sense...). I have looked breifly online, and there is a shocking silence about this 'W' parameter... I once read someone casually say something about converting UVW to UV... please tell me this is simple, or better yet uneccessary.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/03/2003 at 12:40, xxxxxxxx wrote:

Hi,
In C4D, triangles are represented internally as quads with the fourth vertex index the same as the third one. In this case, I don't think that the UVW coordinates for the fourth vertex have any particular value, and you shouldn't be trying to use them.

I believe that the 'W' coordinate can be used with procedurals so that uvw specifies the coords in 'procedural' space, rather than the vertex coords, but I've never managed to get W to do anything either...

Cheers - Steve

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 19/03/2003 at 14:46, xxxxxxxx wrote:

Steve -

Thanks for the help, but I think I have the problem fixed now. What seems to be occurring is that C4D sometimes give me "backwards" U values. (i.e. 1-U instead of U). So I just set a "mirror U" flag in my file format that I can set for models that do this, and then they load into my app ok. This is a bit of a hack... but it does solve my problem for now. If anyone has any idea why this is happening then I'd be very grateful if you could explain it to me.

- Jeff

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 17/05/2005 at 20:47, xxxxxxxx wrote:

I had the same problem, and after reading this topic, I still had the errors. Then I realized that, a polygon has 4 vertecies, so instead of skipping 3 sets of UV coordinates like the first post:
UVw_data[ 3*n + 0 ] //for first vertex
UVw_data[ 3*n + 1 ] //for second vertex
UVw_data[ 3*n + 2 ] //for third vertex
UVw_data[ 3*n + 3 ] //for fourth vertex
You Skip 4
UVw_data[ 4*n + 0 ] //for first vertex
UVw_data[ 4*n + 1 ] //for second vertex
UVw_data[ 4*n + 2 ] //for third vertex
UVw_data[ 4*n + 3 ] //for fourth vertex
That solved my problem.

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 18/05/2005 at 01:31, xxxxxxxx wrote:

Well spotted that man!

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 09/11/2006 at 19:03, xxxxxxxx wrote:

Just one thing... each UVW coordinate should have two values, right? I mean, a X and a Y value, between 0 and 1.
So, that does UVw_data[4*n] returns me? Just one value? Or is it a vector?

Rui Batista

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/11/2006 at 02:19, xxxxxxxx wrote:

to access the UVWs you write something like this:

  
var uvcount = uvwtag->GetDataCount();  
var uvw = uvwtag->GetData();  
var i;  
for(i=0; i<uvcount; i++)  
{  
println(tostring(uvw[i*4+0]));  
println(tostring(uvw[i*4+1]));  
println(tostring(uvw[i*4+2]));  
println(tostring(uvw[i*4+3]));  
}

The UVWs are vectors.

cheers,
Matthias

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 10/11/2006 at 03:35, xxxxxxxx wrote:

Thank you

Rui Batista

Helper

THE POST BELOW IS MORE THAN 5 YEARS OLD. RELATED SUPPORT INFORMATION MIGHT BE OUTDATED OR DEPRECATED

On 15/11/2006 at 00:49, xxxxxxxx wrote:

Just an FYI...
>> I mean, a X and a Y value, between 0 and 1.
...actually, UV values can be negative and can be greater than 1 or less than -1. You can verify this by setting the X/Y Tiling values on a material that's applied to some object before you make it editable.
Most 3D apps will treat these out-of-0to1-range values as a means of either tiling (repeating) the texture across the surface or as a means of utilizing the entire 0-1 uv space by multiple mesh parts of the same mesh object.
For example, a typical Poser humanoid mesh has a 0-1 Head mapping, as well as a 0-1 Body mapping (along with a few other maps for transparency pieces, etc.). If you load one of these meshes into UVMapper (or BodyPaint's UV Edit mode), you'll see a big messy jumble of these maps overlayed on top of each other in the 0-1 space.
If you want to export the model into ZBrush, you have to make sure that there are no overlapping UVs. You can select each of these 'uv islands' (some set of uvs within the mesh that use the entire 1-0 space) and tile them out to the side, into the 1-2 space, and/or 2-3 space, for example. This makes ZBrush happy and C4D and Poser (and most other 3D apps - and if I recall, OpenGL as well) will treat these tiled maps as if they were still sitting in the 0-1 space.