Sign in to follow this  
Followers 0
_the_phantom_

OpenGL
OpenGL BOF @ SIGGRAPH

9 posts in this topic

The slides from the OpenGL BOF at SIGGRAPH 2006 are avalible to download from http://www.khronos.org/developers/library/siggraph2006/OpenGL_BOF/. They are abbreviated but give some nice details about the latest OpenGL news and what the future could hold [smile] Also, a bit late but for those who haven't seen it there is a new letter called Pipeline which also includes some details. Enjoy [smile]
0

Share this post


Link to post
Share on other sites
That's some excellent info, thanks phantom. I don't think there's anyone here who isn't looking forward to some of the proposals made (particularly spicy stuff in the "New Object Model" and "OpenGL 3 directions" slides).

I was at first a bit apprehensive of the heavyweight SDK idea (thinking of the huge DirectX SDK downloads), but the "Ecosystem" slide clears all that up as well. If I'm not wrong it's going to be based online, constantly updated whenever new changes are finalised.

Anyway, there's a lot there to keep us satisfied for a while. Once again, thanks phantom.
0

Share this post


Link to post
Share on other sites
I'm encouraged by the positive feedback so far - this tells me we're going in the right direction. If you're curious, there's a thread on opengl.org where we go into more detail on the object model.

-- Michael
0

Share this post


Link to post
Share on other sites
That was certainly interesting, thank you for the link (and the great talk [smile]) gold!

It appears that you decision-makers are really undecided on whether to retain a display list functionality and I'm curious as to how it turns out. Uptil now, there are just about 2 things people do with display lists:

1) Put geometry data in high performance memory (now obsolete due to existence of VBO)
2) Set a lot of Render states with 1 call.

Now, (2) is reduced as an issue due to the increased use of shaders but I for one would like the option of caching render states into a structure (which may be akin to the old display lists).

Anyway, great job. I think some people will love the steps forward you're taking (me included) and some others may think the change could be implemented differently. The fact that you are taking an initiative to improve OpenGL as a graphics API and make it more competitive and make it easier for developers (case in point: the proposed error checking functionality, redundant slower code paths removed, development tools) should be applauded.
0

Share this post


Link to post
Share on other sites
Display lists for state changes haven't proven efficient in practice. Unless all pieces of relevent state for a particular machine unit are included, it must be treated as a state transition which kills potential optimizations. Even if all relevent state is included when the application is written, what happens when that machine unit is extended?

State objects are more interesting, as they included all relevent state by definition, and extensions automagically extend the state object with default state. State objects are dangerous, however. If we partition state incorrectly, it becomes a maintenance nightmare in the long run. Hence you are unlikely to see any generic objects which encapsulate arbitrary state changes, as a display list does today.

Display lists for geometry are still interesting. VBOs encapsulate vertex data only; they do not encapsulate the primitive type or connectivity information, which allows for further optimization. In OpenGL 2.x, changing VBO and vertex array state involves many function calls and incurs a lot of overhead, effectively killing small batch performance. Display lists win hands down for small batch sizes. We are looking to fix this in 3.0 with vertex array objects, but we still see room for display lists as well, including some new uses which I am not prepared to discuss at this time. :)
0

Share this post


Link to post
Share on other sites
Well, we will be looking forward to more announcements, that's for sure [smile]!
0

Share this post


Link to post
Share on other sites
OMG, FP depthbuffers! I am assuming this should allow for a nicer looking shadowmap? NO? with a new internal texture format 32bit also. After reading the new slides BRING on the GL3.0v. WOOT can't wait now. [grin]
0

Share this post


Link to post
Share on other sites
I can't wait for OpenGL 3.0, but really, should we really trash the bind/unbind system? I definitely like the idea of replacing the indexes with pointers (for say texture objects) but i'm not entirely sure I agree with the direct3d style of(virtually, everything, in, the, entire, state, is, a, parameter, for, the, draw, function)
0

Share this post


Link to post
Share on other sites
Nobody said draw functions will take a large number of parameters - this is pure speculation and is definitely not my vision.

