Re: [osg-users] First steps to improve culling

[Robert Osfield]

Hi Alexandre,

On 12 November 2015 at 20:30, Alexandre Vaillancourt <
alexandre.vaillancourt.l...@gmail.com> wrote:

> Thanks for your reply, and of course I should have specified the version.
> It's 3.2.0, we're planning to update to the most recent one within the next
> 3 months.
>
> I have attached the screenshot. I'm not authorized to post anything not
> approved by the higher end so the visuals have been "painted", but the
> stats are there.
>

>From the screenshots the cull and draw dispatch don't look particular high,
but the draw GPU is clear bottleneck and will be the primary cause of slow
down.

The number of objects that the OSG and hence OpenGL is dealing with isn't
massive so optimizing the scene graph structure probably won't gain you too
much.  Not to say you might not be able to optimize things further but for
now I'd suggest you best spend your efforts looking at how to optimize what
is happening on the GPU.

You could look at threading - CullThreadPerCameraDrawThreadPerContext would
be worth trying just to see how it changes things.  As you are GPU limited
I don't expect this to make a big differents but since calling
"viewer.setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext"
is single line addition to your app it shouldn't take to long to test out.

On the GPU optimization side there are lots of different things that can
cause bottlenecks, each one will have a different set of solutions.  It's
rather open ended topic, so you'll need to do a range of benchmark tests to
find out what is the main bottleneck on the GPU.  One easy test would be to
change the resolution of the different windows - such as half in each
dimension to cut the fill requirements to a 1/4.  If you run the benchmarks
in this configuration and look at how the GPU stats change you'll get an
idea of relative load on vertex vs fragment processing.  For instance if
the performance doesn't change much when you change resolution then you are
likely to be vertex processing limited, while if the performance does vary
significantly then you'll be fill limited.

Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] [build] using 3Ds Model in osgFX::BumpMapping and the Texture UV Coords for diffuse are not loaded

[Tobias Rick]

I found an other problem. When I rotate my object, the light direction also is 
rotated. How can I prevent this?

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65633#65633





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] First steps to improve culling

[Christian Buchner]

If you have lots of similar objects (crates boxes and whatnot), maybe GPU
instancing would be a way to speed up draw calls. We've managed to get
15000 cars on screen at high frame rates using OpenGL instancing, with
several hundred polys per instance.

Christian


2015-11-13 10:09 GMT+01:00 Robert Osfield :

> Hi Alexandre,
>
> On 12 November 2015 at 20:30, Alexandre Vaillancourt <
> alexandre.vaillancourt.l...@gmail.com> wrote:
>
>> Thanks for your reply, and of course I should have specified the version.
>> It's 3.2.0, we're planning to update to the most recent one within the next
>> 3 months.
>>
>> I have attached the screenshot. I'm not authorized to post anything not
>> approved by the higher end so the visuals have been "painted", but the
>> stats are there.
>>
>
> From the screenshots the cull and draw dispatch don't look particular
> high, but the draw GPU is clear bottleneck and will be the primary cause of
> slow down.
>
> The number of objects that the OSG and hence OpenGL is dealing with isn't
> massive so optimizing the scene graph structure probably won't gain you too
> much.  Not to say you might not be able to optimize things further but for
> now I'd suggest you best spend your efforts looking at how to optimize what
> is happening on the GPU.
>
> You could look at threading - CullThreadPerCameraDrawThreadPerContext
> would be worth trying just to see how it changes things.  As you are GPU
> limited I don't expect this to make a big differents but since calling
> "viewer.setThreadingModel(osgViewer::Viewer::CullThreadPerCameraDrawThreadPerContext"
> is single line addition to your app it shouldn't take to long to test out.
>
> On the GPU optimization side there are lots of different things that can
> cause bottlenecks, each one will have a different set of solutions.  It's
> rather open ended topic, so you'll need to do a range of benchmark tests to
> find out what is the main bottleneck on the GPU.  One easy test would be to
> change the resolution of the different windows - such as half in each
> dimension to cut the fill requirements to a 1/4.  If you run the benchmarks
> in this configuration and look at how the GPU stats change you'll get an
> idea of relative load on vertex vs fragment processing.  For instance if
> the performance doesn't change much when you change resolution then you are
> likely to be vertex processing limited, while if the performance does vary
> significantly then you'll be fill limited.
>
> Robert.
>
>
> ___
> 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

[Anders Backman]

It seems to me that OSG eats the 3DConnexion messages, until you move the
window explicitly with the mouse.
The code below show that a console window works just fine, all messages are
intercepted by the "message window".
However, when a osgViewer run loop is being used, the messages seem to be
filtered.

I only get a Spaceball event when I move the window(!).


#include 
#include 

#include 


#pragma comment(lib, "siapp.lib")

#include"windows.h"
#include 

#include "spwmacro.h"  /* Common macros used by SpaceWare functions. */
#include "si.h"/* Required for any SpaceWare support within an
app.*/
#include "siapp.h" /* Required for siapp.lib symbols */

#pragma warning(disable:4700)

