Thanks for the responses.
Ruben: That sounds like a robust way to handle threading issues. We do
something similar in VR Juggler based applications where one thread
receives input but many have to render.
Andrew: Did you have to hook up a lot of UI events to get your scene to
refresh during window relocation, etc? We considered not rendering
continuously to get around ToolTip transparency issues, but it seemed
like it might be complicated to get the control to render when it needs to.
-Todd
On 11/10/2009 10:56 AM, Andrew Burnett-Thompson wrote:
Hi there,
I'm doing something very similar - OSG hosted in .NET. The way I've done
this is I have my render thread running in a loop and instead of
rendering continuously, I have a Stack<RenderArgs> hosted in the OSG
.NET control. Then if I want to render, I push a RenderArgs onto the stack.
Inside the render thread, I check if there is an item in the stack, if
so, pop it out and render.
That way I have control over rendering (I only render when I need to in
my app, as its a visualisation and doesn't need to run continuously).
Also in the render thread, if there are no stack objects I will
Thread.Sleep(1) to pause the render thread for 1ms (The minimum allowed
time).
This is just one solution. You could alternatively call frame directly
and just use some object to handle the thread locking (Lock keyword in
C# or Monitor::Enter/Exit in C++/CLI). Calling frame from within
MainForm_Paint is not that bad an idea, I've donet his myself for
DirectX visualisation applications before.
Cheers,
Andrew
On Tue, Nov 10, 2009 at 3:48 PM, Smelik, R.M. (Ruben)
<[email protected] <mailto:[email protected]>> wrote:
Hi Todd,
I've had the same choices to make for my .NET / OSG program. I'm not
sure whether or not the .NET timer / Invalidate is a stable
approach, FYI I'll just explain the solution I've chosen.
To avoid all the mutexes and threading issues, I went for a very
simple solution. A render thread loops to call frame() and a UI
thread processes user actions. Changes to the scene graph are made
in two steps:
* The UI thread sets a flag indicating what kind of change to the
scenegraph is required;
* Each iteration, the render threads checks (and clears) all flags
and makes the required scenegraph changes before calling frame().
Of course, depending on your application, this can be kind of
awkward (although you can replace flags with more detailed
"modification objects" containing loaded models etc.).
Kind regards,
Ruben
________________________________
From: [email protected]
<mailto:[email protected]> on behalf of
Todd J. Furlong
Sent: Tue 11/10/2009 4:11 PM
To: OpenSceneGraph Users
Subject: [osg-users] OsgViewer and Windows Forms
I have a .NET Windows Forms application with 2 OSG-based classes:
1. A UserControl/OsgViewer based class, and
2. An OSG-based "engine" that handles file loading, scenegraph mods,
etc.
The .NET example from the OSG website gets the viewer initialized:
http://www.openscenegraph.org/projects/osg/wiki/Support/FAQ#HowdoIembedanOSGviewerina.NETcontrol
My question is: What is the best way to call the viewer frame function
in this application?
I have tried updating the viewer in a new thread. It appears to perform
well, but it presents thread safety problems because my scenegraph
modifications (from the "engine") mostly take place in the UI thread
(button press events, etc). I can simplify the engine code (avoid
mutexes around function calls) if I can get the viewer to update on that
thread.
To move the viewer onto the UI thread, I am calling the viewer frame
function in an override of the OnPaint method of the UserControl class.
I've created a Forms timer that periodically calls Invalidate on the
UserControl to make sure OnPaint is called with some regularity. Other
timer-related code insures that the Invalidate call isn't made at a
greater frequency than we expect the viewer to be able to render. It
appears to be working OK, but I'm worried that this approach will be
fragile as we run this application on different systems with different
scene contents.
Comments or suggestions?
Thanks,
Todd
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
<https://tnoportal.tno.nl/listinfo.cgi/,DanaInfo=lists.openscenegraph.org+osg-users-openscenegraph.org>
This e-mail and its contents are subject to the DISCLAIMER at
http://www.tno.nl/disclaimer/email.html
_______________________________________________
osg-users mailing list
[email protected]
<mailto:[email protected]>
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
--
Todd J. Furlong
Inv3rsion, LLC
http://www.inv3rsion.com
888-588-0573 x701 office
603-759-9035 mobile
888-588-0573 fax
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
