Re: [osg-users] Using shared OpenGL contexts

; 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

[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

Re: [osg-users] Using GL textures generated outside of OSG, in a shared GL context

t; 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 Sebbe >

[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

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,

Re: [osg-users] SGI declares bankruptcy (UNCLASSIFIED)

; *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) > > Jum

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 bee

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'

Re: [osg-users] multisampling in embedded window?

, 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, >>

Re: [osg-users] multisampling in embedded window?

ill 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 tryi

[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(

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-users] deadlock in independent contexts

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, u

Re: [osg-users] Mac OpenGL integration / CGLMacro.h

> > of batched geometry submission (as opposed to immediate mode), and the > > increasing reliance on shaders rather than the OpenGL state machine > the > > value of this feature over time get's increasingly smaller. I have > made > > this > > retro-fit man

Re: [osg-users] Mac OpenGL integration / CGLMacro.h

t; failed to see however is any significant performance benefit to well > written > OpenGL code in the first place. > > Richard > > > > Robert Osfield writes: > > > On Thu, Mar 20, 2008 at 1:35 PM, Raphael Sebbe <[EMAIL PROTECTED]> > wrote: > >> tha

Re: [osg-users] Mac OpenGL integration / CGLMacro.h

20, 2008 at 2:52 PM, Robert Osfield <[EMAIL PROTECTED]> wrote: > On Thu, Mar 20, 2008 at 1:35 PM, Raphael Sebbe <[EMAIL PROTECTED]> > wrote: > > thanks for answering. I understand your point regarding cross platform > > complexity. However, I am pretty convinc

Re: [osg-users] Mac OpenGL integration / CGLMacro.h

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

[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

[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

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 t

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 PROTE

[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 a