SiHdl   devHdl;   /* Handle to 3D Mouse Device */
SiOpenData oData;
WNDPROC wndProcOrig;

void ClearScreen() {
  for (unsigned i = 0; i<100; ++i) std::cout << std::endl;
}

int SbInit(HWND hwndC);
void  SbMotionEvent(SiSpwEvent *pEvent);
void  SbZeroEvent();
void  SbButtonPressEvent(int buttonnumber);
void  SbButtonReleaseEvent(int buttonnumber);
void  HandleDeviceChangeEvent(SiSpwEvent *pEvent);


LRESULT CALLBACK MyWndCBProc(
  HWND hwnd, UINT wm, WPARAM wParam, LPARAM lParam)
{
  SiSpwEvent Event;/* SpaceWare Event */
  SiGetEventData EData;/* SpaceWare Event Data */

  /* initialize Window platform specific data for a call to SiGetEvent */
  SiGetEventWinInit(, wm, wParam, lParam);

  /* check whether wm was a 3D mouse event and process it */
  //if (SiGetEvent (devHdl, SI_AVERAGE_EVENTS, , ) ==
SI_IS_EVENT)
  SpwRetVal retval = SiGetEvent(devHdl, 0, , );

  if (retval == SI_IS_EVENT)
  {
if (Event.type == SI_MOTION_EVENT)
{
  SbMotionEvent();/* process 3D mouse motion event */
}
else if (Event.type == SI_ZERO_EVENT)
{
  SbZeroEvent();/* process 3D mouse zero event */
}
else if (Event.type == SI_BUTTON_PRESS_EVENT)
{
  SbButtonPressEvent(Event.u.hwButtonEvent.buttonNumber);  /* process
button press event */
}
else if (Event.type == SI_BUTTON_RELEASE_EVENT)
{
  SbButtonReleaseEvent(Event.u.hwButtonEvent.buttonNumber); /* process
button release event */
}
else if (Event.type == SI_DEVICE_CHANGE_EVENT)
{
  //SbHandleDeviceChangeEvent(); /* process 3D mouse device
change event */
}
  }

  return DefWindowProc(hwnd, wm, wParam, lParam);
}

void mainx(void) {


  /* Implement message loop */
  int bRet;
  MSG msg;  /* incoming message to be evaluated */
  while (bRet = GetMessage(, NULL, 0, 0))
  {
if (bRet == -1){
  /* handle the error and possibly exit */
  return;
}
else{
  TranslateMessage();
  DispatchMessage();
}
  }
}


int SbInit(HWND hwndC)
{
  int res; /* result of SiOpen, to be returned
 */

  /*init the SpaceWare input library */
  if (SiInitialize() == SPW_DLL_LOAD_ERROR)  {
std::cout << "Error: Could not load SiAppDll dll files" << std::endl;
  }
  else {
//std::cout << "SiInitialize() done " << std::endl;
  }

  SiOpenWinInit(, hwndC);/* init Win. platform specific data  */

  /* open data, which will check for device type and return the device
handle to be used by this function */
  if ((devHdl = SiOpen("AppSpaceMouse.exe", SI_ANY_DEVICE, SI_NO_MASK,
SI_EVENT, )) == NULL) {
std::cout << "SiOpen error:" << std::endl;
SiTerminate();  /* called to shut down the SpaceWare input library */
std::cout << "SiTerminate()" << std::endl;
res = 0;/* could not open device */
return res;
  }

  SiDeviceName pname;
  SiGetDeviceName(devHdl, );
  //std::cout << "devicename =  " << pname.name << std::endl;

  SiSetUiMode(devHdl, SI_UI_ALL_CONTROLS); /* Config SoftButton Win Display
*/
  SiGrabDevice(devHdl, SPW_TRUE); /* PREVENTS OTHER APPLICATIONS FROM
RECEIVING 3D CONNEXION DATA !!! */
  res = 1;/* opened device succesfully */
  return res;
}

void  SbMotionEvent(SiSpwEvent *pEvent) {
  std::cout << "TX=" << pEvent->u.spwData.mData[SI_TX] << " TY=" <<
pEvent->u.spwData.mData[SI_TY] << " TZ=" << pEvent->u.spwData.mData[SI_TZ]
<< " RX=" << pEvent->u.spwData.mData[SI_RX] << " RY=" <<
pEvent->u.spwData.mData[SI_RY] << " RZ=" << pEvent->u.spwData.mData[SI_RZ]
<< std::endl;
}
void  SbZeroEvent() {
  std::cout << "zeroevent: " << std::endl;
}
void  SbButtonPressEvent(int buttonnumber) {
  std::cout << "Buttonnumber : " << buttonnumber << std::endl;
}
void  SbButtonReleaseEvent(int buttonnumber) {
  std::cout << "Buttonnumber : " << buttonnumber << std::endl;
}
void  HandleDeviceChangeEvent(SiSpwEvent *pEvent) {
  std::cout << "HandleDeviceChangeEvent : " << std::endl;

}


