0 Davinci: Open Source Engineering Tools (Part 2) Posted: 9/13/2009

Continued from Part 1

So, without further pontification, let me introduce you to the project I used to call Starshine, but that I now call Davinci (with no small amount of irony). Davinci is a family of four programs designed to work in close conjunction with each other: Scrawl, Workshop, Notion, and Plaza. Scrawl is a CAD/CAE solution designed to allow contributors to design and modify individual pieces easily and efficiently while remaining faithful to the requirements of the larger project. Workshop is a high-level assembly interface for connecting together designs made with Scrawl into larger, more complex projects. Notion is a modular simulation framework which is utilized by Scrawl and Workshop to simulate a wide range of behaviors and conditions. Finally, Plaza is a online versioning system akin to a SVN but custom built for organizing and storing large Davinci projects. Together they form a tight ecosystem of functionality that allows widespread collaboration. Allow me to describe each system with a bit more detail.

Scrawl's main functionality is fine-level design of individual parts within a larger project. Like most CAD/CAE programs, it would allow for both schematic and parametric (perspective) views of a design, the ability to define the solid geometry of the design, and define the physical properties of parts. To facilitate flexibility, Scrawl would allow the import and export of geometry from other programs outside of Davinci, a feature also shared by many CAD/CAE programs. However, Scrawl would allow for all of this within the context of the larger design. Should such limitations exist, the interface will show the physical space constraints, connection points, and other relevant data in relation to the design. The design can be tested by Notion, which will in turn create a metadata file, including the performance of the piece for use by Workshop. The files Scrawl will save out will be rich in metadata, including physical properties as well as the creator's name and the intellectual property license under which the creator wishes the work to be shared.

By itself Scrawl is nothing particularly special. Its true potential comes from its tight integration with Workshop, which allows for the assembly of higher-order designs. Workshop is all about applying a object-oriented approach to the design of multi-part inventions. Users can load Scrawl files and even other Workshop files into a single assembly environment. From the interface, users can combine these sub-components together much in the same manner LEGO piece can be pieced together. The user can define the level of binding between individual pieces, approximating bolts, welds, or greased joints. The user can inspect the metadata of each individual piece, as well as open it, either opening its respective Scrawl file or its Workshop file. This power to include other Workshop files, I feel, is a must. It is the equivalent of the #include command I mentioned earlier, as it allows for development of sub-components independent of the larger project. However, simply assembling these higher order designs is somewhat constrained in utility without the ability to test the system as a whole. This is where Notion comes into play.

Rather than be a monolithic simulation program such as those used by most CAD/CAE systems, Notion is far more akin to a rendering engine framework such as those found in professional 3D animation packages. The key thought behind this is flexibility. Different users will want to test for different things, and different projects will necessitate very different kinds of tests. For example, the designer of a airplane may not care much about simulated crowd-flow within a structure, but it is a essential consideration for the designer of a subway station. Conversely, the designer of a subway station probably cares little about hydrodynamic flow, whereas it is absolutely crucial for a airplane's design. This is a simplistic example, but the point is that forcing a single set of simulation tools not only limiting to users, it also limits the applications of Davinci. Notion would act as the ambassador between simulation engine modules and Scrawl/Workshop. A user looking to test a design would select the elements to test in either Scrawl or Workshop, and then specify the test and simulation engine to use. Notion would then glean the needed data/metadata from the selected elements and feed the information to the simulation engine. The output from the engine would be fed back through Notion and displayed within the interface of the originating program. Notion's functionality would not stop there however. For Workshop files, Notion would allow for multi-level simulation. This would allow for tests to be performed not just on static proxies of sub-components, but on a level of to-the-part accuracy. While far more computationally expensive, it would allow for the capturing of “gotcha” mistakes, such as a unintended weight shifts due to a sub-components movement or a unexpected loss in performance due to cross-component heat pollution. The aim of such functionality is to come as close as possible to a fully realistic virtual prototype. While perfection of such a prototype is probably out of the reach of any system in the near future, something close could be attainable.

