I received an email from a development partner yesterday checking in on Autodesk’s VR offerings. It occurred to me that while I’ve spoken about them at the DevDays in the US and Europe, I haven’t posted anything here. So here’s some fairly up-do-date information on what technologies Autodesk has in the VR space.
The way I’ve been tending to classify VR offerings in general is around the “distance from the metal”: i.e. how much (relatively speaking) of the software stack does the executing code need to go through to get down to the display hardware.
This is a somewhat arbitrary view of things, I admit, but it does set some kind of expectation around relative performance. It doesn’t necessary say anything about the systems the software typically runs on – people often use high-end desktop hardware to run native code, while less performance-sensitive scenarios are run via WebVR on mobile phones – but it’s fairly consistently true that larger models benefit from having more capable hardware available.
As some point it will make more sense to slice and dice this list differently, perhaps considering the extent of modelling vs. design review… today the various technologies listed provide limited capabilities for specifying design options, but all currently relate to design review rather than modelling or editing.
Closest to the metal we have native code: in Autodesk’s case this is typically written in C/C++ and calls into low-level graphics APIs such as OpenGL or Direct3D. Good examples of these are Autodesk VRED – which is largely targeted towards our Automotive customers – and Autodesk ReMake (the software formerly known as Memento). The ReMake team has some really interesting VR capabilities about to be ready for Beta-testing: I’ll talk more about this soon.
At the next level up we have game engines: this is the way we refer to Unity and Unreal Engine, for instance. I might also have used the term “real-time 3D engines”, as while Autodesk Stingray could be used to write games, that’s absolutely not its focus: we’re specifically targeting the needs of the design visualization market. One great example of this level of VR is how Autodesk LIVE exports Revit models to be experienced in a Stingray-based runtime. (You can even rename the package LIVE creates so it can be edited in Stingray to add in custom interactions and other advanced features.)
At the top level we have WebVR. This refers specifically to the cross-browser initiative to using WebGL to deliver VR on the web. I’ve put this furthest from the metal, for now, as it sets the appropriate performance expectations for where we are today: in truth WebGL is calling through pretty efficiently into graphics hardware, and as browsers’ execution environment gets optimised over time – for instance as we start to see the benefits of WebAssembly – we could well see this getting closer to the performance profile we see for game engines. We’ll see.
Examples of WebVR-related activities include the Forge viewer – for which you can use Vrok-It to test out some prototype capabilities – and then the stereo panoramas created by our cloud rendering APIs. Example WebVR delivery mechanisms for stereo panos have included viewers such as krpano – which I covered last year in a series of posts – and A-Frame – which was featured in a session at the Forge DevCon – but more recently this also includes Project Play.
Stereo panoramas are pre-rendered stereoscopic scenes – with a cube-map for each eye – that require very simple hardware to view. Any smartphone with an IMU (Inertial Measurement Unit) – it’s important to note that some lower-end Android phones don’t have a gyroscope, so you do need to be a little careful – can view stereo panos perfectly in a browser. And while the scenes are pre-rendered, this doesn’t mean they’re completely static: you can, for instance, add buttons to change the scene from day to night, as well as having hotspots that let you move between locations. As an example you can take Project Play’s VR capabilities for a spin here (this is best viewed using smartphone-based systems such as Google Cardboard, Gear VR or Daydream VR, but you can also try it from a desktop browser).
Now there’s much more going on at Autodesk that relates to VR, these days, but this is a quick summary of the VR-related products and features that a) I’m aware of and b) are either publicly available or soon will be.