int main(int argc, char** argv)
{
  osg::ArgumentParser arguments(, argv);
#if 1
  osgViewer::Viewer viewer(arguments);
#else
  osgViewer::CompositeViewer viewer(arguments);

  osgViewer::View* view = new osgViewer::View;
  view->setName("View one");
  viewer.addView(view);

  view->setSceneData(scene.get());
  

Re: [osg-users] First steps to improve culling

[Jannik Heller]

There is a very high number of PrimitiveSets in your screenshot. In fact you 
seem to have roughly one PrimitiveSet per 4 vertices, that is ridiculous. Each 
PrimitiveSet needs an OpenGL draw call to render it. Try reorganizing your 
models to use as few PrimitiveSet's as possible.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65635#65635





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to grab color from a point on a model?

[Dan Flickinger]

Hi Robert,

I'm getting back to this late for a followup, after I had to burn through a 
bunch of development and testing for a few weeks. Here is the resolution for 
the benefit of future visitors:



The models were in .ive format, but the textures were not stored after file 
load, even when using the TextureVisitor to make sure that 
UnRefImageDataAfterApply was set to false. So now pulling colors from the 
textures works after converting the models to .osg, with the textures stored in 
separate files.

It was kind of a pain to chase this down in gdb, because of the many inline 
functions. Even when playing with compiler flags and building straight from 
source.  :| 


Thank you for all the help!

Best,

Dan

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65636#65636





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Fast cycling of textured rectangles

[Christoph Heindl]

Hi everyone,

I'm working on a project where I need to display different patterns
(textured rectangles) as quickly as possible. Currently, i have an
osgViewer with a single view running that holds a single textured rectangle
and upon user request, the texture / image is updated. This works quite ok,
but requires a CPU->GPU transfer every time I intend to update the image.

I think there must be a way to improve performance when I know the set of
patterns images beforehand. So, I would like to prepare pre-rendered
textured-quads on the GPU and upon user request just cycle between those
pre-rendered elements. That should reduce the CPU->GPU overhead to
initialization time.

I somehow have the feeling that the solution requires a frame-buffer /
render-buffer object per pattern and somehow involves glBlitFramebuffer to
display the correct frame buffer, but I'm stuck in how to implement this in
OSG.

Any kick start would be greatly appreciated!

Best,
Christoph
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Fast cycling of textured rectangles

[Sebastian Messerschmidt]

Hello Christoph,

You can use either a texture which contains all the textures and modify 
the texture coordinates (so to say a matrix of different textures).
Also texture arrays might help here a lot, if all the textures are of 
the same dimensions.
Anyways, what you might you see are initial costs. Once the texture is 
transfered to the GPU and your memory is not filled, subsequent use 
should be a matter of switching texture units binding.


Cheers
Sebastian


Hi everyone,

I'm working on a project where I need to display different patterns 
(textured rectangles) as quickly as possible. Currently, i have an 
osgViewer with a single view running that holds a single textured 
rectangle and upon user request, the texture / image is updated. This 
works quite ok, but requires a CPU->GPU transfer every time I intend 
to update the image.


I think there must be a way to improve performance when I know the set 
of patterns images beforehand. So, I would like to prepare 
pre-rendered textured-quads on the GPU and upon user request just 
cycle between those pre-rendered elements. That should reduce the 
CPU->GPU overhead to initialization time.


I somehow have the feeling that the solution requires a frame-buffer / 
render-buffer object per pattern and somehow 
involves glBlitFramebuffer to display the correct frame buffer, but 
I'm stuck in how to implement this in OSG.


Any kick start would be greatly appreciated!

Best,
Christoph


___
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] MSVS2015 3rdparty build

[Andreas Schreiber]

Hi Trajce,

I would be happy about these builds ;)

Trying right now to build osg and the 3rdPartys so I can work again with it.
I would need the collada plugin as well. Do I need to build these as well for 
VS 2015?
... 

Thank you!

Cheers,
Andreas

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=65640#65640





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] MSVS2015 3rdparty build

[Trajce Nikolov NICK]

I have some subset of the 3rd party dependencies. Don't,  mix these with
plugins :-) ... I am not sure to which dependencies the collads plugin is
based, but I can send you what I have, I know others like Chris and
Sebastian also have something build with VS2015 and there was a discussion
here on the users list about the hosting. I will put what I already have
somewhere will ping you privately

On Sat, Nov 14, 2015 at 3:09 AM, Andreas Schreiber  wrote:

> Hi Trajce,
>
> I would be happy about these builds ;)
>
> Trying right now to build osg and the 3rdPartys so I can work again with
> it.
> I would need the collada plugin as well. Do I need to build these as well
> for VS 2015?
> ...
>
> Thank you!
>
> Cheers,
> Andreas
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=65640#65640
>
>
>
>
>
> ___
> 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] Intercepting Windows messages

[Anders Backman]

Ah thats great. A good step forward.
However, two minor questions:

1. Do you need the instance to the main osg window?
2. If not, how do you manage to get events from the device when you apply
force on it?

I get it to read data (in my message callback) but only if a move/modify
the osg window (Im using osgViewer::Viewer with just one window).

/A

On Thu, Nov 12, 2015 at 10:53 PM, Farshid Lashkari  wrote:

> 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