Hi all! I found that when loading the mesh, the .obj file parser seemed to duplicate vertice with multiple texture coordinates. Like:

v 1 2 3
vt 1 2 3
vt 5 6 7
f 1/1 */* */*
f 1/2 */* */*

The parser seems to generate two different vertice for “v 1 2 3”, each of which corresponds to a different tex coord… So I was not able to recover the initial topology from the Subgeometry.indexData. Any way to fix it or bypass the problem? Thanks!

What you describe is actually completely necessary for any engine that wants to run on a GPU. UV coordinates are stored as vertex attributes in the GPU memory, so that they can be accessed (and interpolated) in vertex and fragment shaders. This means that UV coordinates have to be per vertex, which in turn means that if you want two sets of UV coordinates on the same point in 3D space, you will need to have two vertices stored in memory.

What is the problem that this is causing for you? What are you trying to do that doesn’t work when vertices are split to accommodate for UV (or vertex normal) data?

well I was trying to build a half-edge representation for some mesh operations like morphing/subdivision so I need to query for the neighboring vertex, but unfortunately some of the vertices have multiple uv coords. If the vertices are duplicated, the mesh topology information is incorrect and some vertices may have fewer neighbors.
Any ideas how I can get around this? Previously I was reading from Subgeometry.vertexData and Subgeometry.indexData. Thanks a lot!

It sounds like you will need to use some other representation than the raw GPU-optimized data representation used by Away3D (which, after all, is a rendering engine and should be optimized for rendering quickly.)

I see this quite often, tool developers relying too heavily on the rendering engine’s internal structures. It’s the equivalence of having a TextField where you print out a date in some format, and having that as the only place and only format that the date is stored in. When you want to add a couple of days, or calculate the time difference between this date and another, you suddenly have to read the text field, and parse it into a date object, before you can use it to do what you want. This is an absurd approach of course, and the right way would be to persistently store the date object and only rely on the text field for displaying it, according to a mini-MVC pattern if you will.

The same should apply to your use of Away3D, in almost all cases. In game engines there’s a ton of information that should not be stored within Away3D (like game character health, weapon damage information, player name et c) and that seems reasonable. But the same applies even in some cases where you’re only working with geometry, so if you need information that is more about topology and less about rendering requirements, you should store that information yourself, e.g. by building a representation of your mesh with dedicated vertex and triangle objects. That way you can store the relationships between vertices and the triangles they belong to directly, and you can store the UV coordinates on the triangles, and handle transparently the fact that the same vertex object might point into several different locations in the Away3D vertices vector.

This way you have a data model (your representation) as well as the visual representation (the one in Away3D) and you never have to query the visual representation for data that is more readily available through your data model.

This requires some more memory, but it will be faster once you have built the data model, so that’s probably a trade off you’re ready to live with if you’re building mesh editing functionality (where fast topology operations are more important than memory usage.)

Yeah you’re right I just relied too much on Away3D. I’ll parse and maintain the mesh data by my own. Thx for your help!