With all these components and simulations creating piles of data and metadata, some sort of organizational system would be critical for any serious collaboration. This is where Plaza becomes crucial. Plaza would be a server platform consisting of several different services. The most critical service would be a specially-designed SVN system would intuitively and securely archive the data generated by the innovation process. A second service in Plaza would allow it to act as a abstracted simulation module for Notion. This service would allow for Notion to leverage large clusters of connected servers for especially complex simulations. To facilitate real-time collaboration on a single file, a service based on the Uni-Verse code-base would also run on Plaza. This would allow multiple contributors to collaboratively work on a unified design simultaneously, a important feature for when designs get above a certain level of complexity. One final service would be a API allowing third-party applications to securely access the data stored in the repositories. This will allow developers to expand upon the family of applications that can leverage Davinci. Such applications might include statistical comparison software for comparing the technical merits of different design variations, or a virtual reality walk-through of designs. The possibilities are endless, which is why creating a robust and flexible API would be so crucial.

I think I've rambled enough on this system for now. This was meant to be first and foremost a conversation starter, so I look forward to you thoughts. I most certainly lack much of the technical expertise it would require to build such a system, which is why I would very much like to see such a system developed as open source. There's something poetic about open source being the key to the creation of open source hardware. In short, if this has sparked a interest in you, feel free to adopt the concept and dive into fleshing this out.

Continue Reading

0 Davinci: Open Source Engineering Tools (Part 1) Posted: 9/13/2009

Tonight I want to talk with you about something I have struggled with for some time to figure out. This idea has been with me for close to if not over a year, and yet until recently I was finding it very hard to describe to others. I even posted about it once in my old ideas blog, but even as I wrote that version I felt frustrated by my lack of clarity on the topic. This is my second opportunity to do it justice.

I am, as you may have gathered, a advocate of tools. While it is becoming clearer by the day that humans are not the only animals with the ability to conceive and utilize tools to achieve our aims, it is one of our defining characteristics which has allowed us to thrive as a species. This is one of the reasons I am such a rabid advocate of open source. It calls on the better angels of human nature to facilitate collaboration in the search of better tools, accessible to all. Yet despite all of the wonders open source has provided the world of software, I would hazard that I am one of many who feel that open source must expand beyond the realm of software to deliver its best gifts to humanity. Open source must breach the divide and become a tool for the innovation of corporeal inventions. Several attempts at this have already been made, or are under way. However, their dream will never reach full fruition without confronting a basic reality: Advocates of open source hardware lack the equivalent tools that their software compatriots take for granted. Without these tools, open source hardware cannot achieve the same success that open source software has enjoyed.

When a coder sits down at a computer to write a program, they have all the tools necessary for the act of creation and collaboration at their fingertips. Code can be written in a free text editor or software editing application. That code can be compiled, for free, by a compiler residing on the very same computer. The coder can test the fruits of their labor for free and in most cases, without fear of harming themselves, their computer, or their work. Now to be fair all of this functionality can be mimicked by a engineer, utilizing a CAD/CAE program. A engineer can design a piece of machinery and test its basic functionality, safely and (depending on the software) fairly cheaply. In this regard, the two systems are relatively similar. However, the differences begin to emerge when collaboration, a essential ingredient of any open source project, comes into the picture.

The power of open source derives from the ability of a individual coder to contribute a relatively small amount of work which can easily be merged into a larger, more complex project. The core of open source is the acknowledgment that not everyone is Superman, and that many people contributing just a little can add up to something greater than its part. A coder working on a open source project can easily download all or part of the larger project, make changes, compile the entire project and test it. Adding the work of others to a existing program is also relatively painless, requiring only a few lines of code to instruct the program how to access the new code and to call its functions when needed. Indeed, the command #include and its kin are one of the most powerful commands from the perspective of open source. They are powerful because they allow for a single coder to quickly add the work of another coder, making collaboration not only easy, but in many cases easier than working completely alone. This is where the design of real things runs into trouble. A team of committed, determined engineers looking to create a large open source design, they will quickly realize that while they can all design individual pieces and test them all individually, there is practically no way to test the entire system without building a physical prototype and testing its performance. While this might be a acceptable solution for something small, simple, and cheap to build, it becomes a serious problem for larger projects. The average contributor is most likely a person of modest means, and probably could not afford to build a functioning prototype of something large, like a car, building, satellite, or playground. There should be a tool that empowers the average contributor to the same level that a simple compiler empowers a coder. Such a tool should allow a contributor to build, edit, test and share large complex projects. That is what I shall attempt to describe.

