Improve instantiation performance

[Daniel4144]

Hi,
At the moment I am adding a custom script to every node after instantiation of a model at runtime. Because the models contain many nodes this takes some time.
I experimented with making the instantiation and initialization faster and noticed that instantiating a prefab with all components and scripts is faster than creating a new gameobject, setting transform/parent, adding components... - it is basically just one call: Instantiate(prefab, position, rotation, parent).
To achieve this I created a custom instantiator which works fine for creating the hierarchy with additional scripts attached. However, because this was significantly faster I also wanted to create meshfilters/renderers/colliders this way. I think at the moment it is only possible to add meshes later in a second iteration. Or is this somehow possible?

[atteneder]

Sounds like a great observation!
Indeed right now the order of calls is something like:

1. CreateNode which creates the GameObject
2. AddPrimitive (or AddCamera etc.) which adds components

Solutions I could think of:

1. Query the glTF JSON to figure what components the node will have (sample below)
2. Some sort of component mask parameter in CreateNode (so we know upfront which prefab to instantiate)
3. One combined, monolithic CreateNode with all parameters

we also have to have a strategy how to deal with unknown components (might come from future injected extensions). Imagine a custom physics extension that adds a Collider component.

I kinda prefer the first solution, since it allows you to do that stuff with querying the glTF JSON. Example in CreateNode:

public void CreateNode(
    uint nodeIndex,
    uint? parentIndex,
    Vector3 position,
    Quaternion rotation,
    Vector3 scale
) {
    var node = gltf.GetSourceNode(nodeIndex);
    if (node.mesh >= 0) {
        // instantiat this prefab
    }
    else {
        // instantiate other prefab
    }
    ...
}

public virtual void AddPrimitive(
    uint nodeIndex,
    string meshName,
    Mesh mesh,
    int[] materialIndices,
    uint[] joints = null,
    uint? rootJoint = null,
    float[] morphTargetWeights = null,
    int primitiveNumeration = 0
    )
{
    // fetch previously generated gameobject and renderer component
    var go = nodes[nodeIndex];
    var mr = go.GetComponent<Renderer>();
    // Assign mesh etc.
    ...
}

[atteneder]

granted, it's not very explicit

[Daniel4144]

Hi @atteneder and thank you for the answer.
I haven't checked for performance improvements yet, but your suggested solution number one works great!

A second thing I would like to improve is the creation of primitives as already discussed in #153 :
During AddPrimitive() primitiveNumeration is used to determine whether to instantiate an additional object for the primitive. Because I am deleting the additional objects anyway: is it possible to determine the primitives belonging together before instantiating the scene so I can combine them upfront (so I can just skip the additional Addprimitives)?
There is GltfImport.GetMeshes() which I could probably use to manipulate the meshes, but how can I determine which Meshes belong together?
This would probably also allow me to bake the meshes to use as colliders in parallel during the instantiation.

Thanks again for your help!

[atteneder]

I had a look at it.
The long-term solution I aim for is that glTFast creates combined meshes right away, since that'll be faster than running CombineMeshes afterwards. In fact it already does so, if the primitives use the exact same vertex attribute buffers. Some glTF generators (like Blender's exporter) split up vertex attributes of primitives across smaller accessors, which have to be re-combined again. This is missing and that's why this primitiveNumeration solution is in place.

As far as I can tell primitiveNumeration will never go away completely. glTF's mesh primitives can be more flexible than Unity's. For example you can have one mesh with primitives of different topology, vertex attribute buffer structure (e.g. one submesh has tangents, another don't) or indices type (int16 vs. int32). There are only two solutions to that:

• Create vertex buffers that can hold the more complex primitives and fill the gap for simpler ones (filling in default values)
• Cluster primitives with identical vertex attribute structure (and index format) together, but have multiple meshes when this is not the case.

Upfront: I think this is the rare exception and I probably have to make test glTFs, since I never encountered such a strange thing in real world.
I think it's a shame that glTF allows for such awkward combinations, but that's what it is right now.

[Daniel4144]

I will probably leave it how it is for now and look forward to your solution.

Interestingly, I encountered that in every single model I tested it with, but I have to add that I am only using it to load CAD models. At the moment I use Mayo for the conversion to gltf/glb, which is an open source CAD converter. Maybe that could help you to create some test files, there are many free CAD models available on the internet.

One more thing: In Unity there is Transform.hierarchyCapacity, which should help to improve performance with large hierarchies. Maybe a negligible improvement in most cases, but if the number of nodes is known in BeginScene, that would be a quick addition (just increment it once for the parent transform).