You are going to have to register your object with Jitter as an ob3d because you need to get context notifications to do what you're doing. Things like framebuffers and getString etc. all require a valid context or else you will experience the world of hurt you are currently in. Also, take a look at the various jit.gl headers. For example you may find t_jit_gl_support useful since it in has already parsed out glGetString for you and assigned struct variables to define what extensions/properties of OpenGL the rendered suports.

best, wes

On Jan 17, 2008 6:20 PM, Jean-Marc Pelletier wrote: > > Hi all, > > I'm currently trying to write an external that makes use of OpenGL but I'm running into some problems. Note that this is not an ob3d object: the OpenGL functionality is completely encapsulated and opaque to the user. > > I can't even seem to get started, however, as I'm running into very frequent bad access crashes. For instance, the following crashes unless a jit.gl.xxxx object was created prior to loading my external: > > GLuint fbid; > glGenFramebuffersEXT(1,&fbid); > > > On the other hand, the code below always crashes (on sscanf) no matter what: > > const GLubyte *glstring; > float glversion; > > glstring = glGetString(GL_VERSION); > sscanf((char *)glstring,"%f",&glversion); > > It's obvious I'm missing something fundamental to make this work, but what? >

Thanks, that was quick.

Quote: wesley.hoke@gmail.com wrote on Thu, 17 January 2008 19:27 ---------------------------------------------------- > You are going to have to register your object with Jitter as an ob3d > because you need to get context notifications to do what you're doing. > Things like framebuffers and getString etc. all require a valid > context or else you will experience the world of hurt you are > currently in.

Wouldn't that imply a dependency on jit.gl.render? That is what I'm trying to avoid.

Would it be possible to generate my own context internally? I'm not rendering to either jit.window or pwindow. aglCreateContext?

> Wouldn't that imply a dependency on jit.gl.render? That is what I'm trying to avoid. > > Would it be possible to generate my own context internally? I'm not rendering to either jit.window or pwindow. aglCreateContext? >

What are you in fact trying to render to? wes

Quote: wesley.hoke@gmail.com wrote on Thu, 17 January 2008 20:14 ---------------------------------------------------- > > What are you in fact trying to render to?

Offscreen. I tried using GLUT to create a hidden window but no luck: instant silent crash.

> > What are you in fact trying to render to? > > Offscreen. I tried using GLUT to create a hidden window but no luck: instant silent crash. >

>From what I understand of the AGL API, offscreen rendering can be done offscreen by using the software renderer (incredibly slow) or using things like pbuffers or FBOs. The latter requires some kind of window and context which you may be able to hide but I'm not sure. You'll have to research this part yourself.

Also, don't use GLUT. It plain won't work as you found out. GLUT requires you to call glutMainLoop, which takes over the application loop. Max will not be happy with you if you do that and you will mess many things up.

In short, use FBOs, but you'll have to make your own context stuff up yourself if you don't want to use jit.window/jit.pwindow. Good luck!

best, wes

Quote: wesley.hoke@gmail.com wrote on Thu, 17 January 2008 21:05 ----------------------------------------------------

> In short, use FBOs, but you'll have to make your own context stuff up > yourself if you don't want to use jit.window/jit.pwindow. Good luck!

FBOs are exactly what I am trying to use. I'll try using Apple's API for creating a rendering context to see what comes out of it. I'll post something if I manage to make it work.

Thanks for the help.

I managed to get it to work. Indeed, creating my own context was the way to go. Here's the working code. (You need to include the OpenGL and and AGL frameworks.)

AGLContext gAGLContext = NULL; AGLPixelFormat aglPixelFormat; const GLubyte *glstring; float glversion; GLint attributes[] = { AGL_RGBA, AGL_OFFSCREEN, AGL_NONE };

aglPixelFormat = aglChoosePixelFormat(NULL, 0, attributes); if (aglPixelFormat==NULL){error("Could not get pixel format.");return JIT_ERR_GENERIC;}

gAGLContext = aglCreateContext(aglPixelFormat, NULL); if (gAGLContext==NULL){error("Could not create rendering context.");return JIT_ERR_GENERIC;}

if(!aglSetCurrentContext(gAGLContext)){error("Could not make context current.");return JIT_ERR_GENERIC;}

//Check OpenGL functionality: glstring = glGetString(GL_VERSION); sscanf((char *)glstring,"%f",&glversion);

post("OpenGL version: %s",(char *)glstring); if(glversion < 2.f){error("Invalid OpenGL version: 2.0 or later is required."); return JIT_ERR_GENERIC;}

