First, Linux is essentially the same as UNIX, no problem there. However, there is no "silver bullet" for cross-platform app development in general. Open Inventor itself is mostly platform independent. There are a few methods unique to UNIX or unique to Windows, but they are flagged in the help files. The real problem is the user interface. Here are some of the many possible strategies.

• Write command line apps only (these can be very portable but inherently have a very limited user interface).
• Use dialog boxes only for the user interface -- then you can use the DialogMaster component of Open Inventor to create portable apps. These user interfaces are also limited, but can be effective for test, demo, and prototype apps.

• Use a third party cross-platform user interface (UI) toolkit. This may require some work on integrating Open Inventor with the UI toolkit, especially on UNIX where the Open Inventor SoXt components are specifically Motif widgets. However some UI toolkits use Motif on UNIX and allow you to get the actual Motif widget handle for a UI object. On Windows, the Open Inventor SoWin components only use Win32 APIs, so they should work with almost any UI toolkit that allows you to get the native window handle (HWnd) for a UI object. See, for example, Qt (http://www.trolltech.com).

• Write the user interface twice, once using Motif and once using Win32 and/or MFC. This is the traditional approach. It provides a "native look and feel" in both environments, but at the cost of significantly more programming.

• Write the user interface using Win32 and/or MFC and use a porting environment to build and run on UNIX. The major ones are Wind/U (http://www.bristol.com) and MainWin (http://www.mainsoft.com). Mercury Computer Systems does not directly support these but we have customers using them. It allows a single source, but requires additional licensing and a runtime environment.

• Use Java. Mercury provides MeshViz and Open Inventor as a Java class library. You can write the entire application in Java or you can write the user interface in Java and use JNI to call into a C++ application "core". We have customers doing both. This allows a single source, but there can be problems with Java portability, security, etc.

The answer is a very resounding yes! However, one cannot arbitrarily mix Open Inventor and OpenGL calls in one's program. Usually the OpenGL calls are placed in an SoCallback node or in a custom node. You must be careful to save and restore any OpenGL state, so that Open Inventor doesn't get confused about which state changes it needs to send to OpenGL. The code might look something like the fragment below.

Chapter 17 of the Inventor Mentor addresses this whole area and is entitled "Using Inventor with OpenGL". The Mentor example programs are included with the Open Inventor distribution, hence you will receive some example programs on OpenGL being used with Open Inventor.

Note: The callback function will be called by every action that traverses the callback node. Remember to test the type of the action if the function should do something different (or not at all) for different actions. For example:

if (action->isOfType(SoGLRenderAction::getClassTypeId()))

Specifically, callbacks should generally not make OpenGL calls except when handling an SoGLRenderAction. This is the only time that Inventor guarantees that a valid OpenGL context exists and is current.

Note: By default the callback node may become part of a render cache (OpenGL display list). In this case, so long as the cache remains valid, the callback node will not be traversed by the render action. If the callback function always makes the same OpenGL calls, this might be OK since the OpenGL calls will be part of the cache. But if the callback function interacts with the application or performs different actions at different times, then it should disable render caching. For example:

• It is not guaranteed that GDI calls can be made on an OpenGL window. It does work in almost all cases with the Microsoft generic OpenGL, but may not work with some 3D accelerators.

  You can tell if GDI rendering is allowed by looking at the PIXELFORMATDESCRIPTOR structure, specifically if the bit PFD_SUPPORT_GDI is set in the dwFlags member. (The oglinfo program supplied by Mercury displays info about GDI support.)

• There is absolutely no way to do GDI drawing on the OpenGL "back buffer". You can only draw on the "front buffer" (aka the screen). (This is a "feature" of OpenGL.) So you need to make sure the scene has been rendered and wglSwapBuffers has been called before doing GDI drawing. Usually this is not too hard in an Inventor program.
  The boxZoom example (...\src\Inventor\examples\IVF) shows one way of using GDI calls.

[NEW: Open Inventor 3.0] Yes!
Open Inventor 3.0 includes multiple thread support. Here are just a few of the ways you can use multiple threads in your Open Inventor 3.0 application:

1. One thread for rendering, another thread for computation.
2. Multiple threads rendering different scene graphs.
3. Multiple threads rendering the same scene graph.

In a multithreaded program, every thread that uses Open Inventor classes must call SoDB::threadInit.

See the help file for additional info. The following two topics will likely be of particular interest: the Multi-Threads Overview and SoDB (threadInit method).

In particular, note that if more than one thread is accessing the same scene graph, each thread should request a read or write lock (depending on its needs). See SoDB::writeLock, etc.

Yes, this is possible.

You would need to have installed an X server on the PC, and in particular it would need to support the GLX extension because GLX is the protocol that UNIX OpenGL implementations send over the network.

If you want 3D acceleration (and this would be highly desirable), the X server's GLX implementation must be able to take advantage of the 3D hardware accelerator installed on the PC. We know of two PC X server vendors that do support the GLX extension and offer support for hardware acceleration: Hummingbird and WRQ. There may be others.