Start a new topic

Do textures for Mesh Primitives assume only 3 vertices?

Original Post by: MarcFlores Tue Sep 10 22:45:58 2013


I'm having issues with textures for "some" of my meshes. We have two types of mesh primitive types in our data: triangle and polygon. Triangle prims have 3 vertices, and polygon prims can have any number of vertices.


OpenFlight textures are working great for our triangle prims, but not for our polygon prims. I'm using the same exact code for both, and I don't assume 3 vertices anywhere, so both should work identically. I use this for both types (is MPRIM_INDEXED_POLY okay for both types?):


mgMeshPrimitiveSetType(db_mesh, db_prim_index, MPRIM_INDEXED_POLY) )


The interesting thing is when I look at the FLT file in a viewer it appears like my polygons (in this case simple squares) are bisected into triangles. That is it looks like my square polygon is now 2 triangles, and the texture is repeating on each triangle. I set the prim vertex indices array this way, and the last parameter seems to indicate that OpenFlight can handle any number of vertex indices:


mgMeshPrimitiveSetVtxIndexArray(db_mesh, db_prim_index, vinds, v_index.size()) )

Original Post by: SteveThompson Wed Sep 11 00:02:27 2013


OpenFlight textures are working great for our triangle prims, but not for our polygon prims. I’m using the same exact code for both, and I don’t assume 3 vertices anywhere, so both should work identically. I use this for both types (is MPRIM_INDEXED_POLY okay for both types?):

Use MPRIM_INDEXED_POLY for primitives that are not MPRIM_TRI_STRIP (triangle strips), MPRIM_TRI_FAN (triangle fan) or MPRIM_QUAD_STRIP (quadrilateral strip). Indexed Polygons can have any number of vertices (3 or 4 in your case, no problem).


The interesting thing is when I look at the FLT file in a viewer it appears like my polygons (in this case simple squares) are bisected into triangles. That is it looks like my square polygon is now 2 triangles, and the texture is repeating on each triangle.

Your viewer may be reducing your quads to triangles in order to draw them. This is not necessarily incorrect. Creator, for example, reduces all n-gons to triangles before rendering them in the scene. If the original n-gon is coplanar you should not be able to tell the difference. How can you tell your viewer is not drawing correctly? This is unclear from the information you've provided.


I set the prim vertex indices array this way, and the last parameter seems to indicate that OpenFlight can handle any number of vertex indices

That is correct... when you call mgMeshPrimitiveSetVtxIndexArray, you are telling the API how many vertices this primitive has. And each element of the array you provide is an index into the mesh vertex pool. So if this MPRIM_INDEXED_POLY is a triangle, you will specify 3 indices. Similarly if the MPRIM_INDEXED_POLY is a quad, you will specify 4 indices.


Sorry I don't fully understand your problem. Can you please clarify? Thanks.


Also, have you looked at the sample plugin in the SDK (called meshtest). There is a "mesh editor" tool there that constructs mesh nodes using different styles of primitives.

Original Post by: MarcFlores Wed Sep 11 14:47:37 2013


Thanks, I will look at meshtest.


Sorry I was not very clear in the OP. I can't fathom why some of my meshes are good, and others not, so I was just throwing out what I could, and hoped something would stick. Maybe pictures would help.


The mesh.jpg image attached shows what I mean (hopefully). The red arrows show what looks like bisecting lines on the four sided face primitives. The yellow arrows illustrate why I say it looks like each triangle has a repeating, sort of mirror image texture of its counterpart triangle on each four sided face.


The mesh_texture.jpg image attached is the texture image used. The green texture that looks like bushes in the bottom left corner is what should be textured on to the top face shown in mesh.jpg. So you see we slam several textures into one image, but the texture coordinates should handle that fine. We are also NOT using any repeating textures, so that shouldn't be an issue.

Original Post by: MarcFlores Wed Sep 11 17:09:48 2013


A follow up. I feel like I'm missing something, because all of the sides of the mesh are showing textures, even though I don't call mgMeshSetVtxUV for every vertex. That is, I use mgMeshPrimitiveSetVtxIndexArray to create a primitive, but how does OpenFlight know if that primitive has textures? I set the MMESH_VTXUV0 bit on the mesh, and I call mgMeshSetVtxUV for every vertex that is part of a prim that does have a texture. Of course there are prims that should NOT have texture that might share a vertex with a prim that does have texture.


