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 (Virtual) World Domination Pointers Posted: 8/17/2009

Alright I've got a serious bee in my bonnet, so please excuse the bluntness. I've been sitting on some of these ideas for far too long. These are some ideas for projects of business ventures in/for the Metaverse. The ones that interest me after this posting might get a more fleshed out dedicated post. Feel free to do whatever you will with these.

SimpleViewer: A Beginner-Friendly Metaverse Viewer

Please, for the love of the FSM, somebody do this. It boggles my mind that despite the myriad of development work being done across the OS viewer scene, all of the development work has only made viewers more complex and feature heavy. If we want the Metaverse or SL to really attract more than the hardcores, we can't keep up like this. Its like giving a industrial-grade metal smelter to a kid who just wanted a EZBake oven. Beginning users don't need or want a lot of power or fancy functionality, they just want to be able to log in and interact with the world without wrestling with cluttered menus and counterintuitive interfaces. Please, someone take Hippo and strip it down to its chasis. Then design a easy, intiutive user interface that won't make granny want to put her fist through the computer. The world will thank you.

MetaJobs: A Job Board for Metaverse Workers

Can somebody please answer me why the Metaverse doesn't have a unified job board? No, XStreetSL's employment section of their forums don't count. I'm talking about something meant to serve both SL and the Opensims. Content isn't quite portable yet, but talent sure is. Anyone who's searched for a job in SL knows what a goosechase that is. Making a one-stop web-shop for all things employment would be a big boon for both potential employees AND employers. It would be pretty easy. So easy it could be done with a PHPbb and a domain name. Yes it could and should be more intricate than that, but its really all you would need to start. I have a hard time believing theres no one out there who doesn't see the money potential.

Convoy: A Secure Marketplace for Pan-Metaverse Commerce

So I just said that content isn't portable between grids yet. That's not completely true, but for the majority of normal Metaverse users its the reality. The truth is the functionality to import/export conent exists. What's missing is the system of trust between content makers and grid operators to allow people to buy things in one grid and move with them to another. This creates a giant mess. So what if a company stepped in with a XStreetSL style marketplace, and a dedication to absolute security? Content creators, trusting the market to not sell to unsafe grids, upload their content to the market and put it on sale. The company accepts applications from grids to gain delivery access to the grid. The company verifies they are running a content-safe server code and enters into a contract with the grid to deliver goods to the grid so long as the server remains kosher. Once verified as safe, customers from that grid can buy from the Marketplace and have the purchased content delivered to their account on their grid. The company could make money any number of ways, including delivery charges, listing upgrades, and other services. Just remember the company's number one service is the trusted bridge it provides for content creaators and grid owners.

I'm sure I have other ideas I've spaced on. I'll write about them later.

Continue Reading

0 Upcoming Posts Posted: 7/02/2009

I've come to two realizations over the past week. One: I love writing articles, and two: I have more things to write about than time currently allows. So therefore, I'm going to just jot down a bunch of the topics for posts I plan to write and release soon.

• Tools for open source invention of real world things
• Community vs. Content on the Hypergrid
• How to capitalize on the lack of content in the open Metaverse
• Modular systems for third world empowerment and infrastructure
• How computer vision will revolutionize machinima
• Can radio be crowd sourced?
• Funding the Metaverse explosion
• Bringing the talent from SL to the open Metaverse
• Rapid game design prototyping system
• The Encyclopedia of Stuff
• Mapping material flows and artificial metabolisms
• Citizen journalism through social multimedia mash up tools
• Planning infrastructure through modular evolution
• Hybrids in the skies
• Air deployable emergency aid systems
• Meshing social media and consulting
• Can flash mob tactics be applied to the freelance job market?

For now that's all of the ones I can think keep track of that I need to write about. Looks like I need to get cracking!

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