Re: [osg-users] github not synchronized
On 12 November 2015 at 02:53, Jason Beverage wrote: > So is Github going to be the new official home of osg? > That's my plan. Will be updating the website soon, but have client work to get done right now so will tackle this once I've got a bit more free time. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] github not synchronized
Hi Robert, Will this affect the submission protocol? I.e. will pull-requests at GitHub replace the osg-submission mailing list? /Björn Från: osg-users för Robert Osfield Skickat: den 12 november 2015 10:36 Till: OpenSceneGraph Users Ämne: Re: [osg-users] github not synchronized On 12 November 2015 at 02:53, Jason Beverage mailto:jasonbever...@gmail.com>> wrote: So is Github going to be the new official home of osg? That's my plan. Will be updating the website soon, but have client work to get done right now so will tackle this once I've got a bit more free time. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xrandr version
Hi Robert, I think is would not easy to find an official documentation of xrandr but I foun the option available in v1.1 here: http://www.x.org/archive/X11R7.5/doc/man/man1/xrandr.1.html#sect5 Moreover I cloned the git repository and verified all XRandR API used in "GraphicsWindowX11.cpp" (which AFAIK is the only file that uses XRandR) are available with the same signature. Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65615#65615 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intercepting Windows messages
That is quite explicit. I was thinking about some method for intercepting
events.
I tried fiddling with creating a custom GraphicsWindowWin32 class, but it
turns out that this is explicitly created internally in:
osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
osg::GraphicsContext::Traits* traits )
{
...
osg::ref_ptr window = new
GraphicsWindowWin32(traits);
}
So this does not seem to be the way to catch windows messages.
My idea was that I could register my instance of the GraphicsWindowWin32 to
implement the virtual method:
LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT
uMsg, WPARAM wParam, LPARAM lParam )
Where I could catch all windows events.
Turns out that I do not have enough understanding when and where context
etc is created.
It seems that a GraphicsWindowWIn32 is first created at the call to:
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
And then at the call to:
viewer->realize();
will also result in a call
to GraphicsContext::createGraphicsContext(Traits* traits), which in turn
will create yet another GraphicsWindowWin32.
So there lies my problem, my call to viewer->realize() will override my
first call to GraphicsContext::createGraphicsContext(traits.get());
Not sure how to get around this though. Ideas?
/Anders
On Wed, Nov 11, 2015 at 5:05 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:
> Hi Anders,
>
> here is what I do for this on Windows
>
> while (!viewer->done())
> {
>
> #if defined(_WIN32)
> MSG msg;
> if (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
> {
> ::GetMessage(&msg, NULL, 0, 0);
>
> if (wins.size())
> {
> osgViewer::GraphicsHandleWin32 *hdl =
> dynamic_cast(wins.at(0));
> if(hdl)
> {
> WNDPROC fWndProc =
> (WNDPROC)::GetWindowLongPtr(hdl->getHWND(), GWLP_WNDPROC);
> if (fWndProc && hdl->getHWND())
> {
> ::CallWindowProc(fWndProc,hdl->getHWND(),msg.message, msg.wParam,
> msg.lParam);
> }
> }
> }
> }
> #endif
>
> On Wed, Nov 11, 2015 at 4:21 PM, Anders Backman wrote:
>
>> Hi.
>>
>> Trying the 3DConnexion SpaceNavigator with OSG. However I would like to
>> stay away from VRPN and such dependencies...
>>
>> I was wondering how to best intercept Windows messages from the
>> GraphicsWindowWin32 class.
>>
>> This class has a virtual method handleNativeWindowingEvent which I would
>> like to override to catch custom messages from my device.
>>
>> Would it be possible to implement a derived class and have that
>> instantiated instead of the standard osgViewer::GraphicsWindowWin32 one?
>>
>> Or is there a different method to listen to the messages:
>>
>> ( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
>>
>> Thanks,
>> Anders
>>
>>
>>
>> --
>> __
>> Anders Backman, HPC2N
>> 90187 Umeå University, Sweden
>> and...@cs.umu.se http://www.hpc2n.umu.se
>> Cell: +46-70-392 64 67
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
> --
> trajce nikolov nick
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
--
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] github not synchronized
On 12 November 2015 at 11:38, Björn Blissing wrote: > Will this affect the submission protocol? I.e. will pull-requests at > GitHub replace the osg-submission mailing list? > Possibly. Haven't made any decisions yet. The key part of reviewing submissions is the graphical diff to spot the how/why of the changes. I haven't played with merging stuff via github yet. Right now I'm busy so don't want to get too sucked into big discussions about topics I need to do more research on before commenting too much. Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] xrandr version
On 12 November 2015 at 11:46, Gianni Ambrosio wrote: > Hi Robert, > I think is would not easy to find an official documentation of xrandr but > I foun the option available in v1.1 here: > http://www.x.org/archive/X11R7.5/doc/man/man1/xrandr.1.html#sect5 > > Moreover I cloned the git repository and verified all XRandR API used in > "GraphicsWindowX11.cpp" (which AFAIK is the only file that uses XRandR) are > available with the same signature. You'll need to explain a bit more specifically what you mean hear. Which git repository xrandr? The OSG? What signatures are you referring to? Robert. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intercepting Windows messages
I notice that there is a major difference between osgViewer::Viewer and
osgViewer::CompositeViewer:
The following code:
osgViewer::CompositeViewer viewer;
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = 100;
traits->y = 100;
traits->width = 1000;
traits->height = 800;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osgViewer::View* view = new osgViewer::View;
view->setName("View one");
viewer.addView(view);
view->setSceneData(scene.get());
view->getCamera()->setViewport(new osg::Viewport(0, 0, traits->width /
2, traits->height / 2));
view->getCamera()->setGraphicsContext(gc.get());
viewer.realize(); // Context already created. No call to
GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
If I replace osgViewerCompositeViewer with a osgViewer::Viewer and remove
the creation of View, I get:
viewer.realize(); // A new context is created. A new call to
GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
So it seems that osgViewer::Viewer does not respect? the previously created
GraphicsCOntext?
/Anders
On Thu, Nov 12, 2015 at 2:24 PM, Anders Backman wrote:
> That is quite explicit. I was thinking about some method for intercepting
> events.
> I tried fiddling with creating a custom GraphicsWindowWin32 class, but it
> turns out that this is explicitly created internally in:
>
> osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
> osg::GraphicsContext::Traits* traits )
> {
> ...
> osg::ref_ptr window = new
> GraphicsWindowWin32(traits);
>
> }
>
> So this does not seem to be the way to catch windows messages.
> My idea was that I could register my instance of the GraphicsWindowWin32
> to implement the virtual method:
>
> LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT
> uMsg, WPARAM wParam, LPARAM lParam )
>
>
> Where I could catch all windows events.
>
>
> Turns out that I do not have enough understanding when and where context
> etc is created.
>
> It seems that a GraphicsWindowWIn32 is first created at the call to:
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
>
> And then at the call to:
>
> viewer->realize();
>
> will also result in a call
> to GraphicsContext::createGraphicsContext(Traits* traits), which in turn
> will create yet another GraphicsWindowWin32.
>
> So there lies my problem, my call to viewer->realize() will override my
> first call to GraphicsContext::createGraphicsContext(traits.get());
>
>
> Not sure how to get around this though. Ideas?
>
> /Anders
>
>
> On Wed, Nov 11, 2015 at 5:05 PM, Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Hi Anders,
>>
>> here is what I do for this on Windows
>>
>> while (!viewer->done())
>> {
>>
>> #if defined(_WIN32)
>> MSG msg;
>> if (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
>> {
>> ::GetMessage(&msg, NULL, 0, 0);
>>
>> if (wins.size())
>> {
>> osgViewer::GraphicsHandleWin32 *hdl =
>> dynamic_cast(wins.at(0));
>> if(hdl)
>> {
>> WNDPROC fWndProc =
>> (WNDPROC)::GetWindowLongPtr(hdl->getHWND(), GWLP_WNDPROC);
>> if (fWndProc && hdl->getHWND())
>> {
>> ::CallWindowProc(fWndProc,hdl->getHWND(),msg.message, msg.wParam,
>> msg.lParam);
>> }
>> }
>> }
>> }
>> #endif
>>
>> On Wed, Nov 11, 2015 at 4:21 PM, Anders Backman
>> wrote:
>>
>>> Hi.
>>>
>>> Trying the 3DConnexion SpaceNavigator with OSG. However I would like to
>>> stay away from VRPN and such dependencies...
>>>
>>> I was wondering how to best intercept Windows messages from the
>>> GraphicsWindowWin32 class.
>>>
>>> This class has a virtual method handleNativeWindowingEvent which I would
>>> like to override to catch custom messages from my device.
>>>
>>> Would it be possible to implement a derived class and have that
>>> instantiated instead of the standard osgViewer::GraphicsWindowWin32 one?
>>>
>>> Or is there a different method to listen to the messages:
>>>
>>> ( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
>>>
>>> Thanks,
>>> Anders
>>>
>>>
>>>
>>> --
>>> __
>>> Anders Backman, HPC2N
>>> 90187 Umeå University, Sweden
>>> and...@cs.umu.se http://www.hpc2n.umu.se
>>> Cell: +46-70-392 64 67
>>>
>>> ___
>>> osg-users mailing list
>>> osg-users@lists.openscenegraph.org
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>>>
>>
>>
>> --
>> trajce nikolov nick
>>
>> ___
>> osg-users mailing list
>> osg-users@lists.openscenegraph.org
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>>
>
>
Re: [osg-users] xrandr version
robertosfield wrote: > > Which git repository xrandr? > http://cgit.freedesktop.org/xorg/lib/libXrandr addressed from here: http://www.x.org/wiki robertosfield wrote: > > The OSG? > I'm on OSG 3.0.1 but the code related to xrandr, in "GraphicsWindowX11.cpp" file, on the OSG trunk is exactly the same. robertosfield wrote: > > What signatures are you referring to? > The signature of every xrendr API used in "GraphicsWindowX11.cpp" file did not change from xrandr 1.1.1 to 1.2 (but I also check the trunk version). There is just one difference: Xrandr.h (v1.2) XRRScreenConfiguration *XRRGetScreenInfo (Display *dpy, Window window); Xrandr.h (v1.1.1) XRRScreenConfiguration *XRRGetScreenInfo (Display *dpy, Drawable draw); BTW in Xrandr.c (v1.1.1) the signature is: XRRScreenConfiguration *XRRGetScreenInfo (Display *dpy, Window window) Maybe Window and Drawable are both integers or so. Hope this is clearer now. Gianni -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65620#65620 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intercepting Windows messages
Did you tried something like:
osgViewer::Viewer viewer;
viewer.getCamera()->setGraphicContext(gc);
?
On Thu, Nov 12, 2015 at 2:52 PM, Anders Backman wrote:
> I notice that there is a major difference between osgViewer::Viewer and
> osgViewer::CompositeViewer:
>
> The following code:
>
> osgViewer::CompositeViewer viewer;
>
> osg::ref_ptr traits = new
> osg::GraphicsContext::Traits;
> traits->x = 100;
> traits->y = 100;
> traits->width = 1000;
> traits->height = 800;
> traits->windowDecoration = true;
> traits->doubleBuffer = true;
> traits->sharedContext = 0;
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
>osgViewer::View* view = new osgViewer::View;
> view->setName("View one");
> viewer.addView(view);
>
> view->setSceneData(scene.get());
> view->getCamera()->setViewport(new osg::Viewport(0, 0, traits->width /
> 2, traits->height / 2));
> view->getCamera()->setGraphicsContext(gc.get());
>
> viewer.realize(); // Context already created. No call to
> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>
>
>
> If I replace osgViewerCompositeViewer with a osgViewer::Viewer and remove
> the creation of View, I get:
>
> viewer.realize(); // A new context is created. A new call to
> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>
>
> So it seems that osgViewer::Viewer does not respect? the previously
> created GraphicsCOntext?
>
> /Anders
>
>
>
> On Thu, Nov 12, 2015 at 2:24 PM, Anders Backman wrote:
>
>> That is quite explicit. I was thinking about some method for intercepting
>> events.
>> I tried fiddling with creating a custom GraphicsWindowWin32 class, but it
>> turns out that this is explicitly created internally in:
>>
>> osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
>> osg::GraphicsContext::Traits* traits )
>> {
>> ...
>> osg::ref_ptr window = new
>> GraphicsWindowWin32(traits);
>>
>> }
>>
>> So this does not seem to be the way to catch windows messages.
>> My idea was that I could register my instance of the GraphicsWindowWin32
>> to implement the virtual method:
>>
>> LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT
>> uMsg, WPARAM wParam, LPARAM lParam )
>>
>>
>> Where I could catch all windows events.
>>
>>
>> Turns out that I do not have enough understanding when and where context
>> etc is created.
>>
>> It seems that a GraphicsWindowWIn32 is first created at the call to:
>>
>> osg::ref_ptr gc =
>> osg::GraphicsContext::createGraphicsContext(traits.get());
>>
>>
>> And then at the call to:
>>
>> viewer->realize();
>>
>> will also result in a call
>> to GraphicsContext::createGraphicsContext(Traits* traits), which in turn
>> will create yet another GraphicsWindowWin32.
>>
>> So there lies my problem, my call to viewer->realize() will override my
>> first call to GraphicsContext::createGraphicsContext(traits.get());
>>
>>
>> Not sure how to get around this though. Ideas?
>>
>> /Anders
>>
>>
>> On Wed, Nov 11, 2015 at 5:05 PM, Trajce Nikolov NICK <
>> trajce.nikolov.n...@gmail.com> wrote:
>>
>>> Hi Anders,
>>>
>>> here is what I do for this on Windows
>>>
>>> while (!viewer->done())
>>> {
>>>
>>> #if defined(_WIN32)
>>> MSG msg;
>>> if (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
>>> {
>>> ::GetMessage(&msg, NULL, 0, 0);
>>>
>>> if (wins.size())
>>> {
>>> osgViewer::GraphicsHandleWin32 *hdl =
>>> dynamic_cast(wins.at(0));
>>> if(hdl)
>>> {
>>> WNDPROC fWndProc =
>>> (WNDPROC)::GetWindowLongPtr(hdl->getHWND(), GWLP_WNDPROC);
>>> if (fWndProc && hdl->getHWND())
>>> {
>>> ::CallWindowProc(fWndProc,hdl->getHWND(),msg.message, msg.wParam,
>>> msg.lParam);
>>> }
>>> }
>>> }
>>> }
>>> #endif
>>>
>>> On Wed, Nov 11, 2015 at 4:21 PM, Anders Backman
>>> wrote:
>>>
Hi.
Trying the 3DConnexion SpaceNavigator with OSG. However I would like to
stay away from VRPN and such dependencies...
I was wondering how to best intercept Windows messages from the
GraphicsWindowWin32 class.
This class has a virtual method handleNativeWindowingEvent which I
would like to override to catch custom messages from my device.
Would it be possible to implement a derived class and have that
instantiated instead of the standard osgViewer::GraphicsWindowWin32 one?
Or is there a different method to listen to the messages:
( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam )
Thanks,
Anders
--
__
Anders Backman, HPC2N
90187 Umeå University, Sweden
and...@cs.umu.se http://www.hpc2n.umu.se
Cell: +46-70-392 64 67
___
osg-users mailing list
>
Re: [osg-users] Intercepting Windows messages
That is certainly an important call yes.
I guess my problem is that these two calls are not interchangeable:
#if 1
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
#else
osg::ref_ptr window = new
osgViewer::GraphicsWindowWin32(traits);
gc = window.get();
#endif
createGraphicsContext() will do a few more things which the creation of a
osgViewer::GraphicsWindowWin32 does not. The question is really, is it
possible to even consider this?
Is there a mechanism for creating a custom GraphicsWindowWin32 or is this
path doomed to fail.
/Anders
On Thu, Nov 12, 2015 at 3:31 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:
> Did you tried something like:
>
> osgViewer::Viewer viewer;
> viewer.getCamera()->setGraphicContext(gc);
>
> ?
>
> On Thu, Nov 12, 2015 at 2:52 PM, Anders Backman wrote:
>
>> I notice that there is a major difference between osgViewer::Viewer and
>> osgViewer::CompositeViewer:
>>
>> The following code:
>>
>> osgViewer::CompositeViewer viewer;
>>
>> osg::ref_ptr traits = new
>> osg::GraphicsContext::Traits;
>> traits->x = 100;
>> traits->y = 100;
>> traits->width = 1000;
>> traits->height = 800;
>> traits->windowDecoration = true;
>> traits->doubleBuffer = true;
>> traits->sharedContext = 0;
>>
>> osg::ref_ptr gc =
>> osg::GraphicsContext::createGraphicsContext(traits.get());
>>
>>osgViewer::View* view = new osgViewer::View;
>> view->setName("View one");
>> viewer.addView(view);
>>
>> view->setSceneData(scene.get());
>> view->getCamera()->setViewport(new osg::Viewport(0, 0, traits->width
>> / 2, traits->height / 2));
>> view->getCamera()->setGraphicsContext(gc.get());
>>
>> viewer.realize(); // Context already created. No call to
>> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>>
>>
>>
>> If I replace osgViewerCompositeViewer with a osgViewer::Viewer and remove
>> the creation of View, I get:
>>
>> viewer.realize(); // A new context is created. A new call to
>> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>>
>>
>> So it seems that osgViewer::Viewer does not respect? the previously
>> created GraphicsCOntext?
>>
>> /Anders
>>
>>
>>
>> On Thu, Nov 12, 2015 at 2:24 PM, Anders Backman
>> wrote:
>>
>>> That is quite explicit. I was thinking about some method for
>>> intercepting events.
>>> I tried fiddling with creating a custom GraphicsWindowWin32 class, but
>>> it turns out that this is explicitly created internally in:
>>>
>>> osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
>>> osg::GraphicsContext::Traits* traits )
>>> {
>>> ...
>>> osg::ref_ptr window = new
>>> GraphicsWindowWin32(traits);
>>>
>>> }
>>>
>>> So this does not seem to be the way to catch windows messages.
>>> My idea was that I could register my instance of the GraphicsWindowWin32
>>> to implement the virtual method:
>>>
>>> LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd, UINT
>>> uMsg, WPARAM wParam, LPARAM lParam )
>>>
>>>
>>> Where I could catch all windows events.
>>>
>>>
>>> Turns out that I do not have enough understanding when and where context
>>> etc is created.
>>>
>>> It seems that a GraphicsWindowWIn32 is first created at the call to:
>>>
>>> osg::ref_ptr gc =
>>> osg::GraphicsContext::createGraphicsContext(traits.get());
>>>
>>>
>>> And then at the call to:
>>>
>>> viewer->realize();
>>>
>>> will also result in a call
>>> to GraphicsContext::createGraphicsContext(Traits* traits), which in turn
>>> will create yet another GraphicsWindowWin32.
>>>
>>> So there lies my problem, my call to viewer->realize() will override my
>>> first call to GraphicsContext::createGraphicsContext(traits.get());
>>>
>>>
>>> Not sure how to get around this though. Ideas?
>>>
>>> /Anders
>>>
>>>
>>> On Wed, Nov 11, 2015 at 5:05 PM, Trajce Nikolov NICK <
>>> trajce.nikolov.n...@gmail.com> wrote:
>>>
Hi Anders,
here is what I do for this on Windows
while (!viewer->done())
{
#if defined(_WIN32)
MSG msg;
if (::PeekMessage(&msg,NULL,0,0,PM_NOREMOVE))
{
::GetMessage(&msg, NULL, 0, 0);
if (wins.size())
{
osgViewer::GraphicsHandleWin32 *hdl =
dynamic_cast(wins.at(0));
if(hdl)
{
WNDPROC fWndProc =
(WNDPROC)::GetWindowLongPtr(hdl->getHWND(), GWLP_WNDPROC);
if (fWndProc && hdl->getHWND())
{
::CallWindowProc(fWndProc,hdl->getHWND(),msg.message, msg.wParam,
msg.lParam);
}
}
}
}
#endif
On Wed, Nov 11, 2015 at 4:21 PM, Anders Backman
wrote:
> Hi.
>
> Trying the 3DConnexion SpaceNavigator with OSG. However I would like
> to stay away from VRPN and such dependencies...
>
> I was wo
Re: [osg-users] Intercepting Windows messages
So there seem to be only a very few alternatives for integrating such a
windows oriented toolkit as the 3DConnexion SpaceMouse...
My idea of being able to create a custom implementation of a
GraphicsWindowWin32 would really open up for a better integration, albeit
not a portable one...
Right now, using VRPN feels a bit strange in a native application (as it
requires a server).
As far as I know there is no polling API for the 3DConnexion devices, no?
I see older emails about accessing it through Direct3D, and native
USB...whereas listening to windows messages would be the "correct" way of
integrating it.
I would have to hack into the context classes to do this...
Hm
/Anders
On Thu, Nov 12, 2015 at 3:54 PM, Anders Backman wrote:
> That is certainly an important call yes.
>
> I guess my problem is that these two calls are not interchangeable:
>
> #if 1
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
> #else
> osg::ref_ptr window = new
> osgViewer::GraphicsWindowWin32(traits);
> gc = window.get();
> #endif
>
> createGraphicsContext() will do a few more things which the creation of a
> osgViewer::GraphicsWindowWin32 does not. The question is really, is it
> possible to even consider this?
> Is there a mechanism for creating a custom GraphicsWindowWin32 or is this
> path doomed to fail.
>
> /Anders
>
>
>
> On Thu, Nov 12, 2015 at 3:31 PM, Trajce Nikolov NICK <
> trajce.nikolov.n...@gmail.com> wrote:
>
>> Did you tried something like:
>>
>> osgViewer::Viewer viewer;
>> viewer.getCamera()->setGraphicContext(gc);
>>
>> ?
>>
>> On Thu, Nov 12, 2015 at 2:52 PM, Anders Backman
>> wrote:
>>
>>> I notice that there is a major difference between osgViewer::Viewer and
>>> osgViewer::CompositeViewer:
>>>
>>> The following code:
>>>
>>> osgViewer::CompositeViewer viewer;
>>>
>>> osg::ref_ptr traits = new
>>> osg::GraphicsContext::Traits;
>>> traits->x = 100;
>>> traits->y = 100;
>>> traits->width = 1000;
>>> traits->height = 800;
>>> traits->windowDecoration = true;
>>> traits->doubleBuffer = true;
>>> traits->sharedContext = 0;
>>>
>>> osg::ref_ptr gc =
>>> osg::GraphicsContext::createGraphicsContext(traits.get());
>>>
>>>osgViewer::View* view = new osgViewer::View;
>>> view->setName("View one");
>>> viewer.addView(view);
>>>
>>> view->setSceneData(scene.get());
>>> view->getCamera()->setViewport(new osg::Viewport(0, 0, traits->width
>>> / 2, traits->height / 2));
>>> view->getCamera()->setGraphicsContext(gc.get());
>>>
>>> viewer.realize(); // Context already created. No call to
>>> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>>>
>>>
>>>
>>> If I replace osgViewerCompositeViewer with a osgViewer::Viewer and
>>> remove the creation of View, I get:
>>>
>>> viewer.realize(); // A new context is created. A new call to
>>> GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
>>>
>>>
>>> So it seems that osgViewer::Viewer does not respect? the previously
>>> created GraphicsCOntext?
>>>
>>> /Anders
>>>
>>>
>>>
>>> On Thu, Nov 12, 2015 at 2:24 PM, Anders Backman
>>> wrote:
>>>
That is quite explicit. I was thinking about some method for
intercepting events.
I tried fiddling with creating a custom GraphicsWindowWin32 class, but
it turns out that this is explicitly created internally in:
osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
osg::GraphicsContext::Traits* traits )
{
...
osg::ref_ptr window = new
GraphicsWindowWin32(traits);
}
So this does not seem to be the way to catch windows messages.
My idea was that I could register my instance of the
GraphicsWindowWin32 to implement the virtual method:
LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd,
UINT uMsg, WPARAM wParam, LPARAM lParam )
Where I could catch all windows events.
Turns out that I do not have enough understanding when and where
context etc is created.
It seems that a GraphicsWindowWIn32 is first created at the call to:
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
And then at the call to:
viewer->realize();
will also result in a call
to GraphicsContext::createGraphicsContext(Traits* traits), which in turn
will create yet another GraphicsWindowWin32.
So there lies my problem, my call to viewer->realize() will override my
first call to GraphicsContext::createGraphicsContext(traits.get());
Not sure how to get around this though. Ideas?
/Anders
On Wed, Nov 11, 2015 at 5:05 PM, Trajce Nikolov NICK <
trajce.nikolov.n...@gmail.com> wrote:
> Hi Anders,
>
> here is what I do for this on Windows
>
> while (!viewer->done())
> {
>
> #if defined(_WIN32)
>>>
Re: [osg-users] First steps to improve culling
Hi Alexandre, Could you post a screenshot with the stats displayed or simply post the frame update, cull, draw dispatch and draw GPU stats? Also which version of the OSG are you using? Robert. On 12 November 2015 at 19:21, Alexandre Vaillancourt < alexandre.vaillancourt.l...@gmail.com> wrote: > Hello forum/list! > > We've been using openscenegraph for quite a while now, and now it's time > to start using it in a smarter way. > > We've recently started to test displaying our app with 4 monitors: 3 in a > single Windows window (spanned over the 3 monitors of the same graphics > card with NVidia surround), and a 4 monitor with another Windows window on > a second graphics card. > > Our test app can now run with 1, 2, 3 and 4 monitors, and thus the same > amount of camera displaying the scene. > > Now as it's expected, as more cameras are added, the framerate starts to > go down. > > With the Visual Studio (2013) profiler, I've narrowed down the core of the > time spent in OSG's 'frame' call is during the cull stage. > > A couple of fact: > - The app is a Forklift Simulator > - The essential of the time is spent in the virtual warehouse > - The warehouse is full of loads > - Racks and Loads have no LODs (this could be improved) > - Racks and Loads (specifically) are not optimized geometry-wise, their > poly count could be reduced (this could be improved) > - In the scene graph, all the loads are siblings under a parent > 'LoadsShadowedNode' group node > > The big question is: > How can I reduce the time spent culling? Are the obvious "create LODs" and > "optimize your loads graphics" that effective? Could I rethink how the > loads are organized in the scene graph? If so, in what way? Any clue as > what would bring the most bang for my buck? > > Any clue will be welcome :) > > I'm not that familiar with the inner workings of OpenGL and I realize I > should push my knowledge a bit more. > > I have attached a couple of screenshot to give an idea of what the > software looks like. > > Thanks for any help! > > -- > Alexandre Vaillancourt > > ___ > osg-users mailing list > osg-users@lists.openscenegraph.org > http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org > > ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Intercepting Windows messages
Hi Anders,
You can create a separate "message-only" window to receive windows messages
from the SpaceMouse. See the following MSDN page:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms632599(v=vs.85).aspx#message_only
I've integrated the 3DConnexion SpaceNavigator into our application using
this method, along with other 3rd party APIs that require a window handle.
Cheers,
Farshid
On Thu, Nov 12, 2015 at 11:01 AM, Anders Backman wrote:
> So there seem to be only a very few alternatives for integrating such a
> windows oriented toolkit as the 3DConnexion SpaceMouse...
>
> My idea of being able to create a custom implementation of a
> GraphicsWindowWin32 would really open up for a better integration, albeit
> not a portable one...
>
> Right now, using VRPN feels a bit strange in a native application (as it
> requires a server).
>
> As far as I know there is no polling API for the 3DConnexion devices, no?
>
> I see older emails about accessing it through Direct3D, and native
> USB...whereas listening to windows messages would be the "correct" way of
> integrating it.
> I would have to hack into the context classes to do this...
>
> Hm
>
> /Anders
>
>
> On Thu, Nov 12, 2015 at 3:54 PM, Anders Backman wrote:
>
>> That is certainly an important call yes.
>>
>> I guess my problem is that these two calls are not interchangeable:
>>
>> #if 1
>> osg::ref_ptr gc =
>> osg::GraphicsContext::createGraphicsContext(traits.get());
>> #else
>> osg::ref_ptr window = new
>> osgViewer::GraphicsWindowWin32(traits);
>> gc = window.get();
>> #endif
>>
>> createGraphicsContext() will do a few more things which the creation of a
>> osgViewer::GraphicsWindowWin32 does not. The question is really, is it
>> possible to even consider this?
>> Is there a mechanism for creating a custom GraphicsWindowWin32 or is this
>> path doomed to fail.
>>
>> /Anders
>>
>>
>>
>> On Thu, Nov 12, 2015 at 3:31 PM, Trajce Nikolov NICK <
>> trajce.nikolov.n...@gmail.com> wrote:
>>
>>> Did you tried something like:
>>>
>>> osgViewer::Viewer viewer;
>>> viewer.getCamera()->setGraphicContext(gc);
>>>
>>> ?
>>>
>>> On Thu, Nov 12, 2015 at 2:52 PM, Anders Backman
>>> wrote:
>>>
I notice that there is a major difference between osgViewer::Viewer and
osgViewer::CompositeViewer:
The following code:
osgViewer::CompositeViewer viewer;
osg::ref_ptr traits = new
osg::GraphicsContext::Traits;
traits->x = 100;
traits->y = 100;
traits->width = 1000;
traits->height = 800;
traits->windowDecoration = true;
traits->doubleBuffer = true;
traits->sharedContext = 0;
osg::ref_ptr gc =
osg::GraphicsContext::createGraphicsContext(traits.get());
osgViewer::View* view = new osgViewer::View;
view->setName("View one");
viewer.addView(view);
view->setSceneData(scene.get());
view->getCamera()->setViewport(new osg::Viewport(0, 0,
traits->width / 2, traits->height / 2));
view->getCamera()->setGraphicsContext(gc.get());
viewer.realize(); // Context already created. No call to
GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
If I replace osgViewerCompositeViewer with a osgViewer::Viewer and
remove the creation of View, I get:
viewer.realize(); // A new context is created. A new call to
GraphicsWIndowWIn32::GraphicsWIndowWin32 will be called
So it seems that osgViewer::Viewer does not respect? the previously
created GraphicsCOntext?
/Anders
On Thu, Nov 12, 2015 at 2:24 PM, Anders Backman
wrote:
> That is quite explicit. I was thinking about some method for
> intercepting events.
> I tried fiddling with creating a custom GraphicsWindowWin32 class, but
> it turns out that this is explicitly created internally in:
>
> osg::GraphicsContext* Win32WindowingSystem::createGraphicsContext(
> osg::GraphicsContext::Traits* traits )
> {
> ...
> osg::ref_ptr window = new
> GraphicsWindowWin32(traits);
>
> }
>
> So this does not seem to be the way to catch windows messages.
> My idea was that I could register my instance of the
> GraphicsWindowWin32 to implement the virtual method:
>
> LRESULT GraphicsWindowWin32::handleNativeWindowingEvent( HWND hwnd,
> UINT uMsg, WPARAM wParam, LPARAM lParam )
>
>
> Where I could catch all windows events.
>
>
> Turns out that I do not have enough understanding when and where
> context etc is created.
>
> It seems that a GraphicsWindowWIn32 is first created at the call to:
>
> osg::ref_ptr gc =
> osg::GraphicsContext::createGraphicsContext(traits.get());
>
>
> And then at the call to:
>
> viewer->realize();
>
> will also result in a call
> to Gra
Re: [osg-users] [build] using 3Ds Model in osgFX::BumpMapping and the Texture UV Coords for diffuse are not loaded
In addition of course the new NVidia driver for Fallout 4 the bump on the model is shown in different colors. To fix this problem look up in the newbump.frag and comment out the "if (lamberFactor > 0.0)" instruction but don't comment out the content of this instruction -- Read this topic online here: http://forum.openscenegraph.org/viewtopic.php?p=65628#65628 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
