20,741
edits
CompositeViewer support: Difference between revisions
Jump to navigation
Jump to search
m
→Image Sharing
m (→Image Sharing) |
|||
| Line 722: | Line 722: | ||
=== Image Sharing === | === Image Sharing === | ||
Sharing of images is possible by using a frame | |||
buffer copy to osg::Image, or just having multiple FBO's all within | |||
one graphics context. <ref>https://groups.google.com/g/osg-users/c/9oDKlqiGba8/m/ZkjY66niTkcJ</ref> | |||
If you want to use the result in a separate window/display you'll need | |||
to copy the result back to an osg::Image and then use this image on | |||
another texture on the other windows. osg::Camera supports attaching | |||
an osg::Image to it and will automatically copy the frame buffer(or | |||
FBO) to the image, and osg::Texture* all are able to detect an update | |||
to an osg::Image so will automatically download the result, so it's | |||
possible to do this wiring up relatively easily, but.. performance | |||
won't be great as it requires a round trip to the CPU/main memory.<ref>https://groups.google.com/g/osg-users/c/OBg4fBOj52Y/m/vRkBJS6GPaIJ</ref> | |||
The best way to deal with the high cost of these operations is to | |||
avoid them completely. Try to use algorithms that can use render to | |||
texture using FBO's and read this textures directly in other | |||
shaders. Never try to copy the results back to the CPU/main memory, | |||
this does force you to do more work on the GPU and rely on more | |||
complex shaders but in the end it means that you don't have to force a | |||
round trip to the GPU. | |||
It's the flushing of the fifo that is the problem, that's why it's so | |||
slow, not the data transfer itself. Once you flush the fifo you loose | |||
the parallelism between the CPU and GPU. | |||
The only way to hide this is to use PBO's to do the read back and do | |||
the actual read back on the next frame rather than in the current | |||
frame. In your case you might be able to get away with this, a frames | |||
latency might not be a big issue if you can keep to a solid 60Hz and | |||
the values you are reading back aren't changing drastically between | |||
frames. | |||
osgscreencapture uses a frame latency when it double buffers the | |||
PBO's. It doesn't matter whether it's frame buffer or FBO, the PBO is | |||
only related to memory management.<ref>https://groups.google.com/g/osg-users/c/JY1mVGofOEg/m/8P7j5titqVcJ</ref> | |||
* Sharing of images is possible by using a frame buffer copy to osg::Image, or just having multiple FBO's all within one graphics context. If you can have the frames all done synchronously then perhaps you could have one frame loop and just disable the cameras via camera->setNodeMask(0x0); that you don't need updating on each frame, i.e. main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so get update on frame in 3.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref> | * Sharing of images is possible by using a frame buffer copy to osg::Image, or just having multiple FBO's all within one graphics context. If you can have the frames all done synchronously then perhaps you could have one frame loop and just disable the cameras via camera->setNodeMask(0x0); that you don't need updating on each frame, i.e. main viewer runs at 60Hz, and the other RTT cameras run at 20Hrz so get update on frame in 3.<ref>https://www.mail-archive.com/osg-users@lists.openscenegraph.org/msg07360.html</ref> | ||