Here is the proper link for OpenSceneGraph Max Exporter on Sourceforge:

http://sourceforge.net/projects/osgmaxexp

-This is the definitive tool for me, creating content for ARive; it fluently exports maps, lights, particle systems et.c, with an OSG-preview window.

OpenSceneGraph Max Exporter is the fabulous work of Joran Jessurun and Hartmut Seichter.

Today Professor Høgset supplied me with the DirectShow-drivers I need to make the DragonFly2 interface with ARive.

It works, but I am not able to set the resolution/framerate any highter than 640×480/15Hz

Either this is a result of DirectShow limitations, emulating the camera as an USB 1.1 device, or I need to fiddle with the drivers some more.

However, I got an idea for ARive-Illumination:

1. Using a camera such as this, that has an onboard GPIO (General Purpose In-Out) connector, it wouldn’t be too difficult to code a snippet that does the following:
2. Register brightness and exposure-values (the camera already processes this information on-board) and output them via this serial RS232-interface
3. Recive and store them continually on the computer running ARive (.dat or .XML-file)
4. Script ARive to read these values, and modify light-settings for global illuminators _live_

Result:

Real-time lighting and shadowing of virtual objects (to a modest degree of realism)

Coding it would be simple, and I can’t see that the hardware would cost me more than ~100,- at Claes-Ohlson.

A “brute force” method of testing how a user could setup occlusion in a simple manner could be:

Make a max scene where two shapes have the same coodinates.

The shapes overlap; should produce a rendering artifact.

Hypothesis:

if object A has a lower renderbin-setting than B, it’s surface will show, while B will be overlapped.

If I could set ARive to render A with a GL_COLORMASK FALSE then the object would be an occluder for the other.

This is not nearly as elegant as Sylvi’s and Julian Oliver’s soulutions, but it would make it easy for any 3dMax and OSGexporter-user to define an object in the scene as an occluder:

I could just make ARive always occlude renderbin[0] and make it an ARive imperative that a designer:

1. Only use one object for occlusion

-If a complex object, or several non-adjacent objects are needed, this could simply be an attached poly or mesh.

2. Always set that objects renderbin to 0 using OSGexporter’s OSGStateSet-helper

-In turn this could remove the need for XML-input.

After some experimenting with my app, I belive I need to load two seperate model-files into two seperate nodes, where the first model is the occluder(s) and therefore has to be loaded firstly… I think…

Testing.

I think I will do the following this semester:

1. Software - Creating new architectural tools.

Create a software package (ARive) for myself and other students that enables us to easily experiment with AR.
This must have the following conditions.

• Open Source
• Good Graphics
• High Performance
• Ease of use:
• Direct export from 3DMAX
• Possibility to control an ARive-application with max and osg controllers:

No need for programming skills, only proficiency in MAX

• Easily expandable (plugins)
• Interaction (HW/user input)

This could be of use for AHO in general and the work of the AR-lab there, making the technology more available to the school and its students. Furthermore it could possibly draw interest from other faculties (IDE) and gather more resources for the development of the AR-community here.
2. Research - Studying the tools as I work with them.

Utilize ARive during my project and continually log my thoughts and impressions about the tool.

A lot of the development in the field today seems to be purely “technical”. -A lot of papers and projects aim at enhancing limited aspects of the technology, such as tracking or interactivity. Few projects focus on a direct and practical implementation of the technology to achieve a complete product, i.e. software or architecture.

3. Utilization - Creating an Art-pavillion dedicated to promoting “digital art”, in a variety of forms.

Digital art is something of an underdog in many communities today, mainly because of the digital tools involved in its production. -This is for me a resemblance of the Salon-war that many of the modernist artists were engaged in. However, there is a wide variety in the field, ranging from “classical” paintings, to high-tech installations.

I want to create a expo for this kind of art, and intend for the pavilion to be an integral part of the exhibition itself, utilizing AR to exhibit the pieces, or perhaps the building to be virtual in itself.

For my own part, I want to explore how AR can be used in this context, and also to hone my 3d modelling skills in its representation.

4. Architectural Coherence

I want to merge all of these ideas into one project, so that the technology is at the same time both the means and goal of the pavilion. This as a statement to try and bury the notion that architecture and digital architecture is at odds with one another.

I’ve hired Kjetil Austvoll-Dahlgren (paying him in mayonnaise and beer) to find a name for my upcoming(!) ar-software engine.

He proposes ARive - Augmented Reality Interactive Visualization Engine

Cheers!