32 replies to this topic

[CyraX]

With nVidia and ATI competing with each other, things have been going smooth for most of the game developers who are being thrown more processing power to use. As usual the developers swallow it whole.
Now the question is what do you think is still missing in OpenGL?
What might be added to it in order to really pack some punch.
Lighting is one of the areas where beter support could be expected.

[baldurk]

High level shading language, better extension system perhaps.

[godEcho]

standarization (and inclusion) of common opengl extensions would be nice.

[baldurk]

how about kicking MS off the ARB. What's up with that??

[davepermen]

who cares about microsoft in there..


what i want is a programable blending unit with floatingpoint precicion.. and branches in the pixel unit..

then i can finally raytrace..:D

[Morgoth]

Some true arithmetic for controlling buffers...perhaps?
Take a look at shadow volume techniques (Doom3 anyone?) and i think you'll aggree that the stencil buffer is WAY TOO inflexible!

[MMU_FOX]

I hope can directly to load object to 3d world....like direct x can load object -> .x ......load image..... :blink:

[baldurk]

well, as far as I can tell, that is actually isn't DirectX. It's the "helper" library.

[davepermen]

yes, its d3dx, a (quite handy) helper library..

though, there isn't a real good helper library to load arbitary meshes in gl yet.. there is devIL, great for textures.. but meshes?..

[donBerto]

Quote

I hope can directly to load object to 3d world....like direct x can load object -> .x ......load image.....

i think i know where you're getting at. I don't know if directx has built-in support for different image types but one can easily make their own. like what baldurk said:

Quote

well, as far as I can tell, that is actually isn't DirectX. It's the "helper" library.

as far as what I would like to see in the next OGL, if at all possible, an even faster pipeline [hardware issue?] and maybe better handling of some functions if at all possible. for example, initializing display lists requires that there be an active rendering context. i think it would be nice if it didn't have to but maybe they have their reasons.

[baldurk]

I don't really think you need one. Loading some of the simpler model formats is pretty damn easy. If you can't manage that, you can always use your own format.

[davepermen]

donBerto said:

as far as what I would like to see in the next OGL, if at all possible, an even faster pipeline [hardware issue?] and maybe better handling of some functions if at all possible. for example, initializing display lists requires that there be an active rendering context. i think it would be nice if it didn't have to but maybe they have their reasons.

hm.. the way it is does make sence if you know a bit of hw..

and what about the pipeline, what is slow about it (except some vendors who design some rather bugs into the pipeline, like nvidia did (and possibly still does:D))

[baldurk]

I think you need an active rendering context because the data that it compiles is saved with the rendering context. Like texture stuff. Am I wrong?

[davepermen]

nope, you're right. espencially display lists get partially stored into video mem. and only a valid gl context does have access to video mem.

[donBerto]

Quote

and what about the pipeline, what is slow about it (except some vendors who design some rather bugs into the pipeline, like nvidia did (and possibly still does:D))

i just meant that maybe there's a way to make it faster. i'm not complaining - it's pretty fast now. I guess i'm just trying to push the envelope.

and back to helper libraries:

Quote

I don't really think you need one. Loading some of the simpler model formats is pretty damn easy. If you can't manage that, you can always use your own format.

i think the point baldurk is trying to make is that helper libraries are nice. they make things easy, if not simple [never confuse the two]. but as far as having it built-in, maybe it's not necessary. the last thing you want to do is be forced to use a built-in mechanism especially if you have something against it. an example is my not-so-favorite .bmp format. if OpenGL made it so that bmp file format was built-in, i'd feel obliged to use it. sure i could use other file formats but keeping in mind that it's built in, it may have low-level code [getting at close-hardware support, making it possibly faster] and having or using a high-level user-made file format may not be as fast...

i wouldn't be surprised if directx had built-in support for bmp. after all, wasn't bmp "founded" by an ms-developer?

anyway, i didn't mean any flame-mongering comments. and sorry for my heavy use of quotes ;7

[baldurk]

I reckon I could probably get better performance by writing my own <whatever> loader than using a helper library. That's because a helper library is a layer on top of the actual API. Also, because I'd learn a lot more that way

[davepermen]

dx doesn't have builtin support for loading anything.

but there is d3dx, wich comes with the sdk, wich provides helper funcs. it provides funcs to load textures from files, in different formats. mainly i think jpg, tga, bmp, and possibly some others.. don't really remember..


and yes, worst would be to be forced to something..

[donBerto]

Quote

and only a valid gl context does have access to video mem.

that makes sense. I still think it would be cool if there was a decent, ethical work-around so you can put things into video memory without the context for faster loading without looking at a blank or still screen. bleh - i don't even care. :lol:

[donBerto]

Quote

I reckon I could probably get better performance by writing my own <whatever> loader than using a helper library. That's because a helper library is a layer on top of the actual API. Also, because I'd learn a lot more that way

the best way to go about it.

'nuff said.

[davepermen]

performance is not important, its the last step..

and you would code the same a library would do for you. you code a layer above gl, too..

and loading meshes does not have to do anything with gl anyways.. its about fileformats and all..