I don’t think, the fact, that you COULD do terrain rendering differently is a valid argument against a feature, for which terrain-rendering was ONE example, that it could improve.
And no one is claiming that it is. Only that this particular use seems specious.
flavious:
I think there are better ways to render terrains on modern graphics cards, especially the NV40+ hardware, like clip-mapping…
Perhaps. But it’s patented by Microsoft. What are the terms/cost of using this algorithm?
Korval: My post wasn’t a reply to yours, it was more directed at flavious.
When someone asks for an example-use for a feature, then you can’t dismiss the feature, only because the example might not be perfect.
That’s what i wanted to point out.
Jan.
When someone asks for an example-use for a feature, then you can’t dismiss the feature, only because the example might not be perfect.
That’s what i wanted to point out.
But noone is dismissing the feature. Not Flavious, not me, nobody.
It seems perfectly reasonable, and in fact looks weird without it, to say “the part of the currently bound vertex buffer my indices refer to is this”.
At the moment, my renderer has to manually walk the indices offsetting them, but only if the draw device is OpenGL and not D3D. So I’m actually changing the mesh data in my database because of what can only be described as a limitation in OpenGL. There is no other part in my system where I have to do this.
If you’re refactoring the GL API then I cannot for the life of me see why you would not add this required parameter…for parameter is all it is if you’re rewriting the whole drawing API.
Couldn’t have said it better knackered.
I get the feeling this is like pissing in the wind though, soconne. Lots of active and experienced developers put forward an extensive, well supported and reasoned argument, and what do you get?
At the moment, my renderer has to manually walk the indices offsetting them, but only if the draw device is OpenGL and not D3D.
Why can’t you just resend calls to glVertexPointer(), glColorPointer(), etc, offsetting them by the required index offset?
You don’t have to walk through the index list this way.
Efficiency, bob, efficiency and performance. Have you tried reading the discussions there has already been on this subject? They’re even linked to via this thread…your question is answered in much greater detail there.
Or are you just trying to be funny?
Have you tried reading the discussions there has already been on this subject? They’re even linked to via this thread…your question is answered in much greater detail there.
Or are you just trying to be funny?
I apologies if I have mistakenly given you the impression that I have read every thread on this board in the last 2.5 years, and every post in all those threads.
I will definitely attempt to be more omnipresent next time.
Efficiency, bob, efficiency and performance.
I understand it saves you a few lines of code, but does it really improve performance? Have you measured it? What is the actual cost of calling glVertexPointer() on a VBO?
The threads that were linked to above don’t seem to answer that. There’s only some vague allusion to some unspecified document that apparently says to not do that.
The threads that were linked to above don’t seem to answer that.
Hey, you can’t ask people to prove that a feature is needed before demanding it! It’s in D3D, so it’s worthy of GL inclusion a priori.
[ /sarcasm ]
Kidding aside, there is some legitimate question as to whether it would be a performance gain or just a waste of the ARB’s time. The only way to be sure would be if the IHVs from the various companies came out and said if gl*Pointer readjustment calls are significant performance sinks or not.
Personally, considering the small nature of the feature, and the fact that hardware (or something) must support it since D3D does, I’d just prefer they expose it and be done with it.
I wonder if all these new extensions are going to be well documented ( + examples of use ) in the future Khronos OpenSDK!
Originally posted by Korval:
[b] [quote]The threads that were linked to above don’t seem to answer that.
Hey, you can’t ask people to prove that a feature is needed before demanding it! It’s in D3D, so it’s worthy of GL inclusion a priori.
[ /sarcasm ]
Kidding aside, there is some legitimate question as to whether it would be a performance gain or just a waste of the ARB’s time. The only way to be sure would be if the IHVs from the various companies came out and said if gl*Pointer readjustment calls are significant performance sinks or not.
Personally, considering the small nature of the feature, and the fact that hardware (or something) must support it since D3D does, I’d just prefer they expose it and be done with it. [/b][/QUOTE]Actually the performance gain comes from moving the calculations from the CPU to the GPU. If you read my post about the terrain rendering example you’ll see that. Plus the cost of moving the offsetting of indices to the GPU costs virtually nothing since each would be offset by a constant value.
Originally posted by al_bob:
[b] I apologies if I have mistakenly given you the impression that I have read every thread on this board in the last 2.5 years, and every post in all those threads.
I will definitely attempt to be more omnipresent next time.[/b]
I expect you to have read the thread you are commenting on. Is that really too much to ask, bob?
The original post mentioned a “GL_EXT_ycbcr_422” extension. I don’t see that one listed anywhere in nVidia’s documents or header files.
Does anyone know about it? We would love to have a component video texture format and not have to write ugly shaders and lie about image sizes. The cards all have built-in hardware to do RGB<->YUV conversions. We’d just like it exposed in OpenGL.
Thanks,
- LoopinFool