Re: [osg-users] MultiThreads in OSG
Hi Renan 2008/5/6 Renan Mendes [EMAIL PROTECTED]: Hi, everyone. I've tried creating another thread in my application using the windows API (CreateThread, etc), but it seems that this thread has become a main thread, here it's probably misuse of multithreading. i.e, my program is not working as a multithreaded application. In my case, this means that I'm not even displaying the OSG default screen - all I have is the prompt display, printing some information I wanted. Does OSG have support for multithreading? yes it is, but only to render the scene. When you have multi camera or multi graphics context, you can render them in multithreaded operations. HTH David Callu ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiThreads in OSG
Hi Renan, Multi-threading is big topic, and yes the OSG does support multi-threading out of the box, but it there are constraints in how you need to manage the threading. Search through the archives on this topic to get a flavour. Personally I'd recommend using OpenThreads over native Windowing, as not only is it more portable, it'll integrate better with OSG apps. I also have to recommend taking small steps at learning about threading. Threading is one of the most awkward topics in computing, there are lots of issues that you don't see in single threading apps. Robert. On Tue, May 6, 2008 at 8:41 PM, Renan Mendes [EMAIL PROTECTED] wrote: Hi, everyone. I've tried creating another thread in my application using the windows API (CreateThread, etc), but it seems that this thread has become a main thread, i.e, my program is not working as a multithreaded application. In my case, this means that I'm not even displaying the OSG default screen - all I have is the prompt display, printing some information I wanted. Does OSG have support for multithreading? Or my problem is probably misuse of multithreading? Thanks, Renan M Z Mendes ___ 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] MultiThreads in OSG
Thanks, Robert, for the tips. My intention when using multithreading is to try and solve a problem about an input device (I don't know if you remember me posting it). Well, the thing is, I'm putting the function that gets my device's output in the FRAME loop. But it locks the normal execution of my application if I don't touch (i.e. activate) my input device. That's why I needed another thread: to get another 'route' when my device wasn't activated. I don't know if you or Paul have already suggested that I added my class as a new Event Handler to the viewer doing some modifications which I don't recall. I'll look into the archives for that message, and perhaps I'll continue that topic to get some more details abput your solution. Thanks again. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiThreads in OSG
Hi Renan, Would it be possible to poll the device on each new frame? The is what osgViewer does internally for keyboard and mouse events, each frame eventTraversals() is called this goes and polls for events. In your own frame loop you could do your own polling. The osgviewerSDL examples has an example of polling of events outwith of osgViewer. If you can avoid needing an extra thread to poll the events then you'll keep life simpler, as threading while perfectly doable does add its own very steep learning curve. Robert. On Wed, May 7, 2008 at 1:31 PM, Renan Mendes [EMAIL PROTECTED] wrote: Thanks, Robert, for the tips. My intention when using multithreading is to try and solve a problem about an input device (I don't know if you remember me posting it). Well, the thing is, I'm putting the function that gets my device's output in the FRAME loop. But it locks the normal execution of my application if I don't touch (i.e. activate) my input device. That's why I needed another thread: to get another 'route' when my device wasn't activated. I don't know if you or Paul have already suggested that I added my class as a new Event Handler to the viewer doing some modifications which I don't recall. I'll look into the archives for that message, and perhaps I'll continue that topic to get some more details abput your solution. Thanks again. Renan M Z Mendes ___ 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] MultiThreads in OSG
Hello,
there is something I don't understand:
you say that threading is a complex matter, and if possible
better to avoid:
Robert Osfield wrote on Wednesday 07 May 2008:
as threading while perfectly doable does add its own
very steep learning curve.
yet you also said that SDL is not very good because it
prevents multi-threading:
Personally I wouldn't recommend SDL for windowing for
serious 3d graphics applications, its just way too
limiting - its really just designed for single threaded,
single context apps.
http://lists.openscenegraph.org/pipermail/osg-users-opens
cenegraph.org/2007-August/000558.html
How do I know whether my application needs multi-threading ?
Or multiple contexts ?
If I have to use SDL anyway (for joystick handling) would
that make it automatically single-threaded ?
What limitations would SDL impose if I created the window
and graphical context with it, for OSG to render in it ?
What I have is:
viewer.realize();
while ( !viewer.done() !quit )
{
[...]
if (joystick) inputDev.handleJoystick();
[...]
viewer.getCamera()-setViewMatrix( CameraMatrix );
viewer.frame();
}
If multi-threading is complex, I'll avoid it anyway, so SDL
might not limit me in this case.
I'm a bit confused.
Zoltán
--
Zoltan
http://sourceforge.net/projects/zsim
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiThreads in OSG
Hi Zoltan,
SDL is design around single threaded, single context model for doing
windowing, for a general purpose and scalable scene graph like the OSG
this is pretty restrictive, so I would recommend using SDL for
windowing, and would suggest one use osgViewer's native windowing
support as this supports multi-threading, multiple graphics context
and pbuffers without any complexity being pushed on the user.
SDL however is good for device support like joysticks, and its use
works just fine with an osgViewer based app, just poll the events from
the frame loop as I previously suggested.
Robert.
On Wed, May 7, 2008 at 2:36 PM, Zoltán [EMAIL PROTECTED] wrote:
Hello,
there is something I don't understand:
you say that threading is a complex matter, and if possible
better to avoid:
Robert Osfield wrote on Wednesday 07 May 2008:
as threading while perfectly doable does add its own
very steep learning curve.
yet you also said that SDL is not very good because it
prevents multi-threading:
Personally I wouldn't recommend SDL for windowing for
serious 3d graphics applications, its just way too
limiting - its really just designed for single threaded,
single context apps.
http://lists.openscenegraph.org/pipermail/osg-users-opens
cenegraph.org/2007-August/000558.html
How do I know whether my application needs multi-threading ?
Or multiple contexts ?
If I have to use SDL anyway (for joystick handling) would
that make it automatically single-threaded ?
What limitations would SDL impose if I created the window
and graphical context with it, for OSG to render in it ?
What I have is:
viewer.realize();
while ( !viewer.done() !quit )
{
[...]
if (joystick) inputDev.handleJoystick();
[...]
viewer.getCamera()-setViewMatrix( CameraMatrix );
viewer.frame();
}
If multi-threading is complex, I'll avoid it anyway, so SDL
might not limit me in this case.
I'm a bit confused.
Zoltán
--
Zoltan
http://sourceforge.net/projects/zsim
___
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] MultiThreads in OSG
Hi Zoltan, I think what Robert meant was that threading is a complex topic if you want to dive in and code it all yourself. osgViewer takes care of all this for you, so you can use it and have your application multi-threaded without having to deal with that complexity. Think of it as an abstraction layer. It's done, just *use* it and don't really worry about *how* it's done. On the other hand, SDL's graphics functionality is totally orthogonal to its input functionality. If you want to use SDL for joystick support, you can do so as described in previous posts. Just don't use its graphics and windowing functions, and let osgViewer do its work. Hope this helps, J-S -- __ Jean-Sebastien Guay[EMAIL PROTECTED] http://www.cm-labs.com/ http://whitestar02.webhop.org/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiThreads in OSG
Jean-Sébastien Guay wrote on Wednesday 07 May 2008: I think what Robert meant was that threading is a complex topic if you want to dive in and code it all yourself. osgViewer takes care of all this for you, Ah OK, I understand. On the other hand, SDL's graphics functionality is totally orthogonal to its input functionality. If you want to use SDL for joystick support, you can do so as described in previous posts. Just don't use its graphics and windowing functions, and let osgViewer do its work. All the better, that's what I do today. Thanks for the explanation. Cheers Zoltán -- Zoltan http://sourceforge.net/projects/zsim ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] MultiThreads in OSG
gosh, if you used osgVRPN (or VRPN directly) you'd probably be running by now. -- mew On Wed, May 7, 2008 at 7:31 AM, Renan Mendes [EMAIL PROTECTED] wrote: Thanks, Robert, for the tips. My intention when using multithreading is to try and solve a problem about an input device (I don't know if you remember me posting it). Well, the thing is, I'm putting the function that gets my device's output in the FRAME loop. But it locks the normal execution of my application if I don't touch (i.e. activate) my input device. That's why I needed another thread: to get another 'route' when my device wasn't activated. I don't know if you or Paul have already suggested that I added my class as a new Event Handler to the viewer doing some modifications which I don't recall. I'll look into the archives for that message, and perhaps I'll continue that topic to get some more details abput your solution. Thanks again. Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org -- Mike Weiblen -- Austin Texas USA -- http://mew.cx/ ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] MultiThreads in OSG
Hi, everyone. I've tried creating another thread in my application using the windows API (CreateThread, etc), but it seems that this thread has become a main thread, i.e, my program is not working as a multithreaded application. In my case, this means that I'm not even displaying the OSG default screen - all I have is the prompt display, printing some information I wanted. Does OSG have support for multithreading? Or my problem is probably misuse of multithreading? Thanks, Renan M Z Mendes ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