So does OpenFlight only texture a primitive if "all" off its vertices have UV coords, or is there a step I'm missing that indicates whether an individual prim should have texture (as opposed to using MMESH_VTXUV0 for the entire mesh)?

Original Post by: SteveThompson Thu Sep 12 14:07:27 2013


That is, I use mgMeshPrimitiveSetVtxIndexArray to create a primitive, but how does OpenFlight know if that primitive has textures?
If the mesh has texture, then all the primitives have texture. You set the texture index on the mesh node itself and the UVs on the vertices of the vertex pool of the mesh. A characteristic of a mesh is that all the primitives "share" the same attributes (color, texture, material, etc).

Of course there are prims that should NOT have texture that might share a vertex with a prim that does have texture.
As noted above, this is not possible. If any prim has texture (the mesh has texture) all prims have texture.

So does OpenFlight only texture a primitive if “all” off its vertices have UV coords, or is there a step I’m missing that indicates whether an individual prim should have texture (as opposed to using MMESH_VTXUV0 for the entire mesh)?
If you want some prims to have texture and some to NOT have texture, you need to make 2 mesh nodes, one that is textured and one that is not. Put the textured prims into the first mesh, the untextured prims in the second mesh.
Original Post by: MarcFlores Thu Sep 12 14:38:43 2013


Oh, okay, thanks. Any comments on reply #2?

Original Post by: SteveThompson Thu Sep 12 15:00:43 2013


Oh, okay, thanks. Any comments on reply #2?
Sorry did not see this one...

To me, these don't look like the quad is bisected. I think these images can be explained by the texture not being setup correctly on the prims (UVs). If you like, post this OpenFlight file and we can know for sure. We can examine here in Creator and tell you exactly what the problem is.

Original Post by: MarcFlores Thu Sep 12 16:23:35 2013


Okay, please see the attached ZIP file.

Original Post by: SteveThompson Thu Sep 12 16:39:56 2013


Looked at your file in Creator and have attached some telling images.

The top is an "exploded" view of your mesh in Creator showing each of the primitives. Looks like you have 6 Irregular Polygon primitives (quads). No quad is "bisected" geometrically.


The bottom image is your UV map as shown in the Modify UVs tool in Creator. Looks like many (if not all) of the quad primitives are not "mapped" correctly. The texture is drawing exactly as it is mapped (which is not correct) and that is what is making your geometry look bisected (the lines of the texture are making you think there are polygon "edges" where there are not).


So, it looks like the problem is your setting of the UVs on the vertex pool vertices. I wonder if the problem is related to the "1-V" trick in your other post support/discussions/topics/1760. Perhaps not all the V values you have assigned have been calculated correctly using this trick in that the image you have is a composite image (as your is)? Either way, looks like the UVs on this model are not correct.

Original Post by: MarcFlores Thu Sep 12 16:47:36 2013


Oh, that's cool! I wish we had Creator.


So, for composite textures is there another trick, or do I need to force non-composite textures? I've seen another trick where you find the MAX V value and use that instead of 1 (i.e. max_v - v), but I think that's more for handling repeating textures.


What about repeating textures? Does OF know how to deal with V values greater than 1, or do I need to force non-repeating UV coords too?

Original Post by: SteveThompson Thu Sep 12 16:51:55 2013


I noticed another anomaly in your file. The texture (tex_1_0.jpg) is in the texture palette 3 times. I suspect you don't really want that. The attached image is a "listing" of the textures in your palette in Creator.


I'll answer your last question next...

Original Post by: SteveThompson Thu Sep 12 17:05:46 2013


So, for composite textures is there another trick, or do I need to force non-composite textures? I’ve seen another trick where you find the MAX V value and use that instead of 1 (i.e. max_v - v), but I think that’s more for handling repeating textures.
I was not suggesting this trick does not work - I was just making sure you applied it correctly. For example, if you applied the trick to the UVs of the original images (before they were composited), the values won't work in the composite. At the end of the day, you just have to make sure the UV values you assign to the mesh vertices are the UVs you want from the image. See the attached image. I suggest you draw up a similar diagram for your geometry and texture and make sure the UV values you assign are the values you think they are.


