Rhino Datasmith import time

Hi - I’ve a city model which 100 x 200m real world and is approx 138000 meshs in a 180Mb Rhino file which I’ve been pulling in with the latest version of Datasmith for UE4.22. I’m surprise on how long it takes for Datasmith to process as has been nearly 2hrs on my machine to get this in. I know it’s working very differently however Enscape takes 3mins to export the same data to their Realtime environment. Is this normal currently for a model of this size and complexity right now?

(apologies as not in a position to submit the geo for testing right now)

Update - it finally took 3.5hrs to pull in the data. FPS is still super slow compared to its Enscape counterpart (as a benchmark) - both using dynamic lighting. In the end Datasmith generated 142,152 items for this import. City model I would expect to be as complex as a City Engine scene.

Is this to be expected or are there any optimisations I should be trying? Assume that light baking may also help reduce the overhead?

In my experience, 142,152 actors is a HUGE number for Unreal. Dynamic lighting for that many actors is also going to be rough. The best thing you could do is reduce that number as much as possible. I usually spend some time in Rhino meshing and joining objects before importing. If you can get a nice script together to automate that, it only takes a few minutes and can drastically reduce import time. For example, if you are importing a lot of buildings, and each window is a separate object in each building, it might make sense to join all the windows together (per building side, per entire building, or maybe even per block) into a single disjoint mesh.

If you are primarily concerned about import time (for example, it you are trying to do a quick initial test import), you can also reduce import times a lot by not importing materials and by lowering the lightmap uv resolution on import. This might not work for production-quality, but In our workflow for example, we replace all the materials anyways, so I don’t usually import materials.

A very simplified note on optimization: The number of different meshes and materials increases the number of draw calls, which is handled by the CPU. On the other hand, the number of polygons and dynamic lighting affects the rendering time which is handled by the GPU. Which one is the bottle neck for you will depend on your machine and set up. For statically lit scenes, in my experience I usually hit the draw call bottleneck first.

Thanks - Relatively straightforward to join all meshes together with a bit of GH - will give that a go. There is also the trade off if lighting is baked between quality and resolution of light map and the number of meshes. If you had 100 meshes with their own light maps then these would look better than 1 mesh made up of the 100 merged meshes as you would effectively have a lower res light map per unit2 of the geometry (assuming you don’t have some crazy large light map resolutions!)

Is there any way to get a better trade off here?

have you tried Optim? you could pass for 3dsmax and see if with optim you can still optimize.

Thanks - the optim workflow could be good however we don’t want to have to translate our files from their native application (Rhino) as that’s not an efficient pipeline for us. Much better sorting at the import side with Unreal.