Yes, just thinks like Maximise, Minimise, Resize. I also rendered on
"Activate" in case the form lost and regained focus.

There's no problems integrating OSG with .NET Windows Forms from what I can
see.

On Tue, Nov 10, 2009 at 4:11 PM, Todd J. Furlong <t...@inv3rsion.com> wrote:

> 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)
>> <ruben.sme...@tno.nl <mailto:ruben.sme...@tno.nl>> 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: osg-users-boun...@lists.openscenegraph.org
>>    <mailto:osg-users-boun...@lists.openscenegraph.org> 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
>>    osg-users@lists.openscenegraph.org
>>    <mailto:osg-users@lists.openscenegraph.org>
>>
>>
>> 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
>>    osg-users@lists.openscenegraph.org
>>    <mailto: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
>>
>
> --
> 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
> 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

Reply via email to