Hi,
I’m curious as to what is the best approach of exporting geometry from Revit, considering the default FBX solution from Revit doesn’t export materials or textures, or rather it does but in their own proprietary quirky way that only 3Ds Max supports? - I’ve been looking for a way to sort of 1-click-deploy it straight from the Revit interface:
- Straight to Blender
- Clean, Unwrap, Build lightmaps
- Potentially deploy model from Blender to a web server for the client to see
The first problem (and perhaps biggest problem) I get is when exporting from Revit to Blender, the only way I’m able to get a good enough geometry into Blender whilst keeping the material information is by using the Twinmotion Exporter (FBX) or Lumion Exporter (OBJ), as while the default FBX export from Revit is available from the API, the other exporters aren’t (afaik).
This has led me to two choices:
- Look into making my own exporter for Revit (Possibly fork and update https://github.com/jeremytammik/CustomExporterCollada)
- Look into IFC export
For the first, it would be a massive undertaking (for me at least), since I know very little C# and even less of the Revit API, which would probably take me months if not years to make anything useful of. The second solution has the big benefit of actually retaining the I in BIM, namely the information from the Revit property sets such as materials, quantities, schedules and what not. Plus it partially keeps the material description on the actual geometry. The biggest problem with IFC is that it’s usually massive, both to export from Revit and import in Blender (using BlenderBIM, which is still new and in early development). Plus, a lot of consultants work with and provide models in IFC as well, so that’s an additional plus.
As for SmartUV Unwrap (point A), it sadly is quite slow due to being written in Python (I think), I read somewhere that it might benefit from being implemented in C instead. So far adding support the Xatlas was just one of the planned integrations in TLM, down the line I think support for RizomUV or UVPackmaster might help a bit on this, though a minus to this is that they’re not free (but then again, neither is Revit).
As for point B, what we usually do when using Twinmotion is adding placeholders in Revit, which are then replaced on import (similar to what is shown here https://www.revit.news/2020/07/tutorial-revit-placeholders-in-twinmotion-replace-object-with-its-base-point/), if they’re just squares in Revit they don’t slow down performance much. Same could be used in Blender, where temporary construction lights could light up your basement scenes. Additionally, SSGI (Screen Space Global Illumination for Eevee) might have a few cases where it might be used instead of baking lightmaps, or perhaps as a supplement to it if toned down.
As for point C, a few large .hdr definitely adds up on the long run in terms of space, using encoding might help a bit one this if you’re using .exr (although I still haven’t added DWAA compression, which should help a lot on space usage), otherwise there’s also the options for using 8-bit LogLuv encoding, which should help save space by quite a large margin (between 40-60%), and the dynamic range isn’t decreased too noticeable.
Another point I’d like to extend is potentially adding Armory3D as the final destination from Blender, especially great for it’s ability to deploy to HTML5/Web, thus making the client able to view it from their own devices, potentially on mobile too if the project is minor. So far I haven’t tried this with larger projects, although it works surprisingly well with small apartment views.