Greetings all. I am working on a simulation system that runs on a single Dell, Xeon dual-processor PC with 1G of DDR2 memory. The hardware system consists of the PC and 2 LCD screens, one above the other, with the lower LCD screen being a touch screen. The upper screen graphical display is driven by an executable, and the lower has it’s own seperate executable. The simulation system itself has it’s own executable that manages everything else and sends data to the 2 graphics executables for display.
The way the system has worked in the past, Performer was only loaded in the upper executable, because the upper screen is where the “out the window” view from the cockpit is displayed. There is also a HUD, drawn in 2D using OpenGL, that is overlaid on the 3D graphical scene. The lower executable only ever drew in 2D. It handled menu displays, cockpit button display/touch functionality, and display of RADAR and other MPCD (Multi-Purpose Color Display) pages. There is a left and a right MPCD being draw on the lower screen along with some cockpit buttons during flight.
I am currently modifying this system to allow for 3D graphics to be displayed in the MPCD areas on the lower screen (to simulate a new sensor package that has a camera built into it that can view terrain and zoom, etc.), which means I have had to modify the lower executable to load the Performer libraries, rip out all of the GLUT callbacks and implement my own graphical main loop logic.
The way the old system logic worked, when you fired up the simulator, the upper executable set up a 128Mb pfArena, started loading the terrain files (*.flt files) and the end result was a pfScene pointer to the scene graph that was generated. When I implemented the lower Performer initialization, I had the lower executable run pfInit() seperately, set up its OWN pfArena of size 128Mb and load the terrain files into that, generating it’s own scene graph. This is my problem. I am essentially loading the scene graph twice when I’d really like the upper executable to generate the scene and somehow allow the lower executable to get ahold of that pointer/memory area to traverse the one scene graph. I am noticing a significant performance hit even when I am not displaying 3D graphics on the lower screen when I run my createScene routine for the lower AND the upper seperately. I suspect this is dues to the extra overhead of having 2 scene graphs, and both scene graphs are generated off the same terrain files so they are IDENTICAL!.
I researched a bit, and thought that pfDataPools may have been the answer to my problem. I attempted to have the upper executable set up a pfDataPool to store the scene graph, then have the lower executable grab a handle to it. However, that did not work at all and further reading indicated that the processes trying to share a data pool must be within the same virtual address range. As these are two seperate graphical executables running, and they are both firing off their own pfInit() calls, I am sure that they are in seperate VM address ranges.
My question would be the following: Is it possible to do what I am attempting to do, or am I stuck having to have each seperate graphical executable generate it’s OWN version of the scene graph being generated?