MicroStation to Unity - FBX Export Bottlenecks

I have an HTC Vive virtual reality headset and I've been exporting my MicroStation models to the Unity game engine via the FBX exporter with the aim of creating virtual environments that the client can explore in real time. The workflow is straightforward and the results are spectacular, even for relatively large models. What's more, once the Unity project has been setup and the lighting and material tweaks have been made, it is super easy to replace the FBX files with updated versions from MicroStation and Unity automatically reintegrates all of the new changes without any further input from the user. It's a thing of beauty to behold :-)

With all that in mind, there are a few bottlenecks that if addressed would greatly improve the FBX export workflow. I'm currently using MicroStation SS3 and I would be curious to know if MicroStation CE has made any improvements to the FBX exporter.

Issue 1: Geometry Type.
MicroStation has many different element types, one of which is the “Surface” type that you get when you do a “Surface by Extrusion” of a line or curve. When I look at an exported FBX file with MicroStation, the elements of type “Surface” are all present but when I import that same FBX file into my Unity project, the elements of type “Surface” are missing. My workaround in MicroStation has been to use the “CONVERT BREP” command to convert all elements of type “Surface” to elements of type “Smart Surface”. It looks like this might be a limitation of Unity itself but I was wondering since “Smart Surfaces” work so well, would it be possible for the FBX exporter to automatically convert all elements of type “Surface” to elements of type “Smart Surface” before doing the export?

Issue 2: UV Texture Coordinates.
The Unity game engine has an option to bake lighting into the materials of each piece of geometry and this requires that all geometry has properly applied UV texture coordinates. Back in MicroStation, some materials will simply use a “Base color” whilst others will use a “Texture map”. It looks like the FBX exporter applies correct UV texture coordinates to geometry that has materials that use a “Texture map” but it does NOT apply UV texture coordinates to geometry that has materials that only use a “Base color”. I was wondering if the FBX exporter could be made to apply default UV texture coordinates to geometry that has materials that do not use a “Texture map”? Without this option, Unity can't bake its global lighting solution.

Issue 3: Material Names.
The FBX exporter does not parse material names as they are defined in the Material Palette, it appends the current file (or reference file) name to the end of each material name. I guess it does this just in case the active and reference files have materials with the same name but different properties. I use external “mat” & “pal” files so ALL of my files are guaranteed to be using the same material properties and so this naming schema ends up being far more of a hindrance than a help. The unfortunate side effect of this naming approach is that it creates VERY long material names in the Unity editor and much worse than that, when you have multiple buildings with multiple FBX files, you end up with multiple versions of the same material, all of which need to be tweaked in the same way so as to maintain consistency. Would it be possible for the FBX exporter to ONLY use the Material name and NOT append any file name information at all?

Issue 4: Surface Normal Direction.
For performance reasons, Unity's Standard shader only does single sided rendering which means that surface normal direction becomes critical. MicroStation has the “Change Surface Normal” tool but it isn't designed to clearly show which surfaces happen to be pointing in the wrong direction. Would it be possible for us to have a “Display Style” that does single sided rendering so that we can more easily see where the holes are in our geometry? Better yet, would it be possible for the “Change Surface Normal” tool to have an option to set ALL geometry with its Surface Normals facing the camera to be blue, and All geometry with its Surface Normals facing away from the camera to be red? This would make it so much easier to simply click on red geometry and confidently correct a model in a fraction of the time.

Issue 5: Mirror Element Command.
The Surface Normal direction of a piece of geometry is critical for the proper application of texture maps. If the Surface Normal direction is reversed then text that's present in a texture map will be reversed. Bump & Normal maps will also be reversed and the shadows will appear to come from the wrong direction.

Both MicroStation's “Mirror Element” & “Change Surface Normal” tools could be improved to make working with Surface Normal directions so much easier. Here is a screen capture showing what happens to a texture map when you first mirror a shape and then change the Surface Normal direction:

After applying the Mirror command, the Surface Normal direction has reversed and the texture is incorrectly mirrored. After applying the Change Surface Normal command, the Surface Normal direction is once again correct but the texture has rotated 90°. Neither of these behaviours is acceptable and makes working with the Mirror tool something to be avoided. What I believe should happen for both the “Mirror” & “Change Surface Normal” tools is that the origin of the shape (Point 1) should move to where where Point 2 is and the direction of the points should reverse. It's as simple as that and so many headaches would go away.

Conclusion:
I know that these sorts of changes happen on their own time line which means that we may never see them implemented but I put it to you that Virtual Reality is a breakout technology that will have far reaching benefits. FBX's place in the Unity game engine is central and any improvements that you can make to the FBX export workflow will have far reaching effects for us users of MicroStation and the clients we service.


Cheers,
Andrew Novinc.