Re: [osg-users] OSG on Universal Windows Platform
Chris Hanson wrote: > I was pretty sure UWP also prohibited the OpenGL API, which would mostly be a > deal-breaker unless you use ANGLE or something. Yes, I am aware of the problem with OpenGL, thank you for pointing it out. I'm indeed using Angle and I still don't know if the GL part is going to work... I've to solve these compilation errors first -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70223#70223 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] OSG on Universal Windows Platform
Hi, I'm trying to compile OSG for the Universal Windows Platform (https://docs.microsoft.com/en-us/windows/uwp/get-started/whats-a-uwp). At the moment it looks to me like a pretty big challenge, considering that UWP limits the use of some classic desktop API (on which OSG relies). In UWP it is not possible to use many CRT functions (https://msdn.microsoft.com/en-us/library/jj606124.aspx), like getenv() for example. Also, the OpenThreads Win32 library seems completely unusable, since it relies on many features not supported on UWP. Is there any workaround for these problems? Thank you! Cheers, Lorenzo -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=70208#70208 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading problem, OpenVR integration
Problem solved! :D
As guessed by Robert, the GL objects were not compiled properly.
In the old desktop-version of the software the compilation of the scene was
performed by a osgUtil::GLObjectsVisitor created and launched in a subclass of
osg::Camera::DrawCallback, which was assigned to the main camera as a
"preDrawCallback" (I don't know if this is the right approach but it works and
I don't want to mess up with the old system :) ).
It works fine but it relies on the renderer of a single main camera, the very
camera that osgopenvrviewer deactivates
(https://github.com/ChrisDenham/osgopenvrviewer/blob/master/src/openvrviewer.cpp#L61)!
It means that in the VR environment that preDrawCallback was never called and
the compilation was never performed.
The solution? I simply assigned the same callback also to every slave camera
present in the view (in the osgopenvrviewer case these are two RTT cameras, one
for the left eye and one for the right eye):
Code:
for (unsigned i = 0; i < view->getNumSlaves(); ++i)
{
osgViewer::View::Slave& slave = view->getSlave(i);
if (slave._camera.valid())
{
slave._camera->setPostDrawCallback(compilationCallback);
}
}
I used "setPostDrawCallback" because a preDrawCallback was apparently already
assigned (replacing it resulted in a full deactivation of the rendering, black
screen).
Is this wrong on any level? It works like a charm, no more frame drops :D
Thank you very much guys, your help pointed me to the right direction.
A special thanks to Robert!
Cheers!
--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=69237#69237
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Loading problem, OpenVR integration
Hi Robert! Thank you for your kind reply. robertosfield wrote: > Is the scene static or is your application adding new scene graph > objects through the lifetime of the application? The scene is completely static and motionless :) robertosfield wrote: > It's only new objects that you need to compile to make sure that the > graphics objects are created and ready to download to the GPU Ok, perfect. I'm pretty sure that the compilation process is already performed on the entire scene by the system I'm working on. Do you think that my problem could be caused by a missing compilation of objects? If you say that it might be the case, I will investigate more on this. robertosfield wrote: > The other issue might be that the graphic objects have are all > compiled already but not download to the GPU. Also if the GPU memory > is full the driver has to start moving graphics objects in/out of GPU > memory on the fly which can cause big frame drops. Do you think this might be the case? Is there a way in OSG to tell if an object is already in the GPU memory? And to push them there? I remind you that once I scan the all scene with my vision the problem disappears and I can look around without any frame drop. So I guess that the GPU memory is enough to handle the whole scene, I just need to force some sort of "pre-loading" of ALL objects. robertosfield wrote: > What specifically you need to do to resolve the problem depends > entirely where the actual bottleneck is, we can't answer this without > knowing more about what is happening your scene graph, how much > headroom you have on the GPU to handle the extra memory usage, > bandwidth and compute work. As I said, my conclusion is that I don't have any actual system bottleneck, I just have to get rid of this lazy loading process :) I just need to tell the GPU "hey, here's my scene, I know you can handle it all, just pre-process it in one shot and don't wait for me to look around!" But I could be completely wrong and I'd love to know what you guys think about it. I want to 1) learn more about OSG and VR 2) solve this annoying problem. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69216#69216 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Loading problem, OpenVR integration
Hi, I'm working on a Virtual Reality project that involves the rendering of a OSG scene in an Oculus Rift CV1 device using the OpenVR library. All these technologies are pretty new to me so everything is as exciting as frustrating :) My code is based on the Chris Denham "osgopenvrviewer" project (you can find it on Github) So, my starting point is a osgViewer::View that contains my immersive scene. I managed to render it in the headset display by doing this: Code: osg::ref_ptr vrViewer = new OpenVRViewer(myView, myDevice, myRealizeOperation); osg::ref_ptr sceneData = myView->getSceneData(); vrViewer->addChild(sceneData); myView->setSceneData(vrViewer); So far so good, the render quality and the stereo effect are perfect. The problems start when I move my head to look around in the scene: it looks like the objects outside my first view frustum are not ready when the application starts, so I get serious frame drops when I see these objects for the first time. These frame drops are particulary annoying in the headset, where a frame drop freezes the view for a fraction of second multiple times, causing a very ugly effect. This happens only the first time I look around: after a first "scan" of the scene, everything works smoothly and nice. The system I'm working on started as a simple desktop application with a single view/camera and I couldn't reproduce these problems in the no-VR version. I can look around very fast using a gamepad without losing any frame. So, I guess the problem is in the OpenVR integration. Is there anyone who already had this kind of issues? Do you have an idea on how to manage pre-loading of the entire scene before the realtime simulation starts? Thank you! Cheers, Lorenzo P.S. I see that many people solved this problem using osgViewer::Renderer->setCompileOnNextDraw(true) but I think it is not enough in my case. I have two RTT slave cameras for VR rendering (left eye and right eye) and I saw that the "setSceneData" method internally calls "setCompileOnNextDraw" on every slave camera in the viewer. -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=69205#69205 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
