Summary

This page describes the process and supplies the code for building a SPICLOPS enabled osgViewer for use with eLumens SPICLOPS curved-dome correction API and their dome projection devices.

Original code by Farshid Lashkari (flashk a t gmail) A simple example of getting the Elumens Spiclops API working with OSG. There are still some small bugs/issues with this sample. If you find a fix or a better way of doing something, please let me know.

Overview:

Get the APIs from eLumens

Get the osgSPICLOPS source

Create or download a make/project file

Build it

Adapt it to your application

Known Problems

Get the APIs from eLumens

Regretably, you cannot share these files, you must get them from eLumens themselves. This link tells you how, but no-one ever answered my queries there. If you have an eLumens product (or a client who has one) have them pester their support rep to get you the necessary API files.

Get the osgSPICLOPS source

Create or download a make/project file

Clone the osgViewer target. You won't need any additional osg libraries. You will need to add the appropriate spiClops.lib/spiClopsD.lib to your link phase.

Build it

Nothing difficult here.

Adapt it to your application

Really all you need to add are the objects and methods (outside of main()) from osgSpiclops.cpp to your app. Insert the code in lines 331-345 into the appropriate part of your Viewer setup. You will already have a realize() call. Beware of single-threaded caveat mentioned in the comment (see below).

SPI-specific parameters are set to constants in initSpiclops() using calls to spiSetChanOrigin, spiSetChanSize, spiSetChanFOV, spiSetChanTessLevel. Number of channels (and therefore channel configuration) is set to a constant 3 via numChannels on line 329. Projection method (defaults to SPI_PF_NORMAL) is set on line 333 in the creation of the InitSpiclopsCallback?. Different methods seem to work better or worse on different hardware. Try different variations.

Known Issues

This has been compiled on OSG version 0.9.8 (plus some later CVS checkout changes) of OSG by Chris 'Xenon' Hanson

I (FL) had to modify the Producer::Lens class to allow manually setting the projection matrix. CXH: These Producer changes have been submitted and accepted into Producer after .9.8.

All the spi samples call glClearColor and glClear before spiFlush, but this was sometimes causing a crash on my (FL) system, so I (FL) commented them out. 01/05 CXH: This has been found to have been a driver bug, and is not necessary. Those code has not yet been updated.

I (FL) could only get the sample working by starting the osgProducer::Viewer in single threaded mode. 01/2005 CXH: I have used it in both modes and it works ok both ways for me. The code is still set to single-threaded at this time. 05/2005 CXH: It still appears to require single-threaded for channels > 1.

CXH: Picking behavior is unknown at this point. SPI provides some code to handle the screen transform to make picking work, but I haven't tried working with it yet.

CXH: Turning on Framerate statistics crashes the program on exit. Not sure why.

CXH: Billboards read their orientation from the real view vector for each SPICLOPS sub-channel rather than from the intended Camera view vector. This means that they may exhibit erroneous behaviour when crossing channel boundaries, especially between the side and top channels.

CXH: The original code was not designed to handle channels=1. I haven't had a chance to migrate the changes from my codebase to the demo codebase yet. I am Attaching the diffs from my codebase, while the line numbers are wrong, the changes should still be relevant to the original demo code, but you'll have to make the changes by hand. [attachment:SingleChannelDifs.zip
*CXH: The original code also improperly turns off near/far computation. Instead of the existing setComputeNearFarMode call, you must instead viewer->getCullSettings().setComputeNearFarMode(osgUtil::CullVisitor!::DO_NOT_COMPUTE_NEAR_FAR);