Hi Jan, On 28 September 2016 at 06:21, Jan Cools <[email protected]> wrote: > This is a more high level software architecture question considering a > combination of OSG with a RTOS. My application considers 3D visualization and > navigation for automatic machine control. The machine control loop will be > implemented on a RTOS. In this control loop also some functions of OSG will > perform some 3D calculations. For the RTOS I'm looking into the Xenomai > patches for Linux. However this API is written in C while the OSG API is > written in C++. I'm familiar with both languages however never attempted to > combine 2 API's of different programming languages. Is it even possible what > I'm trying to attempt? Any good advice?
Mixing C and C++ libs is what the OSG already does so I wouldn't expect any issues on this front. On the real-time front OpenGL/GLES doesn't make any claims, or provide any controls, for hard real-time. The closest you can get would be classed as "soft" real-time. On the OSG side you have to work within this constraint. With "soft" real-time you are working with operations that will completely within a reasonable time frame but you won't have guarantees that it will always finish in this time. Things that cause big deviations would be when your system gets overload and the driver/OS start having to juggle memory and threads. Your job is then is make the whole system work efficiently and well balanced so you don't get close to point where frame time etc. suddenly increase. OpenThreads that the OSG uses for threading has affinity support that helps here, and by chance you happen to post while I'm actually working on making the affinity support in OpenThreads and the OSG more flexible and controllable, so I'd recommend keeping tabs on this work. For your own project you'll want to decide what threads you'll be wanting to run and on what cores. Make sure the OSG/OpenGL side you stick to efficient fast paths and keep the load well below the maximum that the system can handle - i.e. you'll need to be conservative with how much load you push through, so to get the visual quality you want you may need to be creative to make sure things are done efficiently rather than just brute forcing things. I don't have any idea of how much graphics you'll need and how this relates to the hardware target you have in mind, it could be that you have simple needs on the graphics side and a very capable system so you won't need to optimize heavily as you'll be running safely anyway. So there is chance you won't need to spend time optimizing things on the OSG/OpenGL side, it all depends upon the requirements of your project. If it does turn out you do need to optimize things then be prepared to have to lean quite a bit about how the hardware/drivers/OpenGL/OSG all manage data and processing, there are lots of different techniques for optimizing things so it can be a bit overwhelming to dive in, so I'd suggest taking it step by step, creating prototypes that flesh out different bits of what your system needs to do, lean how to do these tasks efficiently. In the above, where I write OpenGL I mean desktop OpenGL or OpenGL ES. Robert. _______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
