Why your 3D gamified models are not VR ready…

Gamification is the process of tweaking 3D models so that they attribute similar features of a typical game, but with the objective to promote learning/understanding. In the AEC industry, this typically means turning our 3D BIM heavy architectural models into ‘archviz’ models or ‘data interrogation’ models, usually to migrate with software like game engines.

The process of Gamification can be long or short depending on how much you need to change in your model. However, what’s often missed with gamified models, is that when this gets into VR, there’s a whole other level of ‘setting up’ to do. Luckily for you, I’m not only going to talk you through the general gamification stages – I’m also going to go through the VR stages and offer some out of the box solutions for you!

General Considerations:

Before we jump into the VR considerations, its important to talk about some of the general concerns, as these can be exaggerated significantly in VR.

Z Fighting

Problem: Z Flighting occurs when two planes/objects are at the exact same level and are fighting for render time. This is very common in architectural models and often occurs when structural and architectural models combine. Sometimes… it’s bearable, and you can get away with it, however most of the time, especially in VR, this can cause flickering and can be a real strain on the eyes.

Solution: Unity3DTips have some great tips on how to do this. These being:

• Physically move the objects further apart
• Increase the near clipping plane and decrease the far clipping plane of the camera
• Nudge the shader depth offset to force an object to be rendered on top

For those less familiar with game engines, the first one is probably the easiest to do, this can also be done in your ‘gamified model’ itself rather than the game engine. Even if it’s just 1mm or so, this makes a world of difference.

Materials and Textures

Problem: This is two fold, firstly, you need to make sure that the materials you’re using in your architectural model are of good quality, especially important for archviz models. It’s very easy to model a building without adding any textures and still produce the same 2D drawings. Secondly, even if you have all your materials in your model, its very hard to get them into game engines as they are; they can often go missing or just not be on the model at all!

Solution: One of the main reasons that materials go missing is that when you export to FBX or similar file formats, sometimes the materials are not embedded within your model. Most architectural design platforms won’t let you do this out of the box, but I’ll discuss some options out there later that will help you with this. In addition, how important are materials to you? One of my favourite Revit teachers Balkan Architect shows how an ‘all white’ render can achieve a nice effect – if you’re using the gamified model for data interrogation, an all-white render is actually recommended as this can highlight clashes and selections much better than a fully-fledged render.  

Lights aren’t what you’d expect

Problem: Here’s one for you MEP guys out there, you can set your lights to be exactly correct in your model, but when it comes to putting this into the game engine, I’m just going to delete all of them. Why? Two reasons. One, the light intensities you’ve inputted into your model are going to be calculated differently in game engines. You’re either going to have a very bright or very dark scene no matter how accurate the lights are in your model. Two, game engines limit how many lights you can have on at once in a scene if they are of close proximity, which they are in buildings. If you have a kitchen full of 8 or so downlights, I guarantee that even if these are lit perfectly, because of their proximity, they’re all going to be off. Sucks I know!

Solution: There’s a bit of an art to this one. Firstly, I’d change all of your light models to a bright/emissive material to give the ‘illusion’ that light is coming from them. Then it’s really down to dropping in some point/area lights and playing with their settings to see what looks best. The image below will give you an idea of what I mean by that, you’ll notice the white LED lights emitting a bright white whereas the actual scene is lit by a point light.

VR Considerations:

Now for the juicy bit!

Movement

In VR you really have two main choices for movement – ‘continuous’ which involves using a joystick to direct your movement in the game, or ‘teleport’ which shoots a ray at the ground and moves you to that position⁺. Both are just as easy to set up but here is why your gamified model isn’t ready for either – collisions. Importing your models into game engines will import the mesh but no colliders, put simply, you have a wall you can walk through but we need a wall that stops us doing that.

Firstly, we need a ground plane so we don’t fall through the floor. The quickest and easiest way to do this is to create a new plane and turn off the mesh so that it is invisible, but the mesh collider is still there. This will mean that you won’t have to go to each part of the floor and add a collider to it. It’s worth noting that if you have a model on multiple levels, you may need to make multiple planes to cut around shafts. You can then apply a similar principle to stairs, i.e. making an invisible collider ramp that goes up the stairs.

If you’re happy with walking through walls, then we can leave it there! If you’d rather not walk through walls, then there’s a bit of a process of going though each wall and adding a collider to it. If your model is detailed enough, you should be able to filter out which parts are walls and which parts aren’t. Then by selecting all, you can add a mesh collider* which takes the shape of the wall and stops people walking or teleporting through.

*Mesh colliders are data HEAVY, if you’ve got the time, a few tailored box colliders would be better.

⁺ This is the subject of a whole other blog post, but its also worth considering that teleportation is less likely to make you feel sick than continuous movement.

What you don’t model you don’t see

This is coming out of the game engine and back to the CAD guy in the office. As the heading suggests, what you don’t model, you won’t see. For example, you might be using recessed skirting instead of normal skirting. If you don’t model this recess and just detail it on in the 2D drawings, you’ll be missing out key aesthetic appearances of wall in a 3D visualisation.

This is a really tricky balancing act because its very common in building design practices to not show too much information at too early of a stage. My advice would be a less detailed VR model is better than no model at all. You know your projects well enough to be able to advise people when they have questions inside the model, if you wait until things are perfect in the model, you’ll never end up showing it to everyone.

Probably a better way of looking at this is that if the detail is drawn at a different location to where the model is, nobody will know unless that’s pointed out to them. Rule of thumb, model everything in its right place, if the detail moves, the model moves.

Where the hell am I?

The advantage of 3D modelling software visualisations to VR ones is that its very easy to tell where you are in a scene, as it should be really! This isn’t as essential in VR as the people using the building in real life aren’t getting this luxury, but it can certainly help, especially when the layout of the building isn’t set in stone yet.

What can be done? There’s a couple things you can try, both require a bit of game engine experience. Some platforms out there allow you to jump out of a VR model and jump back in by scaling it up and down. This can be very helpful for collaborative VR visualisations and is becoming more and more prevalent in VR ‘data interrogation’ experiences (Tools like IrisVR Prospect use this). Another way is to provide a UI map in the headset. This can be done by positioning a second in game camera above the player that culls the rendering of the scene to a few mm above the players head. This way you can see the floor plan of the building as you move throughout the scene, and this updates as you move from floor to floor.

Conclusion

Luckily for you, game engines and VR app companies out there know that these are big problems. To the point where game engines themselves have created tools to allow you to solve these problems.

If you’ve read Simon’s post on Datasmith for Unreal, you’ll already be aware of one of them. Unity has a similar paid version called Reflect. The reason for it being paid is due to reflect being a ‘live link’ as opposed to an import. This means any updates you do in your modelling software gets reflected in Unity straight away, pretty neat!

Visualisation softwares like Enscape and VRay (although not game engines), does a lot of this straight out of the box and is why they are used by numerous AEC companies around the world. Your lighting, materials, VR movement and collisions are all dealt with at a push of a button, and after reading this post, you can see how that’s a good thing!⁺⁺

So hopefully you understand now why gamified models aren’t VR ready yet, but that doesn’t mean they don’t have to be. Got something in mind that I haven’t mentioned, let us know!

⁺⁺Enscape 3.0 just got released at time of writing, I’m yet to try it out but there may be some nice VR changes to see!?