Foam Sculpting

The inspiration for this work came out of a project we did with some industrial design students. Their job was to create some input devices for my SAR Airbrushing system. First up, we had a  meeting where I showed them a very early stages of development version of the system, to give them an idea of what we were doing. They went away and came up with ideas for input devices, and in the next meeting had a bunch of sketches ready. We discussed the sketches; what we liked and what we didn’t like. Next, they brought us foam mockups of some of the designs. We discussed these, and then eventually they came back with full CAD models ready for 3D printing. They did a great job by the way. But it got us thinking:

How can we make this process better?

Augmented Foam Sculpting is the result of this work. It allows a designer/artist to simultaneously create a physical design mockup and matching virtual model. This is a Good Thing™, because it utilises the skills and tools that designers are already using.

The system works by tracking the position and orientation of both the hot wire foam cutter, and the piece of foam the user is sculpting. We can track the motion of the hot wire as it passes through the foam. From there, we can create geometry that matches the cut path, and perform a Boolean difference operation on the foam geometry, to replicate the cut in the virtual model (Before any of you “Booleans are evil” people get to me, I’d like to point out I’m only dealing with, and creating, triangle meshes. There are no 11 sided polygons here).

Using projectors, we can add extra information to the foam as the user sculpts. We implemented 2 visualisations to aid designers when creating specific models. Cut Animation displays cuts to be made as animated lines on the foam surface. Once a cut has been made, the system moves to the next one. This visualisation could be used to recreate a previous object, or to instruct novices. An algorithm could be developed to calculate the actual cuts that need to be made, reducing the amount of planning needed when making an object.

The second visualisation, Target, projects a target model so that it appears to be inside the foam. The foam is coloured based on how much needs to be removed to match a target model. This could be used to create variations on a previous model.

Finally, we can use 3D procedural textures to change the appearance of the foam. For example, we implemented a wood grain 3D texture. This works pretty well, because as you cut away the foam, the texture updates to appear as though the wood was actually cut. 3D textures are also ideal because we don’t need to generate texture coordinates after each cut.

For all the details, please have a read of the paper. If you have any questions/comments/feedback/abuse, please comment on this post, or send me an email.

Michael

http://www.swiftless.com

Multiple X Screens

The easiest way to do dual screen output is if you have your X server configured so each output is its own X screen. The first thing you need to do is make sure you have enough screens. Finding this out is easy enough:

int getNumScreens()
{
    osg::GraphicsContext::WindowingSystemInterface* wsi = osg::GraphicsContext::getWindowingSystemInterface();
    osg::GraphicsContext::ScreenIdentifier si;
    si.readDISPLAY();
    return wsi->getNumScreens(si);
}

You should do this before attempting to create your screens to make sure the X server is configured correctly. Otherwise OSG will throw an error when you try and create a graphics context for a screen that doesn’t exist. Setting up the viewers is fairly straight forward:

//Create main scene viewer
 
ref_ptr<osgViewer::CompositeViewer> compositeViewer = new osgViewer::CompositeViewer;
 
// create first view
osgViewer::View* v0 = new osgViewer::View();
v0->setUpViewOnSingleScreen(0);
 
// add view to the composite viewer
compositeViewer->addView(v0);
 
// do the same with the second view
osgViewer::View* v1 = new osgViewer::View();
v1->setUpViewOnSingleScreen(1);
compositeViewer->addView(1);

And thats it. You also need to set the scene data for each of your views and a couple of things I’ve missed, but that is the basic idea. The problem with this method is it creates 2 graphics contexts, which in most cases will cause a performance hit.

Single X Screen, Single Context

I looked into this method because I use TwinView on my Linux desktop boxes. Of course, TwinView means that there is only 1 XScreen that spans both monitors. Therefore, the getNumScreens function above will return 1. I have also set up our projector setup to use TwinView, so I don’t need to have one lot of code for testing on the desktop and then do something completely different when using the projectors. The other benefit of this approach is you only create one graphics context.

First thing we do is get the dimensions of the screen, which will be the combination of both screens.

// get the total resolution of the xscreen
osg::GraphicsContext::WindowingSystemInterface* wsi = osg::GraphicsContext::getWindowingSystemInterface();
unsigned width, height;
wsi->getScreenResolution(osg::GraphicsContext::ScreenIdentifier(0), width, height);

Once that is done we can create our (single) graphics context.

// create a context that spans the entire x screen
traits->x = 0;
traits->y = 0;
traits->width = width;
traits->height = height;
traits->windowDecoration = false;
traits->doubleBuffer = true;
traits->sharedContext = 0;
traits->overrideRedirect = true;
osg::ref_ptr<osg::GraphicsContext> gc = osg::GraphicsContext::createGraphicsContext(traits.get());

The important one here is overrideRedirect. Some window managers (I’m looking at you Gnome) will redirect the position of your graphics context, so it won’t appear where you want it. The overrideRedirect option is kindof new, it does not exist in the version of OSG shipping with Ubuntu 8.10. Therefore, I am running the latest stable release (2.6) compiled from source.

To get the equivalent of 2 screens to draw on, we create 2 views like before. However, we have to set their viewport manually. Here we just make v0 use the left half of the screen, and v1 use the right half. Easy enough?

//first screen
osgViewer::View* v0 = new osgViewer::View();
 
osg::ref_ptr<osg::Camera> cam = v0->getCamera();
cam->setGraphicsContext(gc.get());
cam->setViewport(0, 0, width/2, height);
compositeViewer->addView(v);
 
//second screen
osgViewer::View* v1 = new osgViewer::View();
osg::ref_ptr<osg::Camera> cam2 = v1->getCamera();
cam2->setGraphicsContext(gc.get());
cam2->setViewport(width/2, 0, width/2, height);
compositeViewer->addView(v1);

setViewport sets the viewport of the camera. The first 2 parameters are the position in the context’s window, the next 2 are the dimensions. So, each view gets width/2 for the width, and the second screen’s position is offset by half the screen width meaning it starts on the second monitor.

Conclusion

And there you have it. Two methods for dual screen using OpenSceneGraph. Looking at the code, it is fairly simple. However, after browsing the doxygen docs for OSG it was not at all obvious to me. Of course, the osg-users mailing list was a big help here. In fact, here is the thread from the mailing list

Cheers
Michael