Can anyone recommend a workflow for subgrouping meshes within an OBJ that I’ll be loading into a Loader3D? I’m trying to determine the best way to get at a specific mesh (named?) within an OBJ. For example, let’s say I have one OBJ with two cubes. How would I go about isolating them during the parsing process. This may be an issue of how to export the OBJ more than actually parsing the OBJ. It seems when we export our OBJ from our 3D authoring environment the groups are nuked. What’s the best way to group submeshes?

Just to be clear in the hopes of getting some info:

I have a test, and in the AssetEvent.Complete handler i have assigned to the Loader3D instance, I’m getting four meshes: obj1, obj2, obj3, obj4

I’d like to be able to tag or name the individual meshes before exporting them from our modeler’s IDE. Is there a recommended workflow?

Additionally, inside the OBJ file, I can see the four different meshes and see that they have group names. How do I access the g identifier during the parsing process? The Mesh(event.asset).name is coming across as “obj0, obj1..” not the identifier we assigned in the OBJ.

Meshes are renamed as obj+count by default, this is how it worked till few weeks ago to prevent null names. Now that we have a smart library taking care of this, it’s no longer required. Plus the library allows you to decide how the engine handles the names. (see AssetLibrary.namingStrategyPreference).

For now, the parser gives the prefix obj + meshcount during the parsing.

The names of group, if found, should be set on the parent container as the group is the equivalent to Away’s ObjectContainer3D. It was like this from Away3D 1.0 up to 3.6. This feature got somehow lost during the update. It’s on the todo.

What the parser do not support yet (and probably will not be waterproof as there are quite a few variations on outputs per 3D editor) is setting a mesh name from the “o” tag if the tag has a defined name. It’s on my todo too.

Short story: the workflow because of missing functionality is not flexible enough. We’re gonna change that.

What Fabrice is trying to say is that the OBJ format is complicated because different exporters create different flavors of OBJ. Since we want to be able to parse all of them we are sort of stuck with the “least common denominator”. We will try to soon parse names even of “o” tags in OBJ, but if you can, try to use a less ambiguous format like 3DS or AWD if you can.