glstring = glGetString(GL_EXTENSIONS); if(!gluCheckExtension((const GLubyte *)"GL_EXT_framebuffer_object",glstring)){error("The GL_EXT_framebuffer_object extension is not supported on this system.");

On Jan 18, 2008, at 7:04 AM, Jean-Marc Pelletier wrote:

> I managed to get it to work. Indeed, creating my own context was > the way to go. Here's the working code. (You need to include the > OpenGL and and AGL frameworks.)

Hi Jean-Marc,

Glad to hear you're figuring this OpenGL stuff out for your project. One thing to consider with this code, is the probability that with a NULL device and just the offscreen flag, this aglChoosePixelFormat will most likely return a pixel format for a software based context. The OpenGL versions for each possible driver are different, so while your software renderer could support FBOs, your HW driver might not (again, different video cards in the same machine are also a possibility and each could have different versioned drivers and different levels of support). For fast FBO based rendering, it would require a HW context/driver.

Finally, there are cards which support FBO, but might not have OpenGL 2.0 drivers, in which case it would be better to check the extension strings somehow. I forget exactly what these mechanisms are off the top of my head, but a quick google on OpenGL extension strings FBO, yielded the following thread, which may have some of the information you are looking for, or at least get you started:

While OpenGL is a cross platform "standard", there is a huge amount of room for platform/device/driver differences even within the standard. It can be a *lot* of work trying to keep up. There are a variety of open source projects designed to make it easier to interrogate system capabilities which you may find useful. GLEW is one which is liberally licensed (BSD/MIT style), which you might be able to draw from:

Hope this helps.

-Joshua

Indeed GLEW is a really handyl lib. Make sure that the GLEW headers go before any other OpenGL headers, else you will get massive compilation errors.

wes

On Jan 18, 2008 9:18 AM, Joshua Kit Clayton wrote: > > On Jan 18, 2008, at 7:04 AM, Jean-Marc Pelletier wrote: > > > I managed to get it to work. Indeed, creating my own context was > > the way to go. Here's the working code. (You need to include the > > OpenGL and and AGL frameworks.) > > > Hi Jean-Marc, > > Glad to hear you're figuring this OpenGL stuff out for your project. > One thing to consider with this code, is the probability that with a > NULL device and just the offscreen flag, this aglChoosePixelFormat > will most likely return a pixel format for a software based context. > The OpenGL versions for each possible driver are different, so while > your software renderer could support FBOs, your HW driver might not > (again, different video cards in the same machine are also a > possibility and each could have different versioned drivers and > different levels of support). For fast FBO based rendering, it would > require a HW context/driver. > > Finally, there are cards which support FBO, but might not have OpenGL > 2.0 drivers, in which case it would be better to check the extension > strings somehow. I forget exactly what these mechanisms are off the > top of my head, but a quick google on OpenGL extension strings FBO, > yielded the following thread, which may have some of the information > you are looking for, or at least get you started: > > http://lists.apple.com/archives/mac-opengl/2006/Apr/msg00090.html > > While OpenGL is a cross platform "standard", there is a huge amount > of room for platform/device/driver differences even within the > standard. It can be a *lot* of work trying to keep up. There are a > variety of open source projects designed to make it easier to > interrogate system capabilities which you may find useful. GLEW is > one which is liberally licensed (BSD/MIT style), which you might be > able to draw from: > > http://glew.sourceforge.net/ > > Hope this helps. > > -Joshua > > >

Quote: wesley.hoke@gmail.com wrote on Fri, 18 January 2008 17:57 ---------------------------------------------------- > Indeed GLEW is a really handyl lib. Make sure that the GLEW headers go > before any other OpenGL headers, else you will get massive compilation > errors.

I tried glew some time ago, and I just checked again, and it seems impossible to use with Jitter. OpenGL headers are included in the standard Jitter includes and no matter where I put my link to glew.h, I'm getting an avalanche or errors. Somehow, gl.h manages to get linked before glew no matter what I do.

Check the prefix header! wes

On Jan 20, 2008 5:46 PM, Jean-Marc Pelletier wrote: > > Quote: wesley.hoke@gmail.com wrote on Fri, 18 January 2008 17:57 > ---------------------------------------------------- > > Indeed GLEW is a really handyl lib. Make sure that the GLEW headers go > > before any other OpenGL headers, else you will get massive compilation > > errors. > > I tried glew some time ago, and I just checked again, and it seems impossible to use with Jitter. OpenGL headers are included in the standard Jitter includes and no matter where I put my link to glew.h, I'm getting an avalanche or errors. Somehow, gl.h manages to get linked before glew no matter what I do. > >

Quote: wesley.hoke@gmail.com wrote on Sun, 20 January 2008 18:47 ---------------------------------------------------- > Check the prefix header! > wes >

Of course! (It's working now...)