Re: [osg-users] Using shared OpenGL contexts
Thank you Robert and Paul for this information. To further clarify, my goal is to be able to use multiple GL contexts representing the same scene from different camera angles, and those contexts could well be GL views in windows, FBOs, or even Core Animation GL layers (Mac). As said previously, having textures on 3D objects being the result of some GPU image processing (Core Image), or the other way around, using the result of 3D rendering as input to GPU filters (Core Image) are possible applications. But all these things require some kind of flexibility in the way you create/declare (possibly shared) contexts, to avoid duplicating VBO, DL and other GPU resources all over. A nice extension to OSG would be to make it possible to work with external contexts, even if some constraints need to be enforced (such as state preserving across OSG calls, or other threading constraints). But this is probably easier to say than to implement. I will dig some more in the source to find out. Thanks, Raphael On Fri, Aug 14, 2009 at 6:33 PM, Paul Martz pma...@skew-matrix.com wrote: Robert -- Thanks for replying to this; I saw the post and was curious myself as to how this could be done. Let's assume the app has created their own contexts and done so with object sharing set up correctly. Taking just DLs as an example, could the app enforce their own DL sharing with a Drawable draw callback? Seems like this would be possible, but I'd have to dig further. Not sure at all how an app would do with with shared buffer objects, texture objects, etc. Paul Martz Skew Matrix Software LLC *http://www.skew-matrix.com* http://www.skew-matrix.com/ +1 303 859 9466 Robert Osfield wrote: Hi Raphael, On Tue, Aug 11, 2009 at 6:36 PM, Raphael Sebberaphael.se...@gmail.com raphael.se...@gmail.com wrote: Is it possible in OSG to use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. There isn't any support for doing this directly. If you use the GraphicsWindowEmedded feature of osgViewer they you could probably do it, but you'd loose threading and multi-context support provided by osgViewer. If you just need a single context and single threading then this would be OK. See the osgviewerSDL and osgviewerGLUT for examples of this in action. In general though, the OSG is designed to be the primary way you drive OpenGL apps rather than something that is secondary and piggy backing on the back of another part of the app that does OpenGL. Lazy state updating, state sorting, threading and and multi-context management that make the scene graph so useful are all things that make mixing with 3rd party OpenGL code awkward. Robert. ___ osg-users mailing listosg-us...@lists.openscenegraph.orghttp://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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using shared OpenGL contexts
Hi, Is it possible in OSG to use shared opengl contexts that are created outside of OSG, and yet declare to OSG that they are sharing their texture spaces (and VBO, etc)? I searched the documentation, but could not find a way to do that. Thank you, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Using GL textures generated outside of OSG, in a shared GL context
Hi Robert, OK, I will investigate that route. The main idea is that some work gets done on the GPU with another API, and it would loose all benefit if I have to read that back through the bus to CPU memory to just afterwards send it back to OSG to recreate a GL texture with that. Lots of things can be made on the GPU these days... Thank you, Raphael On Mon, Jul 27, 2009 at 10:26 AM, Robert Osfield robert.osfi...@gmail.comwrote: Hi Raphael, It's technically possible, but the OSG is not designed out of the box to facilitate this, so you'll need to wrap up the texture ID via a custom subclass of osg::Texture. Personally I would avoid playing games like this as manage threading and multi-contexts out-with the full control of the OSG will require very careful management. Robert. On Sun, Jul 26, 2009 at 6:45 PM, Raphael Sebberaphael.se...@gmail.com wrote: Hi all, In my app, I would to use an OpenGL texture (with an existing GLuint id) as a texture map to an object of an OSG scene. The texture is generated outside of OSG, but OSG GL context and the texture GL context are the same (or shared). Could someone tell me if this can be achieved in OSG, and if it is, how? Thank you in advance, Raphael ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Using GL textures generated outside of OSG, in a shared GL context
Hi all, In my app, I would to use an OpenGL texture (with an existing GLuint id) as a texture map to an object of an OSG scene. The texture is generated outside of OSG, but OSG GL context and the texture GL context are the same (or shared). Could someone tell me if this can be achieved in OSG, and if it is, how? Thank you in advance, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Picking Problem PolytopeIntersector
Hi, I second Paul on that. Generally speaking, you need some kind of tolerance (or margin) when picking for best user experience. Users dont want to spend time trying to pick an object. And that's exactly what polytope is about. But if you only have large objects (pixel size) in your application, well, line intersector may be just fine. Raphael On Fri, Apr 24, 2009 at 8:04 PM, Jean-Sébastien Guay jean-sebastien.g...@cm-labs.com wrote: Hi Paul, When you do a mouse pick, you generally are trying to pick an object that falls into a small screen-space box around the cursor. In a perspective view, the box has smaller world-space extents at the near plane, and larger world-space extents at the far plane. In essence, it looks like a view frustum. PolytopeIntersector is the only intersector that accurately represents this pick volume. Yes, but this is only a problem if the user clicks on the pixels at the edge of the object (or the limit case, if the object occupies only one pixel on screen). The chances that the user will click just at the edge of the object and the ray will miss are really small. Generally the object is big enough on screen (even if the object occupies 5x5 pixels I'd be surprised to see a user click on the edge, most of the time they'll click in the middle). Every developer is free to make the choices they want. I consider this case much too infrequent, and it has not been a problem for us. I have not had one user tell me hey, I should have selected the object then but I didn't. J-S -- __ Jean-Sebastien Guayjean-sebastien.g...@cm-labs.com 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED)
For Pixar involvement, I just re-read it, it is in the Renderman Companion, in the last part of Pat Hanrahan foreword (May 1989). ... *During this time, we also began a joint project with Silicon Graphics to work on a three-dimensional graphics library usable for both interactive graphics and high-quality rendering* ... (the time he's referring there is the time when the RISpec was built) Not sure though if that joint project is IrisGL, or if it's something else actually... Thanks for sharing! Raphael On Sun, Apr 5, 2009 at 12:25 AM, Paul Martz pma...@skew-matrix.com wrote: Not sure about Pixar's involvement. The Genesis of OpenGL varies depending on who you ask. People inside SGI say that OpenGL was driven by customer demand. Their users wanted to see IrisGL deployed on non-SGI platforms. SGI tried this with a fee hardware vendors, but the support was spotty, different vendors supported IrisGL in different ways, and the same app did not run the same way across platforms. So SGI came up with OpenGL and designed it in such a way that anyone could support it well. However, if you talk to anyone in the PHIGS/PEX camp during the late 80s/early 90s, they'll tell you that SGI was feeling threatened by the widespread adoption of PHIGS/PEX, and decided to turn IrisGL into an open standard (OpenGL) in order to kill off PHIGS/PEX. PEX was an open standard adopted by just about anyone with X Windows on their box, but SGI had not been invited to join the PEX consortium. So there was some animosity there. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com +1 303 859 9466 -- *From:* osg-users-boun...@lists.openscenegraph.org [mailto: osg-users-boun...@lists.openscenegraph.org] *On Behalf Of *Raphael Sebbe *Sent:* Saturday, April 04, 2009 3:28 AM *To:* OpenSceneGraph Users *Subject:* Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED) Jumping in... Well, I would definitely be interested in getting more history background about the original design of the OpenGL API. There was a collaboration between Pixar and SGI in the late 80s, probably around the same time that both IrisGL and the Renderman specification emerged. Pixar had been working on this for some time, yet, I am unsure of how the whole process of OpenGL (IrisGL) happened. Did Pixar propose the Renderman specification to SGI, which then proposed a real-time api inspired on that? Or did SGI develop this all internally and by chance came to some similar design? Raphael On Fri, Apr 3, 2009 at 10:42 PM, Paul Martz pma...@skew-matrix.comwrote: As the British punk band The Stranglers used to say, Everybody loves you when you're dead. Sure, SGI did some things pretty well, but let us not forget they also did some things pretty poorly, and in my opinion were really not much better or worse than many other hardware vendors. Things they did well: OpenGL 1.0 was a masterpiece of design that took the graphics world by storm and utterly crushed several other competing APIs of the era. This is an API that is so well-accepted that it has outlived its creator. Things they didn't do well: Too much focus on the high end. Bad business decisions. No focus on open standards until absolutely forced to do so. Not able to keep pace with the industry (look where they are now). And marketing faux pas... When OpenGL 1.0 first came out, SGI marketing constantly repeated the notion that immediate mode was the most important thing in the world. (This was a direct slam against the PHIGS/PEX APIs, which were focused on retained mode.) At the same time, SGI was promoting their 1.1 million triangles/second hardware. However, all their demos had a performance HUD that clearly showed significantly less than 1.1m tris/sec. When pressed on this, they eventually published a benchmark that demonstrated 1.1m tris/sec, but it used display lists. Oops. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED)
Jumping in... Well, I would definitely be interested in getting more history background about the original design of the OpenGL API. There was a collaboration between Pixar and SGI in the late 80s, probably around the same time that both IrisGL and the Renderman specification emerged. Pixar had been working on this for some time, yet, I am unsure of how the whole process of OpenGL (IrisGL) happened. Did Pixar propose the Renderman specification to SGI, which then proposed a real-time api inspired on that? Or did SGI develop this all internally and by chance came to some similar design? Raphael On Fri, Apr 3, 2009 at 10:42 PM, Paul Martz pma...@skew-matrix.com wrote: As the British punk band The Stranglers used to say, Everybody loves you when you're dead. Sure, SGI did some things pretty well, but let us not forget they also did some things pretty poorly, and in my opinion were really not much better or worse than many other hardware vendors. Things they did well: OpenGL 1.0 was a masterpiece of design that took the graphics world by storm and utterly crushed several other competing APIs of the era. This is an API that is so well-accepted that it has outlived its creator. Things they didn't do well: Too much focus on the high end. Bad business decisions. No focus on open standards until absolutely forced to do so. Not able to keep pace with the industry (look where they are now). And marketing faux pas... When OpenGL 1.0 first came out, SGI marketing constantly repeated the notion that immediate mode was the most important thing in the world. (This was a direct slam against the PHIGS/PEX APIs, which were focused on retained mode.) At the same time, SGI was promoting their 1.1 million triangles/second hardware. However, all their demos had a performance HUD that clearly showed significantly less than 1.1m tris/sec. When pressed on this, they eventually published a benchmark that demonstrated 1.1m tris/sec, but it used display lists. Oops. Paul Martz Skew Matrix Software LLC http://www.skew-matrix.com +1 303 859 9466 ___ 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] MAC
I think it's right in the middle of moving from Xcode based projects to cmake build system, which currently generates dylibs instead of frameworks (I may not be up to date, checked a couple of weeks ago, moving target). Once you get a successful build in cmake, with proper build flags, you shouldn't have much surprise on the mac. Raphael On Wed, Nov 19, 2008 at 1:46 AM, Ulrich Hertlein [EMAIL PROTECTED]wrote: Quoting Don Leich [EMAIL PROTECTED]: My experience with Mac development has not quite so smooth. Getting cmake to build was a battle and beyond the scope of this thread. OSG itself has some appearant rough edges with OSG and X11 integration. I am working with Odd, it was a complete breeze for me getting OSG/cmake/Makefiles (cmake 2.6 from DarwinPorts) compiled on OS X. I don't know why you have to use X11 (Qt?) but that could be the cause of your problems. You'd probably see similar issues running OSG/X11 on Windows. /ulrich ___ 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
[osg-users] multisampling in embedded window?
Hi, I am trying to enable multisampling in an embedded viewer, with no luck so far. It works great on stand alone Viewer though. Here is what I do: Create an OpenGL buffer with multisampling enabled. Then, this: osg::DisplaySettings * ds = osg::DisplaySettings::instance(); ds-setNumMultiSamples(4); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); But this doesn't make it. I also tried this: ref_ptr DisplaySettings displaySettings = new DisplaySettings; displaySettings-setNumMultiSamples(4); _osgViewData-viewer-setDisplaySettings( displaySettings.get() ); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); Same result. Do you have any recommendation on what to check to make multisampling anti-aliasing work? Thank you, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multisampling in embedded window?
Hi Robert, Thank you, I was not aware of that. I'll experiment some more. Raphael On Tue, Nov 18, 2008 at 11:14 AM, Robert Osfield [EMAIL PROTECTED]wrote: Hi Raphael, If you are embedded the OSG within an existing OpenGL graphics context then no OSG settings will make any difference, you'll have to request a multi-sample visual from whatever toolkit you are using to create the graphic context. Robert. On Tue, Nov 18, 2008 at 10:01 AM, Raphael Sebbe [EMAIL PROTECTED] wrote: Hi, I am trying to enable multisampling in an embedded viewer, with no luck so far. It works great on stand alone Viewer though. Here is what I do: Create an OpenGL buffer with multisampling enabled. Then, this: osg::DisplaySettings * ds = osg::DisplaySettings::instance(); ds-setNumMultiSamples(4); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); But this doesn't make it. I also tried this: ref_ptr DisplaySettings displaySettings = new DisplaySettings; displaySettings-setNumMultiSamples(4); _osgViewData-viewer-setDisplaySettings( displaySettings.get() ); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); Same result. Do you have any recommendation on what to check to make multisampling anti-aliasing work? Thank you, Raphael ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] multisampling in embedded window?
Some conclusions: the opengl context created in Interface Builder did not respect the requested settings (multisample and sample count). Providing a pixel format manually fixed this issue. As you said, nothing special has to be done on OSG side. Thanks, Raphael On Tue, Nov 18, 2008 at 11:22 AM, Raphael Sebbe [EMAIL PROTECTED]wrote: Hi Robert, Thank you, I was not aware of that. I'll experiment some more. Raphael On Tue, Nov 18, 2008 at 11:14 AM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Raphael, If you are embedded the OSG within an existing OpenGL graphics context then no OSG settings will make any difference, you'll have to request a multi-sample visual from whatever toolkit you are using to create the graphic context. Robert. On Tue, Nov 18, 2008 at 10:01 AM, Raphael Sebbe [EMAIL PROTECTED] wrote: Hi, I am trying to enable multisampling in an embedded viewer, with no luck so far. It works great on stand alone Viewer though. Here is what I do: Create an OpenGL buffer with multisampling enabled. Then, this: osg::DisplaySettings * ds = osg::DisplaySettings::instance(); ds-setNumMultiSamples(4); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); But this doesn't make it. I also tried this: ref_ptr DisplaySettings displaySettings = new DisplaySettings; displaySettings-setNumMultiSamples(4); _osgViewData-viewer-setDisplaySettings( displaySettings.get() ); _osgViewData-window = _osgViewData-viewer-setUpViewerAsEmbeddedInWindow(100,100,bounds.width, bounds.height); Same result. Do you have any recommendation on what to check to make multisampling anti-aliasing work? Thank you, Raphael ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] deadlock in independent contexts
Hi,
I have some additional information.
I moved to OSGv2.6rc1, built the .dylib with cmake. I still get the same
deadlock situation, with the same thread backtraces (I had to create 7
windows, the log makes it more difficult to get to that situation).
I uncommented this line in getCompileContext:
osg::notify(osg::NOTICE)GraphicsContext::getCompileContext
contextIDstd::endl;
And it shows this (meaning all threads except one, 0, are blocked):
.
*GraphicsContext::getCompileContext 3*
*GraphicsContext::getCompileContext 5*
*GraphicsContext::getCompileContext 6*
*GraphicsContext::getCompileContext 1*
*GraphicsContext::getCompileContext 3*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 4*
*GraphicsContext::getCompileContext 2*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
*GraphicsContext::getCompileContext 0*
... always 0
Can it be an OpenThreads implementation problem? Do you have any other
suggestion?
Note: made on a dual proc system (Core2Duo), compiled in 32-bit.
Thank you,
Raphael
On Tue, Jul 29, 2008 at 5:26 PM, Raphael Sebbe [EMAIL PROTECTED]wrote:
Hi,
I have come across a problem when performing multi-threaded rendering.
The application setup is as follows: 4 windows with 4 independent OpenGL
contexts, with 4 associated GraphicsWindowEmbedded. There are 4 threads,
invoking Viewer-frame().
After some time, 3 out of 4 threads are blocked, using gdb, I get the
deadlock locations:
2 threads are in this:
#0 0x90c5a4ee in semaphore_wait_signal_trap
#1 0x90c61fc5 in pthread_mutex_lock
#2 0x00299ffc in std::_Rb_treeunsigned int, std::pairunsigned int const,
ContextData, std::_Select1ststd::pairunsigned int const, ContextData ,
std::lessunsigned int, std::allocatorstd::pairunsigned int const,
ContextData ::insert_unique
#3 0x00295b18 in osg::GraphicsContext::getCompileContext
#4 0x0051ed05 in osgViewer::Renderer::cull_draw
#5 0x00297350 in osg::GraphicsContext::runOperations
#6 0x00521d20 in osgViewer::ViewerBase::renderingTraversals
#7 0x3b91 in -[OSGView drawRect:] at OSGView.mm:367
#8 0x3d7d in -[OSGView displayFrame:] at OSGView.mm:400
#9 0x3007 in MEDisplayLinkCallback at OSGView.mm:102
#10 0x955a8013 in CVDisplayLink::performIO
#11 0x955a863f in CVDisplayLink::runIOThread
#12 0x90c8b6f5 in _pthread_start
#13 0x90c8b5b2 in thread_start
Another one in this:
#0 0x90c5a4ee in semaphore_wait_signal_trap
#1 0x90c61fc5 in pthread_mutex_lock
#2 0x00299ffc in std::_Rb_treeunsigned int, std::pairunsigned int const,
ContextData, std::_Select1ststd::pairunsigned int const, ContextData ,
std::lessunsigned int, std::allocatorstd::pairunsigned int const,
ContextData ::insert_unique
#3 0x00295b18 in osg::GraphicsContext::getCompileContext
#4 0x00060060 in osgDB::DatabasePager::requiresExternalCompileGLObjects
#5 0x0051ef88 in osgViewer::Renderer::cull_draw
#6 0x00297350 in osg::GraphicsContext::runOperations
#7 0x00521d20 in osgViewer::ViewerBase::renderingTraversals
#8 0x3b91 in -[OSGView drawRect:] at OSGView.mm:367
#9 0x3d7d in -[OSGView displayFrame:] at OSGView.mm:400
#10 0x3007 in MEDisplayLinkCallback at OSGView.mm:102
#11 0x955a8013 in CVDisplayLink::performIO
#12 0x955a863f in CVDisplayLink::runIOThread
#13 0x90c8b6f5 in _pthread_start
#14 0x90c8b5b2 in thread_start
Seems to be in there:
GraphicsContext* GraphicsContext::getCompileContext(unsigned int contextID)
{
// osg::notify(osg::NOTICE)GraphicsContext::getCompileContext
contextIDstd::endl;
OpenThreads::ScopedLockOpenThreads::Mutex lock(s_contextIDMapMutex);
ContextIDMap::iterator itr = s_contextIDMap.find(contextID);
if (itr != s_contextIDMap.end()) return
itr-second._compileContext.get();
else return 0;
}
I did not configure any thread specific flags in OSG (perhaps I should have
done that?), I am not familiar with how OSG handles threading.
I also cannot instrument OSG to debug this as I am using precompiled
binaries (OSX frameworks), OSG 2.2.0-10.5SDK.
I can workaround this by making all rendering mutually exclusive, but this
is obviously not what I want.
Any advice would be greatly appreciated. Thanks,
Raphael
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Mac OpenGL integration / CGLMacro.h
Hi all, On Mac OS X, there is a possibility of using a special mechanism for OpenGL calls, that is, you include CGLMacros.h in your source, and all gl*** calls take an implicit additional parameter, the context. This makes the use of a current active context unnecessary, gives better performance and it works better with threads. Developers are encouraged to use that mechanism. Some apps (thinking of Quartz Composer) strongly suggest that this is used for their plugins, drawing to the given context, and discourage changing the current OpenGL context. I guess we're not far from a suggest becoming a require in the future. The way it works is that you have to define a local variable with the name cgl_ctx, and that variable is passed as first argument to the special gl calls: CGLContextObj cgl_ctx = aContext; glBegin(GL_LINES); // which actually is like _blaBegin(cgl_ctx, GL_LINES), because of CGLMacro.h inclusion // this won't compile if cgl_ctx is not defined So my question is: what is your thought about integrating this mechanism in OSG? Thanks, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Mac OpenGL integration / CGLMacro.h
Hi Robert, thanks for answering. I understand your point regarding cross platform complexity. However, I am pretty convinced that passing the context to drawing functions makes sense these days, especially considering the many contexts and threads running in parallel, and I don't get this as a vendor lock-in strategy, although this can be a side-effect of course. Raphael On Thu, Mar 20, 2008 at 1:32 PM, Robert Osfield [EMAIL PROTECTED] wrote: Hi Raphael, The changes of the OSG uses this tricked out non standard vendor lock-in mechanism are 0. If such an extension was available across platforms it might make some sense, but given the massive amount of changes it'd require, for a minor platform like OSX, and the likely small performance delta they might give anyway I think it would be huge waste of resources and added code complexity, associated bugs and testing. It would in the end be an utter nightmare to maintain for little gain for a small number of users. Far more interesting is items like OpenGL-ES and OpenGL 3.x, this is the future of OpenGL, not a silly little detour Apple hopes to hook you into to make you apps even more tied to a single platform. Robert. On Thu, Mar 20, 2008 at 11:22 AM, Raphael Sebbe [EMAIL PROTECTED] wrote: Hi all, On Mac OS X, there is a possibility of using a special mechanism for OpenGL calls, that is, you include CGLMacros.h in your source, and all gl*** calls take an implicit additional parameter, the context. This makes the use of a current active context unnecessary, gives better performance and it works better with threads. Developers are encouraged to use that mechanism. Some apps (thinking of Quartz Composer) strongly suggest that this is used for their plugins, drawing to the given context, and discourage changing the current OpenGL context. I guess we're not far from a suggest becoming a require in the future. The way it works is that you have to define a local variable with the name cgl_ctx, and that variable is passed as first argument to the special gl calls: CGLContextObj cgl_ctx = aContext; glBegin(GL_LINES); // which actually is like _blaBegin(cgl_ctx, GL_LINES), because of CGLMacro.h inclusion // this won't compile if cgl_ctx is not defined So my question is: what is your thought about integrating this mechanism in OSG? Thanks, Raphael ___ 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Syntax coloring of OSG headers in Xcode
Hi, does anyone know a way to make OSG headers syntax-colored in Xcode? I can change the file type to sourcecode.cpp for individual files in a given project and make them colored, but I am interested in an automatic way. I saw there was some support for other IDEs on OSG website. Thanks, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] New to OSG, some questions (selection buffer, parametric curves)
Hi everyone, I am new to OSG, yet intend to use it for some projects. I've been through implementing some scene graph things before, I find OSG very interesting, I appreciate tight OpenGL integration (no cumbersome abstractions) and clean class design. So far I have a few questions regarding some aspects of OSG: - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? Thank you very much, Raphael ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
Hi J-S, Yes, geometry shaders would be a must for these (and also for subdivision surfaces). I'd be interested in contributing to these (time permitting, you know that...), although I first have to catch up with OSG. Thank you! Raphael On Feb 11, 2008 10:29 PM, Jean-Sébastien Guay [EMAIL PROTECTED] wrote: Hello Raphael, Welcome! Hope you enjoy your time working with OSG, and the community around it! - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? I'll let others answer this one, I don't know myself. I have always found OpenGL selection buffers cumbersome to use, but with a good wrapper it should be possible to make something that works well and is easy to use I imagine. So I don't know why that was not done. - Support for parametric curves / surfaces (Bezier, NURBs and the likes). Are there any plan to support this directly (through GLU or other), or should I export those as polygonal data instead? I would like to eventually help in adding support for parametric curves and surfaces in OSG. I have used the GLU interface before and would have used that as the first step, followed by an implementation using Geometry Shaders, with the ability to select the implementation you want to use at runtime and a fallback mechanism. I think it would be really cool to support that. But I haven't gotten to it thus far... :-( If you want to start doing something in this direction, I will be glad to test and comment. And search the archives, there was a discussion related to this not too long ago, so there was obviously interest in this. Hope that helps, and again welcome. 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 ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] New to OSG, some questions (selection buffer, parametric curves)
I didn't know software rasterizer was used... hmm, but thinking about it, it makes sense as retrieving info from the GPU has not always been an easy thing, yet selection buffer exists since a very long time. Anyway, as you said, higher level knowledge of the scene is definitely an advantage. I'll try to reproduce the same configuration (selecting a square of given width around the click in view space, think I saw a pyramid-like intersection primitive for doing this in OSG) as I did before with selection buffer. Thanks for that info, Raphael On Feb 12, 2008 2:52 AM, Paul Martz [EMAIL PROTECTED] wrote: - OpenGL selection buffer seems not recommended as a way of picking in OSG, explicit primitive intersections are used instead. Could someone please comment on this (why...)? OpenGL's selection render mode is almost universally implemented via software rendering, and is therefore painfully slow for any moderate geometry load. It also tends to be O(n) -- your app just renders everything, even stuff no where near the pick point. You can sidestep these issues by reducing or simplifying the geometry being tested. Selection is the only (sort of direct) support OpenGL has for picking, so if you're using OpenGL and don't want to code a better method, then you're stuck with selection. Fortunately OSG has a superior alternative. One thing scene graphs are good at is spatial organization. As a result, pick testing in a scene graph is O(log(n)). Although it also runs in software, it performs simple ray/sphere intersection tests, which are much more efficient than software rasterization. Paul Martz *Skew Matrix Software LLC* http://www.skew-matrix.com 303 859 9466 ___ 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
