OBJ Importer making far more groups than expected.

So I am working on my full body model and trying to identify the different groups in the model.

Objo, this is the same model I am using that I emailed you recently.

When I load the model into UVMapper it shows that there are 63 groups in the model which was exported from Daz Studio...



All well and good. But when I import into WPF with Helix, suddenly I have 2146 children in the model. I thought a group would be a child and was only expecting 56 children (from 0 to 55 indexed).

Here's a bit of code. This function (after loading the model) iterates over all the children in the model, which I was expecting to be the 56 groups... this is to help me identify the groups/children in the model. The texture of a group/child defaults to green.

To identify a particular child visually I pick out the index and colour it red.

But as said there are 2146 children and it's not workable. I am seeing minute parts of the model in red, rather than a whole group/child.

Am I doing something wrong or is there a bug in the importer please ?

 public Material greenMaterial = MaterialHelper.CreateMaterial(Colors.Green);
        public Material redMaterial = MaterialHelper.CreateMaterial(Colors.Red);

        public Model3DGroup neutralModel = new Model3DGroup();

        public void makeNeutralReferenceModel()
        {
            var index = 0;

            foreach (var m in neutral.Children)
            {
                GeometryModel3D geo = (GeometryModel3D)m;
                MeshGeometry3D mes = (MeshGeometry3D)geo.Geometry;

                if (index == 1)
                {
                    neutralModel.Children.Add(new GeometryModel3D { Geometry = mes, Material = redMaterial });
                }
                else
                {
                    neutralModel.Children.Add(new GeometryModel3D { Geometry = mes, Material = greenMaterial });
                }
                index++;
            }

            scene.Content = neutralModel;

            temp.Text = neutral.Children.Count.ToString();
        }

Can a group contain meshes with different materials?
In that case it is possible that the importer adds a new model for each mesh. The output model could be changed to a hierarchy, where the first level correspond to the groups. I think this can be added as an issue! A small example model and a failing unit test included in the issue would be awesome! :)

Can a group contain meshes with different materials?

I do not know the answer to that, I'll see if I can find anything.

The output model could be changed to a hierarchy, where the first level correspond to the groups.

Do you mean that as something you would need to do in the importer or something I can do in code ?

I think this can be added as an issue! A small example model and a failing unit test included in the issue would be awesome!

I'm happy to help in any way I can but I do not really know what a "failing test unit" is' !

Every other model I have used so far (not many really though) have been fine. The head I was working on came from a different program, I think from FaceGen. But as mentioned above this full body one comes from Daz Studio, but it looks fine in UVMapper.

You will have the model in your email if that's any use (daz-working-model.zip).

Thanks for taking a look :)

Hi again,

In an effort to find out about the question over groups and meshes I asked a question over on Stackoverflow.

Here is a link to it for your reference : http://stackoverflow.com/questions/21517489/obj-3d-model-can-a-group-contain-meshes-with-different-materials

Can a group contain meshes with different materials? In that case it is possible that the importer adds a new model for each mesh. The output model could be changed to a hierarchy, where the first level correspond to the groups.

Thinking some more about this. There are 26 materials. Some groups would seem to refer to the same material. Like the eyes for example. So you have two eye groups and both point to the same material. I don't think there are any sub meshes within a group like you ask. At least I don't think there should be ?

I can see no reason why a mesh is being dissected like the way it is, just by looking at the model. The importer appears to be subdividing the groups, if it is finding the groups at all.

Making a hierarchy might help, but why not just identify the groups anyway and build those individually so you have the right number of children/groups in the end ?

If it were a hierarchy one would still need to apply textures and modify the mesh - would that be possible with a hierarchy ? Which makes me think simply going for groups is the key here.

Personally I do not need to control the minute parts of the mesh - I don't know if that would be useful to anyone else though.

Well I have been looking at the model files produced by Daz Studio and I think I have been going up the wrong path.

I now do not think it is the fault of the OBJ Importer :)

After examining the different export options in Daz Studio, it seems the one I was using is making all these groups. For example in the OBJ file for the body model I used a text editor to count the occurrences of the left toe and there are 248 matches, each time declared as a group and assigned a material.

So that's what is going on. I had thought that groups would be the major parts of the model, and after seeing what UVMapper displays I thought it even more. I clearly do not know enough about the OBJ format !

I found I could export from Daz using the materials as groups. Once I had done this I have what I want - a model with groups of major body parts.

I still feel confused by what UVMapper was telling me though. Like why was it reporting only 63 groups ? I have no idea.

My guess is that the models have so many groups so that each part of the body can be morphed/reshaped. So I was wrong in thinking that for example the head would be one group - I was actually exporting a lot more information than that. Information that I don't think I need.

So Oystein it looks like that is settled, sorry for taking things so far off course - I think you can now close the issue I opened regarding this matter. :)

ok, I am glad you found out what was going wrong. I have closed the issue!