I’m parsing an FBMesh - using the FBGeometry API to get vertex and vertex detail values out of the mesh inside of the ORSDK in Motion Builder 7.5.2b

However, even though the mesh itself does have a material + texture attached, the UV coords I get from VertexUVGet are always 0. There’s *defintely* a texture on this mesh but I have no idea where the UV Coords actually are if they aren’t in the VertexUVGet call (I mean, that’s where I’d expect to get them?).

The texture is set to UV coordinate mode, although thats really post the geometry values since that’s at a shader level rather than a UV specification level.

The UVMapping mode is set to UVMappingModeSurface, which, while explaining why I’m not getting per vertex UV’s, doesn’t explain where they actually are.

Now I’m suspecting that this has something to do with the FastTessellator, however I can’t find any example useage of that in any of the samples, neither can I actually get to use the values in code since I just linkage errors the moment I try and access any of the functions within the FBTessellator class. Awesome.

Help?

JakeSimpson 02 November 2009 05:11 PM

The UVMapping mode is set to UVMappingModeSurface, which, while explaining why I’m not getting per vertex UV’s, doesn’t explain where they actually are.
Help?

that’s basically mean the geometry (mesh) itself doesn’t contains any texture UV coordinate. Since texture has UV mapping mode, so it will automatically compute texture UV coordinates as Projection_XY mode. that’s why you can see the texture appears to be mapped on the model properly.

if you save your model in ASCII format, you can get more information regarding your mesh format.

If you still have problem, you can upload your model, and I can have at look at it.

Yeah, that’s kinda what I figured was going on - the UV’s are being generated in real time at render time. It’s not efficient but it explains why I’m not getting the UV’s out of the vertex data.

I figured that this is actually what the FBTessellator class does? I think it actually generates arrays that get handed to the renderer (Normals, vertex array and UV array), however it’s hard to actually know because a) there is zero documentation on what it does (I’m just going from where it’s been included as an instance, IE in FBGeometry, and what’s actually inside the class) and b), any attempt to use the FBTessellator instances that are inside of FBGeometry result in linkage errors, which means that the header files are including a class that’s not actually in the distributed fbsdk.lib supplied with MoBu 7.5.2b.

Awesome.

I can’t push the model up here because this is a movie asset - totally not a good thing to do, pushing that out into the world.

I don’t know if it’s the same in 7.5 since I have only used 2009 & 2010.

In 2009 you get the UVs from FastTessellator.GetUVArray() where FastTessellator = HFBGeometry.FastTessellatorPolygon. In 2010, GetUVArray (and GetPositionArray and GetNormalArray) moved to HFBGeometry. The array is organized differently from the position or normal arrays, so you need the index from FastTessellator.UVIndex[n] where n is the current vertex (sorted by polygon vertexes).

The way it’s generally done is:

For what it sounds like you are trying to do, I don’t know if this is the best method to use (or if it is the only). But this is the method I know, and I know that it works. I haven’t found a case where vertex and normal indexes were different, and usually the UV array is a flat list of all the UVs (there are as many elements as there are total polygon vertexes) with the index array simply being equal to its index, i.e. UVIndex[n] = n.

And like I said, I haven’t used 7.5 so hopefully this has the appearance of making sense within that version’s ORSDK. It tends to change quite a bit between versions.

I got nothin

Hi, I have a similar problem - on the tessellator polygon, GetUVArray() returns back a null pointer and the geometry VertexCount() is reporting no vertices at all. Is it sensible to call the tessellator from within the DeformerNotify? Why would there be no vertices when the mesh obviously has them?