There’s a major shift in 3D as companies move to cloud and mobile solutions. And even though we live and breathe the complicated world of 3D, nobody has a crystal ball. Nevertheless, here are my thoughts about what I see happening with the different approaches and challenges to viewing 3D data on modern platforms.
net Explorer 11.0, coverage (on the desktop) is pretty much complete. But while I think it’s really cool technology that will dramatically expand the use of 3D, as with most cool new things, there are limitations.
First, older versions of the browsers don’t support WebGL. Is this a big deal? Not if you are most people - but for large enterprises that lock down versions for years (many still using MSIE v9), it matters a lot. Second, as a general rule, browsers are 32-bit applications incapable of handling the large models that are becoming more prevalent in the engineering and construction worlds. Third, support for WebGL is pretty spotty on mobile devices. I think we’re going to see solid support on Android soon, but it looks like Apple is making a strategic stand against it (as it did with Flash).
And speaking of mobile, while the devices are getting more and more powerful, engineering and construction models are also getting larger and larger. So trying to download and load these models simply swamps the mobile device.
Ok, so WebGL is usef
ul in many cases, but not all. What’s to be done? With HOOPS Communicator we have included other options for when a WebGL approach doesn’t work well. First, we provide tools for building native 3D apps on mobile devices. This seems to be the paradigm that works much better than using a browser. Ever try to read the New York Times in a browser on your phone? Notice how much better it is when you use the New York Times app? That’s because the app is optimized to the form factor of the device.
But what if the developers (or users) still want their apps to run in browsers?
For these situations, we have implemented server-side rendering. This approach renders the model on the server and pushes down simple images to the device. While the interaction can be less dynamic than rendering locally, it also provides absolute freedom. Any browser can render an image (no matter how old), there are no issues with mobile support (as long as you support a touch interface), and there is no power requirement for the device. For example, the weakness of a client device has no impact on the speed in which a huge building model can be rendered.
Live 3D in a safari browser on an iPad with HOOPS Communicator Server Side Rendering
WebGL, native mobile apps or server-side rendering: which is the best, and which will win out? The short answer is that it depends, and there probably is no need to choose at this stage. Our approach is to cover all bases, so that the solution developer can choose the approach that makes the most sense for the application and their users’ requirements (typical model, hardware set-up, IT requirements, etc.)
Which direction(s) do others see this going? Any thoughts?