It is likely the non-shader code path (fixed-function pipeline) will also go away in the next twelve months (~ early/mid 2022). In addition, adopting OSG 3.6 means that the experimental CompositeViewer Support can be more widely enabled and tested (it is already enabled by default on next).Īlso, as part of the CompositeViewer effort, Canvas FBO rendering is in the process of being moved out of the scene graph into dedicated viewer-level cameras, which provides better support/integration with OSG threading and fixes the long-standing issue where Canvas textures were being rendered twice per view unnecessarily due to the original new/far camera scheme.įurthermore, to support Canvas (actually CanvasPath/all SVG handling) on Core profile, the plan is to migrate our Canvas Path backend from Shiva to ‘something else’ (see Shiva Alternatives) which implements the required drawing operations, unlike Shiva, ShaderVG or NanoVG can target Core-profile OpenGL. More importantly: Adopting OSG 3.6+, moving to the OpenGL core profile, WS 3.0, Osm2city buildings, Photoscenery and Compositor shadows & lights.
Hopefully, once I get the Windows-7 machine built, P3D up and running, and some hands-on with the SDK will be able to ask more specific questions.Note FlightGear is currently undergoing a lot of huge changes. Kind of compelled to go this route with an external sim question is how best to proceed. Given all that, the P3D visuals and addons are vastly superior to what is available under FlightGear and if I'm going to invest time and money for a large collimated display (which I already have) makes sense to have top-of-the-line visuals.
It's a proven and tested architecture, in fact, the electronics were used to build pilot workstations for the Global Observer program at AeroVironment.
Moving all that and redesigning things to work under windows-7 would be a Herculean effort. And the FDM in FlightGear is a world class product, for all I know the P3D folks might be using it as part of the OpenEaagles project.
FLIGHTGEAR GRAPHICS PLUS
The 737 cockpit runs with HRT scheduling under Linux/Xeonami, plus all the electronics and interface boards are custom built and designed to work with Linux drivers. To run everything on P3D would require a real-time embedded platform. The goal right now is to use Prepar3D as a graphics engine to generate the OTW view and warp and blend the multiple images for the collimated display projectors.Īny suggestions, guidance, or pointers would be appreciated. Is source code available to edit and recompile the client.dll? For the moment there is no need to transmit info from Prepar3D, although that might change down the road. Is that feasible or does one have to deal with simconnect or FSUIPC to talk with the app. Then modify the client.dll to create a client socket to receive the udp packet and stuff the variables into the Prepar3D packet. The objective is to replace the FG scenery which is just okay and a far cry from the richness available and addon support available in PrePar3d and run it under Windows-7 and DirectX-11 on the graphics machine.īased on my limited understanding in reviewing the docs and forum topics, my approach is to send to the client.dll the lat/lon and position state vector (pitch, roll, yaw, heading, and altitude) via a UDP socket from the flightgear machine. The graphics machine, also running under Linux, performs the warping and blending of the scene for the four HD projectors. The visual graphics are created via a separate machine receiving position and orientation from the flightgear machine. The 737 cockpit and flightgear exchange data and controls via UDP sockets over a LAN. In my case, running flightgear and a fullscale 737 cockpit under Linux and wish to use Prepar3d to generate the graphics for the collimated display ( see videos on youtube as 737castle or the opencockpits forum under 2 place collimated displays ).
FLIGHTGEAR GRAPHICS PRO
New to PrePar3D and about to purchase Pro license and SDK development chair, but would like to first confirm my understanding on connecting to an external sim.
0 kommentar(er)