Initially, I envisioned such a tool as a monolithic piece of software. This one program would handle all functionality, from the design of individual elements, all the way to the testing of large complexity projects. I based this initial notion off the analogy of a software development environment, where code writing, project organization, and testing functionality were all part of the same program. Understandably, this system became very hard to describe, as I tried to describe a family of functionality while retaining the notion of a singular program. It wasn't until recently that I realized what I was really looking for was a close-knit ecosystem of smaller, function specific programs. Once broken down into functions, the system is suddenly much easier to conceptualize, and hopefully easier to describe.

Imagine my embarrassment...

Continued in Part 2

Continue Reading

0 Google and the Soft Monopoly Posted: 7/08/2009

Google is taking over the world, or at least the Internet. We've suspected this for a while, so it really shouldn't come as a shock. Yet unlike previous companies which have tried to do this, such as Googles nemesis Microsoft, we don't seem too concerned about it. Quite to the contrary, we tend to welcome Googles juggernaut rampage to conquer every segment of functionality on the Net.

Take Googles announcement today that it will be releasing a free operating system based on its Chrome Internet browser some time in 2010. This is from a company which already has established itself as the dominant player in searches, email, maps, video, advertising, and is considered a strong contender in fields such as group collaboration, phone services, and even mobile computing. This is the same Google which is sponsoring a race to the Moon and regularly invests millions of dollars a year in a broad spectrum of startups. The same Google which recently introduced the concept of Google Wave, which may have the ability to revolutionize communications in a way Twitter can only dream about. Google isn't just a 500 pound gorilla on the Internet, it is THE 500 pound gorilla. Now, had any other company with this kind of omnipresence announced its intention to expand into yet another market, there would be panic and fleeing of the populace to the hills. Instead, the overwhelming consensus seems to be one of eager anticipation, bordering on celebration. So why does Google get treated so differently?

My guess, for what it's worth, is that Google has mastered the art of the Soft Monopoly. A Soft Monopoly is everywhere because people genuinely want it everywhere. It's helpful, useful, and generous, and doesn't go throwing its weight around to get what it wants. Instead, it convinces everyone else that they want what it wants because what Google wants makes things better for everyone. With only a few exceptions, everything Google has tackled has made the Internet a better place for everyone, which wins you a lot of friends. With such populist support, how could a Soft Monopoly do anything but expand? Whereas Microsoft and Apple have consistently tried to dictate what their customers could and could not do, Google has taken the opposite path. Their logic, I suspect is that the more seamlessly and effortlessly Google can fit itself into the experience its customers dictate, the more positively Google will be viewed. For Google this means offering a lot of high quality services for free. In doing so they become a ubiquitous part of the fabric of the Net, so when you need a professional solution, the answer comes naturally.

So should we be surprised Google is creating a free open source operating system? No, it's a natural behavior for a Soft Monopoly like Google. By leaping into another market with a free disruptive product, Google expands their potential to be helpful in all sorts of new ways. For a Soft Monopoly, helpfulness is directly related to future profit, so Google is right on its game plan. Right now Google seems content to constrain its monopoly to the realm of bits and bytes. So until your Google Groceries get delivered to your Google Apartment door by a Google Grocerybot, I think the world is safe for the time being.

Continue Reading

0 Joomla for the Metaverse Posted: 6/29/2009

I recently posted this question on Twitter and Plurk: if Opensim is the Apache of the Metaverse, then what will be the Joomla of the Metaverse?  Clearly I need to work on my grammar when tweeting/plurking, but I was being serious.  This isn't a idle or rhetorical question, its something which has to be answered if Metaverse solutions like Opensim are ever going to truly become the next incarnation of the Web.  

While it is true that the Web grew through its infancy without much in the way of content management software, it has become a essential ingredient to its continued growth.  Even in its early years, the growth of the web was spurred by programs and services like Geocities and Dreamweaver. These served to sufficiently lower the bar of entry into the world of web design to allow those with little or no technical knowledge quickly create a web presence.  This created a primordial sea of amateur designers and content from which the committed and skilled graduated to create bigger and better things.  