What about repeating textures? Does OF know how to deal with V values greater than 1, or do I need to force non-repeating UV coords too?
Yes, OpenFlight handles repeating textures fine...so to repeat a texture 2 times across a quad, you'd set UVs to (0,0), (2,0), (2,2), (0,2) (bottom left to upper left CCW).
Original Post by: MarcFlores Wed Sep 18 17:36:46 2013


Finally getting a chance to get back to this. Ok, so a question I have now is, "Does OpenFlight expect only one (u,v) pair per vertex in a mesh?"


I did as you suggested, and mapped out my vertices and texture coordinates, and noticed that I can have different (u,v) pairs for the same vertex if that vertex is shared by different primitives. So I do call mgMeshSetVtxUV multiple times with the same vtxIndex but different (u,v) values. I don't know if this is making sense to you, so let me try listing the mapped out values as well.


The first list of 4 numbers are the vertex indices that make up that primitive, and the list of coordinates are the (u,v) pairs (we use x and y respectively in this context) for those vertices. Notice for example for vertex #2 I have 3 different (u,v) pairs assigned for 3 different primitives. The prims without texture coords don't have any textures assigned to them.


[4](2,0,1,3),

[4]({m_x=0.00000000 m_y=0.42452830 },{m_x=0.12442624 m_y=0.42452830 },{m_x=0.12928760 m_y=0.98002064 },{m_x=0.0033530556 m_y=1.0000000}


[4](0,2,7,6),

[4]({m_x=0.64907652 m_y=0.00000000 },{m_x=1.0000000 m_y=0.00000000 },{m_x=1.0000000 m_y=0.29245284 },{m_x=0.64907652 m_y=0.29245284}


[4](1,0,6,5),


[4](3,1,5,4),

[4](2,3,4,7),

[4]({m_x=0.00000000 m_y=0.00000000 },{m_x=0.64907652 m_y=0.00000000 },{m_x=0.64907652 m_y=0.42452830 },{m_x=0.00000000 m_y=0.42452830}


[4](4,5,6,7))

Original Post by: SteveThompson Wed Sep 18 20:06:50 2013


Finally getting a chance to get back to this. Ok, so a question I have now is, “Does OpenFlight expect only one (u,v) pair per vertex in a mesh?”

Yes, just one UV per mesh vertex.

I did as you suggested, and mapped out my vertices and texture coordinates, and noticed that I can have different (u,v) pairs for the same vertex if that vertex is shared by different primitives. So I do call mgMeshSetVtxUV multiple times with the same vtxIndex but different (u,v) values. I don’t know if this is making sense to you, so let me try listing the mapped out values as well.

You can't do this. The vertex is shared (completey) by the primitives. The vertex can ONLY be shared if it has the same XYZ, UV, normal and color. If you set the UV more than once, only the last value "sticks", every "set" after the first overwrites the previous "set". If a vertex can't be shared by multiple prims, simply add another vertex. That new vertex can have the same XYZ as another vertex but have a different UV. Seems like that is what you need.

Original Post by: MarcFlores Wed Sep 18 20:30:22 2013


Okay, I'll try that out. In the meanwhile, would you mind terribly taking a look at another FLT file for me? I was hoping you could compare it to the one I attached to post #7 of this thread, and compare and contrast how the mesh is built in that one versus the mesh in this one.


The mesh in the FLT file attached to this post was created in the old way that we have done it, and that works how I want it to. I wrote a plug-in to Safe Software's FME software, and they are taking what I give them and using your API to somehow create the mesh as we want it. So they must be doing something differently than I am.


A few things I'm wondering:

1. It looks like they have multiple copies of the same texture image in the Textures folder. Are they somehow using different texture files for each primitive face of the cube?

2. If so, how is that possible? Is this in fact a single mesh with 6 primitives, or did they do something differently than I am (e.g. these are actually 6 meshes, not a single, 6 faced mesh)?

3. If it is a single, 6 faced mesh, how are they managing faces with no textures?

4. If it is a single, 6 faced mesh, how are they managing to make shared vertices have multiple (u,v) coords, or are they?


Thanks for any time you can give this.

Login to post a comment