Here is a more complex kind of content, that I did not think would be possible until I discovered I could use Flash to develop an interface for ARive, thus opening for online-integration with SQL.

Graphitti is illegal as an artistic medium here in the capitol of Norway, with the police enforcing a zero-tolerance policy.

Virtual Graphitti is an online ar-service that works as follows.

Content:

Artists can log on to a website, i.e. www.formbureauet.com, and register themselves anonymously.

With this account, they can upload a 3D-model and link it to a marker on the site.

After that, they can print the marker on a sticker, and place it anywhere in Oslo. = Legal, no policy against stickers.

Alternatively, they could draw or spray the marker by hand on any location.

Audience:

Using a smart-cell phone, people discovering the markers around town, can do one of two;

1. Take a photo, and send it to wap.formbureauet.com, and get a new photo in return, displaying the model superposed on the marker.

2. Download a portable version of ARive on their phones, and watch the virtual graphitti in real-time.

Sketch:

Virtual graphitti by Amund Schweder, render by myself:

This is an extension of Virtual Spaces, but perhaps even more traditional AR-use:

High-def models of design-furniture, are linked to a marker, that can be placed in an appartment.

An easy and intuitive way of seeing how refurnishing you place could turn out. Move the marker-move the furniture.

I will cooperate with my brother-in-law Pål Lunder of fjordfiesta furniture to display some pieces of the Scandia-chairs (by Hans Bratterud).

This is a beautiful example of Scandinavian design, and I’ve already done the 3d work for the Scandia Junior chair.

Sketch:

Model of Scandia Junior:

Not original in any way, but necessary to use ARive in an architectual context.

I want to use markers in a physical environment to introduce new structures, or mask out existing ones.

On the experimental side, I would like this to encompass “impossible perspectives”… I’ll post some more sketches soon.

Unfortunately i need Occlusion for any of these to be really interesting.

This is an idea for a kinetic sculpture, inspired by the works of Alexander Calder.

It is a branching structure, resembling a SceneGraph itself, with the _root at top, hooked to the ceiling.
At the end of each branch is a “node”, with a marker.

This physical installation is to hang freely in a room, while a camera or a head mounted display will allow an audience to either watch it, or interact with it.

The installation will react to the physical enviroment in terms of small local winds in the environment, causing it to rotate, or spin the nodes.

Virtual Objects attached to the nodes, will then flicker in and out of appearance, and move parallel to the physical object.

This could be video, or models, either attached close to or over the markers, or distanced from them, moving, appearing and disappearing across the room.

I like how this could explore the relation between physical/virtual, and how it also represents an interface on many levels:

It is a representation of the scenegraph, but also takes input from wind, but not with a anemometer/wind gauge, but a camera.

Here is a rough sketch:

I’ve just set up a separate page to expose the ARive project exclusively. you can find it here -and with its own button on the top of every page, here at formbureauet.

The blog was originally for my own documentation, and is getting too comprehensive and messy for anyone else to get a grasp of.

I’ve just written down a very rough presentation, but will continue to polish it as I develop it further.

I’ve gotten in touch some people that are also working with AR, and gotten a lot of help with my occluder-issues, newbie to C++ as I am.

I would already like to thank Julian Oliver for pointing me in the right direction, and give some attention to his AR-game levelHead. -This is one amazing piece of work.

Also my salutes go to Sylvi, for supplying me with some sourcecode to play around with. Check out the Naver based on osgART project.

And just recently, Raphael Grasset, one of the developers of osgART himself, found my videos on youtube and contacted me, telling me I could direct some of my questions to him.

Everyone here have my sincere gratitude!

I’m not giving up on occlusion yet!

I’ve recently put Object Occlusion on hold, after realizing that I cannot let a programming-feature hinder my overall development of ARive, and both Proffesors Høgset and Sørensen have urged me not to forget to also develop content.

So, I have in my influenza-fever gotten out of bed, and sketched a lot, and built a beta-GUI right away.

I’ve made it in Flash and SWFkit. Flash to make it look good, and save me from making it in C++, and SWFkit to enable the GUI to send calls to ActiveX controls, the Windows API, C++ and databases etc.

At the moment the GUI is quite functional; It has a fluent interface, and loads a simple XML database I built to store the library of all the files.

I didn’t know I could build stand-alone apps in Flash, until I discovered SWFkit, even apps that are independent of Adobe/Macromedia’s flash-player, so this has scrambled my progression-plans a bit (by speeding up what I had planned to do later), and I have to rewrite my plans.
XML was easier to get a grasp of than I feared, so now I am ahead of schedule in some aspects of development, but ARive still lacks a lot of functionallity.

Here are some screenshots:

After having lots of trouble implementing occlusion in ARive (and learning C++ and Visual Studio on the run), I’ve descided to narrow down my project, without neccesarily feeling that I’ve failed.

I want to make ARive as good as can be, but within the time-limits of the semester.

Thus, I’ll try to develop the software in stages of completion, so that I can stop implementing new features if I run out of time.

ARive BETA 1: (Status Quo)

Criteria:

A working executable

Marker tracking

Custom Markers (within design parameters)

Video display

Rendering:

support for textures: tiff, jpg, gif, png

support for baked maps

support for cube-maps

support for omni and directional lights (dynamic)

support for animation

support for particle-systems (some, simple)

….

3D-formats:

.osg (OpenSceneGraph native ASCII)

.ive (OpenSceneGraphnative binary)

Via converter:

.3ds

.obj

.pfb

…

Direct export from 3DMax 9

Geometry

Splines

Particle systems (some)

Animation

Textures

…

High Quality Performance

Support for low-end devices

Console-level loading (commands via prompt)

ARive BETA 2: Next step

Geometry Occlusion

Arive Beta 3:

XML-loading via parser (TinyXML?)

Branching of ARive into two executables

“ARiveB3.exe” <- normal edition,user defined lights

“ARiveB3-shadow.exe” <- real-time simulated shadows using object occlusion. Ideally parametrically controlled via XML/Max

ARive BETA 4:

Graphical Interface:

Stage 1:

Creates loading-scripts

Stage 2:

Creates XML-files for parsing togeather with loading scritps.

Stage 3:

Creates an index of stored XML-scripts that can be run at convenience

ARive BETA 5:

msi-installer

ARive RC1 –

Test with fellow-students

ARive 1.0 Champagne.

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.