We are removing bind-to-edit, not all forms of binding.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0

  • Similar Content

    • By recp
      Hi,
      I'm working on new asset importer (https://github.com/recp/assetkit) based on COLLADA specs, the question is not about COLLADA directly
      also I'm working on a new renderer to render (https://github.com/recp/libgk) imported document.
      In the future I'll spend more time on this renderer of course, currently rendering imported (implemented parts) is enough for me
      assetkit imports COLLADA document (it will support glTF too),
      importing scene, geometries, effects/materials, 2d textures and rendering them seems working
      My actual confusion is about shaders. COLLADA has COMMON profile and GLSL... profiles,
      GLSL profile provides shaders for effects so I don't need to wory about them just compile, link, group them before render

      The problem occours in COMMON profile because I need to write shaders,
      Actually I wrote them for basic matrials and another version for 2d texture
      I would like to create multiple program but I am not sure how to split this this shader into smaller ones,

      Basic material version (only colors):
      https://github.com/recp/libgk/blob/master/src/default/shader/gk_default.frag
      Texture version:
      https://gist.github.com/recp/b0368c74c35d9d6912f524624bfbf5a3
      I used subroutines to bind materials, actually I liked it,
      In scene graph every node can have different program, and it switches between them if parentNode->program != node->program
      (I'll do scene graph optimizations e.g.  view frustum culling, grouping shaders... later)

      I'm going to implement transparency but I'm considering to create separate shaders,
      because default shader is going to be branching hell
      I can't generate shader for every node because I don't know how many node can be exist, there is no limit.
      I don't know how to write a good uber-shader for different cases:

      Here material struct:
      struct Material { ColorOrTexture emission; ColorOrTexture ambient; ColorOrTexture specular; ColorOrTexture reflective; ColorOrTexture transparent; ColorOrTexture diffuse; float shininess; float reflectivEyety; float transparency; float indexOfRefraction; }; ColorOrTexture could be color or 2d texture, if there would be single colorOrTex then I could split into two programs,
      Also I'm going to implement transparency, I am not sure how many program that I needed

      I'm considering to maintain a few default shaders for COMMON profile,
      1-no-texture, 2-one of colorOrTexture contains texture, 3-........

      Any advices in general or about how to optimize/split (if I need) these shaders which I provied as link?
      What do you think the shaders I wrote, I would like to write them without branching if posible,
      I hope I don't need to write 50+ or 100+ shaders, and 100+ default programs

      PS: These default shaders should render any document, they are not specific, they are general purpose...
             I'm compiling and linking default shaders when app launched

      Thanks
    • By CircleOfLight97
      Hi guys,
      I would like to contribute to a game project as a developer (open source possibly). I have some experiences in C/C++ in game development (perso projects). I don't know either unreal or unity but I have some knowledges in opengl, glsl and shading theory as I had some courses at university regarding to that. I have some knowledges in maths and basic in physics. I know a little how to use blender to do modelling, texturing and simple game assets (no characters, no animation no skinning/rigging). I have no game preferences but I like aventure game, dungeon crawler, platformers, randomly generated things. I know these kind of projects involve a lot of time and I'd be really to work on it but if there are no cleary defined specific design goals/stories/gameplay mechanics I would like to not be part of it x) and I would rather prefer a smaller but well defined project to work on that a huge and not 'finishable' one.
      CircleOfLight97
    • By gamesthatcouldbeworse
      Hi, I finally released KILL COMMANDO on gamejolt for free. It is a retro-funsplatter-shooter with C64 style. Give it a try.
    • By phil67rpg

      void TimerFunction(int value) {  glutPostRedisplay();  glutTimerFunc(1000, TimerFunction, 1); } void drawScene() {  glClear(GL_COLOR_BUFFER_BIT);      drawScene_bug();  TimerFunction(1);  eraseScene_bug(); // drawScene_bug_two(); // eraseScene_bug_two(); drawScene_ship(); drawScene_bullet();  glutSwapBuffers(); }