Right now the Metaverse scene is currently in the AOL stage, with a few centralized services offering walled garden experiences wherein they hold the monopoly on content and users.  A few pioneers (OSGrid, ReactionGrid, Openlife) cling to the fringes, boldly attempting to create more open alternatives.  However on their own they cannot compete on the scales of content and user population that the walled gardens offer.  This is why the developments in cross grid transportation in Opensim are so widely hailed, because in many ways they are the equivalent to the most powerful element of the Web: the hyperlink.  Once a critical mass of grids become connected and standards arise for commerce and content sharing, this new web of grids will begin to eclipse the walled garden providers.  But this critical mass must exist.

This is where the question of content management becomes so crucial.  Without tools and services to lower the barrier of entry, the growth of the open Metaverse will be stunted.    The open Metaverse will need its Geocities, its Dreamweaver, and its Joomla.  The barrier of entry must be lowered, which means making the deployment and management of entire grids simple, pain-free, and dirt cheap.  When the barrier of entry is lowered, it will open the gates to a stampede of amateur Metaverse creators seeking their slice of the pie.  Now to be clear, most of these amateurs will not create great virtual environments.  Just like the web now, most of the content will be mediocre. 

A Metaverse Geocities will probably offer free hosting for simple one-sim grids, with a simple template-based creation tools.  Revenue will most likely be provided in much the same way Geocities provided it, embedded ads for free accounts, or a monthly cost for those who chose to upgrade.  An astute observer will note some similarities between this and grid services currently provided, sans the advertising.  One of the primary differences will again be in the linking, as users of such a service will occupy a grid of their own, populated only with their own sims and any hypergrid sims that they should choose to link to.  

A Metaverse Dreamweaver will most likely provide a world creation tool set based heavily off of the tool sets currently used by MMOG developers to layout large environments.  When augmented with a marketplace function (much like a pan-grid XStreetSL perhaps), it will facilitate a drag-and-drop style of world creation.  Much in the same way Dreamweaver simplified complex web functionality into a WYSIWYG interface, its Metaverse cousin must do as well.  Commonly occurring complex scripted objects would be abstracted into click-and-place entities.  Any fine tuning of these worlds would most likely be performed in-world, the Metaverse equivalent to hand-rolling HTML and Javascript. 

Finally, a Metaverse Joomla would abstract and simplify the maintenance of large, complex grids in much the same way Joomla simplifies and abstracts the maintenance of large complex websites:  by providing high-level editorial, publishing, and management tools.  In the case of the Metaverse variant, this would entail on-the-fly creation of template based sims, the ability to monitor real-time activity, permissions based administrative controls, and the ability to extend the grid to include third-party functionality and themes.

I cannot begin to stress how important these services will be to the growth of a open Metaverse. I've listed these three comparisons in this order for a reason.  It is most likely the order in which they must occur.  Right now the major battles of cross-grid content transfer loom just over the the horizon, as the first transfer mechanics are just now being created.   While that battle rages, a Metaverse Geocities can be introducing the world at large to the idea of being a virtual world maker.  Inevitably some compromise will be reached, and a Metaverse Dreamweaver would capitalize from whatever content marketplace system emerges.  As these worlds grow and mature, and the need for simple dynamic management of large scale grids emerges, a Metaverse Joomla can fill the need.

So the question remains: if Opensim is the Apache of the Metaverse, what will be its Joomla?

Continue Reading

2 The Deep Eye Viewer, or how to turn the SL machinima scene on its head. Posted: 5/05/2009

I love the concept of doing machinima in Second Life.  No other platform gives a machinimatographer such absolute control over their work.  But by the same token, no other platform is quite as frustrating.  Second Life was never made with in depth character acting, dramatic lighting, advanced graphics, or cinematic camerawork in mind.   Lag, limitations in the graphics engine, and even in the avatar models themselves hold back a lot of Second Life's potential for high quality compelling cinema.  That said, the quality of work produced by SL machinimatographers is a testament to their creative will and technical savvy.  But is the nature of SL in and of itself the problem, or just one part of it?

