Skip to content

Investigate making nested instances their own glTF nodes #150

@corybarr

Description

@corybarr

Currently, every exported Revit element gets a corresponding glTF node. For most elements, this makes sense. For example, each exported column should each have one glTF node.

This makes less sense with more complex elements--in particular the ones with nested instances. Here's a railing from the Snowdon data:

Image

Currently, this exports as a single glTF node with one mesh and one mesh primitive. However, there's obvious instancing going on in the balusters.

Here is Revit's event order for the above element:

OnElementBegin

    OnInstanceBegin

        OnInstanceBegin
            OnPolymesh
            OnPolymesh
            ...
        OnInstanceEnd

        OnInstanceBegin
            OnPolymesh
            OnPolymesh
            ...
        OnInstanceEnd

        OnInstanceBegin
            OnPolymesh
            OnPolymesh
            ...
        OnInstanceEnd

        ...

    OnInstanceEnd

OnElementEnd

Each inner OnInstanceBegin....OnInstanceEnd sequence corresponds to a baluster.

We could makes these nested instances their own glTF nodes. The advantages would be that a hash-based instance detector would certainly detect these as GPU instances. It's also highly likely they could be instanced in Revit to reduce export time, file size, etc.

Here are elements in the Railing category of Snowdon isolated. The above element along with two similar ones are in blue:

Image

Since balusters often have curved surfaces, these inner instances could likely account for a large number of repeated high-poly meshes.

The above railing is one specific example. Inner instances appear in more than just railings.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions