Tag Archives: 3D

WebGL is finally ready for prime time – watch everything change! – Part 1 of 4


If you see a spinning Pebble smartwatch above you are using a WebGL enabled browser!  Otherwise you’ve fallen back to a precomputed spinnable 360 degrees format which isn’t even close….

With the latest round of WebGL supported browsers and the hard push towards optimized JavaScript compilers, JavaScript “assembly” libraries that play well with optimizing compilers(asm.js), support for compilers that generate asm.js compliant JavaScript (LLVM with Emscripten), and direct support for LLVM virtual machines and even totally safe sand-boxed code execution (NaCL in chrome only) we are FINALLY ready for a 3D web. And much more than that – these technologies will signal the death knell of traditional OS specific apps….. again FINALLY!

The History from the Standpoint of Applications and the Web

If you are inpatient or pressed for time you can skip down past this – but having a feel for the background really makes the appreciation sink in.  The history with respect to mobile devices is in part 2, web 3d is coming up in part 3 and part 4 will wrap things up by explaining how WebGL on browsers should pull all app development into its fold and leave the other targets as second thoughts.

Let’s start at the beginning (where most things usually start) with the schizophrenic, 1.5 steps forward – 1.2 steps back nature of the computer world where the ecosystem can change over night – a Darwinian process that works well in the end but is far from optimal with respect to efficiency. In the beginning everything was proprietary to processors…. great job security for developers. Some reasonable guys created C to be “a portable machine language” and for a while things moved closer to the write once, modify for various targets and be good to go model. A useful orthogonal model of development – 1.5 steps forward. And remember these systems were very different under the hood – but conveniently were mostly crunching data and spitting out text. Over time things exploded as essential proprietary libraries were created for various targets that broke many of the most useful elements of this paradigm – only 0.5 steps back. These systems did in fact have different capabilities, processors and memory footprints and so a universal abstraction layer couldn’t be generated in many cases. So this did make some sense.

As we enter more modern times – hardware began to be nearly ubiquitous across operating systems – you probably had the same hardware underneath whether you were running Windows, Unix (including the Mac, being Unix of course), Linux, etc. However operating systems that implemented a large number of the same applications (everyone wanted Photoshop to run the same way on all targets) were proprietary in nature with respect to their code. Due to the power of the fast new machines, code could be written with abstraction layers that made it possible a more write once and build for multiple targets; however many programmers still chose the easier, more feature rich approach of writing code specifically for each target. For companies that did nothing but port this was a cash cow.

When the internet took off the ultimate force multiplier for a homogeneous, ubiquitous development abstraction layer was in motion – oddly disguised as a hypertext viewer.  In throws and spurts thanks primarily to Microsoft compatibility games (in Internet Explorer, Java etc.) getting the web experience to be reliable and consistent was a process of never-ending testing.  This did get fixed over time to a good degree.  And as these things really settled down in recent years the stage was almost set, cross-browser compliance was close enough.  There were key missing ingredients however.

One of these missing ingredients was performance – you just couldn’t get close enough to native performance out of the apps that were developed for the web without security risks a mile wide AKA Active X.  These first generation JavaScript ajax apps were really far from the ideal mark – a huge step back in look and feel from native apps.  However, they were relatively safe and sand-boxed(after some time).  Most importantly collaboration was available in a larger way as application installation wasn’t an issue and a rate limiting factor to  deployment and acceptance.  So they were good enough and created a strange, ever-expanding environment of cross-breed of internet applications.  In our guts most developers realized these environments were first class kluges making a square peg round hole metaphor look like an insane understatement.  Html documents were never intended (or designed for) application development and this environment really create a freak show of clunky technologies.  But they became irresistibly de facto – their limited functionality was simply to useful to end users.

Things were getting very close…. 2.5 steps forward for the concept of write once run anywhere.  Everyone who was anyone wanted to have a web app built or customized for their company.  Over the course of several years, web-based app frameworks started to take hold – and sprout up everywhere.  The only thing standing in the way to a the universal “OS killer” app environment in browsers at this point was performance and a more unified, cohesive development experience (client side functionality instead of everything on the server, support for multiple programming languages, something closer to a symmetry between client side and server-side code, etc.).

Side Note: 

Many would think Flash might have helped bridge these gaps – but the binary executable blob concept simply never sat well with a generation of developers wined and dined on complete transparency of underlying code and implementation that came with the standard web development paradigm.  Flash was doomed well before Steve Jobs pulled a Microsoft and didn’t permit it on iOS devices.  Was he the benevolent guru of user experience as he claimed – keeping the masses from poorly performing flash apps?  Of course not, his Bill Gates spidey senses were at work – flash apps could be as strong as app-store apps and would be completely out from Apple’s thumb.  This is the same reason iOS devices don’t support WebGL – it makes uncontrolled high quality apps possible.  But Apple will cave in with iOS just as Microsoft did with WebGL in Internet Explorer – we’ll talk more about this later. 

HTML 5 was coming down the pipe and JavaScript engine optimizations were being implemented – and even rudimentary 3D using canvas and “software rendering” was coming along.  Things were getting so close you could almost smell it in the air.  And then the machines turned into a wrench (literally and figuratively)…….

Mobile phones came on the scene with Android and iOS and …… the old days were revisited – proprietary “OS apps” were back in full swing.  Let’s once again set back the clock and take a big step back…….

More coming in part 2!

Scenegraphs and OpenSceneGraph for 3D Software Development

I get a lot of questions about scene graphs and 3D development. Many people either aren’t sure what they are or have misconceptions about them. For this article I will explain the concept of scene graphs from the standpoint of OpenSceneGraph, an amazing open-source scene graph inspired by the granddaddy of the modern scene graph – SGI’s Performer. For purposes of this article I will use the terms OpenSceneGraph and scenegraph interchangeably in many places. It is beyond the scope of this article to explain all possible permutations of the scene graph concept.

Standard graphics objects and a spatial graph

At their heart, scene graphs are nothing more than a graph of nodes representing the spatial layout of a 3D scene while encapsulating primitive graphic characteristics in objects. This sums up the two greatest strengths of the scene graph – spatial organization for culling and encapsulating graphics characteristics in a data format.

Standard graphics objects

Why is this such a great thing?

When model data is read into memory to be utilized in OpenGL or Direct 3D using non-scenegraph solutions, proprietary formats are often used that are suited to the exact needs of the application. While this isn’t a bad thing in many respects, it makes it difficult to impossible to grab libraries and pieces of code you need from sources and use them without significant modification. Many times graphics programmers will see a technique they like and be forced to dig into the code and rewire things to work with their data structures. Scene graphics enable users to create code that works with the basic object primitives out of the box. This can quickly lead to a huge amount of code that is available for just about any graphics technique or purpose, ready to use out of the box.

Many ask, “What if you choose the wrong data format for these objects? Why is one superior to another? Scene graphs choose a format that encapsulates the lowest level graphics primitives and states into unique objects. These objects are combined in the graph to visualize anything that can be procedurally generated in a lower level graphics API. Various graphics states such as material attributes, blend modes, textures, etc. each have a corresponding object that is applied when the scene graph itself is drawn. Because of this flexible “standardizing” of basic graphics operations it is both possible to represent most anything the graphics sub-system can create as well as allowing new objects to be built to utilize them in a standard way.

Culling of the scene, optimization, transform stacking, billboards, LOD management, texturing are all able to have powerful, simple and standard code to manage them.

A spatial graph

By setting up the scene graph as a spatial non-acyclic graph culling can be more easily managed as well as graphics state. A node with children can set the state for the children without the need to redundantly specify it in the children. A scene graph is traversed as it is drawn and state is popped and pushed to both minimize setting state without need and to simply the organization and management of the scene as a whole. Scene graphs are often used in a complimentary fashion to other more “automatic” and hardboiled culling and spatializing strategies such as bsp nodes. I have seen many scene graph systems over the years that use bsp structures at various levels in the scene graph strictly for collision detection. The main thing about this approach is flexibility. Scene graphs can build very sophisticated scenes in a way that is logically consistent, as simple as possible and easy for the (relative novice) to learn and understand.

What scene graphs don’t do

Scene graphs are very powerful but not much easier to learn than the underlying graphics API’s themselves such as OpenGL or Direct 3D. They are not “game engines” that the novice can pick up and with little understanding create 3D scenes from.

You may ask yourself what the point is. The point is to not reinvent the wheel. The   is so flexible a tool because it doesn’t try to hide capabilities or oversimplify them. However, it mirrors the kind of system one would generally have to write themselves through much trial and error to achieve the same functionality. Many of these concepts are “classic” at this point. OpenSceneGraph, for example, is chocked full of appropriate and useful design patterns. Performer used these design patterns long before the term became a buzzword. SGI spent a lot of time and money developing Performer, and like OpenGL, the results were impressive. Most modern scene graphs are directly influenced by Performer and can be seen at their core to be “Performer-clones”. Those who try to build fast and flexible graphics solutions will eventually come to something close to a scene graph on their own eventually. But why reinvent the wheel. With solutions like OpenSceneGraph already waiting……

The choice seems obvious

Use an existing scene graph solution. You wouldn’t try to write your own graphics API in today’s world. In just the same respect you shouldn’t try to think you’ll create a better scene graph. If you need a fast, flexible graphics solution and use one of the scene graphs out there today. I personally prefer OpenSceneGraph, something I mention often. It has a huge user base and an unmatched set of features for an open-source project. Other commercial options include Gamebryo or Renderware.

In short the benefits of using a scene graph are numerous. A reusable, flexible and fast object system and a graph structure for hierarchy give it a strong user base and an ever-expanding collection of useful code.

The next time you think about doing a project coding in a low-level graphics API think about bumping up to a scene graph. They sit nicely on top of the underlying graphics API’s and make your job much simpler at the end of the day by allowing you to focus on the problem at hand and avoid reinventing the wheel.