I'd like to back up for a second and challenge one of the assumptions common in most forms of machinima today.  Nameably, the assumption that machinima is the direct per-pixel recording of live game engine output.  Why do we do this?  In closed game systems, such as Warcraft it makes sense, what appears on the screen is pretty much the only accessible output. True, you can perform a GL rip and get what ammounts to a 3D photograph of the game geometry, but in terms of using a engine as a filming apparatus, this method doesn't hold much mainstream value.  Some games such as Halo 2 and 3 open things up a little bit by providing a replay tool, which allows for more advanced shot sequences and interesting camera angles.  Yet nothing comes close to the openness of SL, which is literally streaming data about not only the characters surroundings, but also up to the second changes in status, all in a data stream accessed and interpreted through a open source viewer.   Why are we settling for a system of capturing the pixels cranked out by a video card working overtime, only to recieve footage of so-so quality when we could be capturing event data from this stream and saving it to a file for later rendering and yes, even editing.  Imagine what could be possible if you could shoot a scene, decide that your character came into the scene a bit too close to the camera, and instead of having to reshoot the scene, you could just select the character and shift his performance into the desired position.  Imagine being able to apply such forbidden wonders such as depth of field and raytraced lighting to your shots, where the only limitation to visual quality would be how long you wanted to wait for the final footage to render.  Machinima is supposed to marry the advantages of live action and animation, and a system like this would make good on that. It would also knock down the performance barrier, allowing those with less than stellar computers to still shoot beautiful works of machinima.  Call it crazy if you want, I call it the Deep Eye Viewer.

In essence the viewer would operate as follows.  The machinimatographer would set up their scene as normal, taking into consideration all of the normal concerns of staging, props, animations, etc.   They would then activate hit a pre-record mode on their viewer, which would scope out the surrounding area and take note of all major assets present.  This would include terrain, object UUID's, and position data (NOTE: not actually ripping the prim parameters, just getting a reference for later recall), avatar appearances and their intital positioning, and finally windlight settings.  This in essence creates a snapshot of everything that will be required later to re-rez the scene in a semi-local "sim" for rendering and editing.   Once ready, the viewer will prompt the machinimatographer who could then activate the "recording" mode.  This would begin capturing realtime animation and position data from the pre-recorded avatars in addition to the camera position and motion.  Once the machinimatographer is satisfied with the take they can stop recording.   The recording process can be repeated ad nauseum, with each recording saved as a unique "take" within the data file.  

To review or edit a piece of recorded footage, the machinimatographer would select a file from their hard drive and the scene would be loaded into a semi-local (assets are still being called from the grid) "sim".  The user could then play, pause, rewind, and fast forward through the captured data, edit scene element properties, and mute scene objects from visibility.   Muting is useful in cases where the user wishes to either specifically isolate certain scene elements (opening up the possibility of green screen for machinima) or to remove certain extraneous bits of the scene which detract from the overall effectiveness of the shot. The user could add additional cameras to the scene, in effect allowing for multicam setups of the same action.  Also addable would be advanced lighting setups to enhance the pre-existing lighting, such as spot-lights and negative-intensity lights to add areas of shadow. 

One particular addition to the scene data that would be exceedingly useful is the ability to overlay facial animation data onto a avatar's performance.  Lets face it, the current expressions in SL are clunky at best, and downright offputting at worst.  Imagine shooting a scene and then recording the facial acting through a computer vision system that uses a webcam to interpret your expression (oh yeah, its possible).  The same could be done for the hands, which right now are little more than just great big clunky mitts.  The level of nuace these enhancements could bring would be significant to say the least.  These are advanced functions, to be sure, but something which is going to end up having a major impact on the quality of machinima that is produced using such a system, and something for which Deep Eye would be uniquely suited for.

There are of course questions to be addressed before any of this can leave paper.  For example, would SL allow for the sort of on-demand asset-rezzing described, and if so what would its limitations be?  Additionally there are the obvious concerns of the scope of this project and the amount of effort that would be required to bring it to fruition.  Another valid question is how to marry this data playback to a rendering system.  My hunch would be to leverage existing rendering engines such as Blender's, although leaving the interface open to allow for user choice may very well be a valid option too. 

All in all this might be a crazy rant, but hey, that's what I'm here for.  

Continue Reading