Originally posted by AlexN:
Does the G80 support mixing render target bit depths or multisample modes for multiple render targets?
Yes to render target bit depths and formats. No to multisample modes. I assume by multisample modes, you mean 2x vs. 4x vs. 8x vs. the new CSAA modes.
Originally posted by pbrown:
[quote]Originally posted by AlexN:
Does the G80 support mixing render target bit depths or multisample modes for multiple render targets?
Yes to render target bit depths and formats. No to multisample modes. I assume by multisample modes, you mean 2x vs. 4x vs. 8x vs. the new CSAA modes. [/QUOTE]Thanks, that’s great. I was more concerned about mixing a non-multisampled render target with one that is, but it sounds like that is not possible?
Are updated headers available?
I would like to know also when the glext.h file with the new extensions will be available?
You can download a modified version of GLEW which supports GeForce 8 series OpenGL extensions at:
http://www.clockworkcoders.com/oglsl/
Addendum:
The updated include files are now available at the NVIDIA developer website.
http://developer.nvidia.com/object/nvidia_opengl_specs.html
Thanks!
Does anybody know if this next version of OpenGL will finally support a feature similar to DirectX’s BaseVertexIndex when binding an index array?
For instance if you have an index array {0, 1, 2, 3, 4} and you set BaseVertexIndex = 10, then when sent to the graphics card the vertices {10, 11, 12, 13, 14} are used.
I’ve been waiting soooo long for this to be supported. Hopefully people other than myself find this a must have feature.
Originally posted by soconne:
[b] Does anybody know if this next version of OpenGL will finally support a feature similar to DirectX’s BaseVertexIndex when binding an index array?
For instance if you have an index array {0, 1, 2, 3, 4} and you set BaseVertexIndex = 10, then when sent to the graphics card the vertices {10, 11, 12, 13, 14} are used.
I’ve been waiting soooo long for this to be supported. Hopefully people other than myself find this a must have feature. [/b]
Ditto on that one…
There isn’t a way to write an extension to do what we need is there? Since DirectX already has the functionality, couldn’t a modified OpenGL driver be written which takes advantage of that? I don’t see why it would be difficult for Nvidia or ATI to do it.
Originally posted by soconne:
There isn’t a way to write an extension to do what we need is there? Since DirectX already has the functionality, couldn’t a modified OpenGL driver be written which takes advantage of that? I don’t see why it would be difficult for Nvidia or ATI to do it.
Can either of you guys that “voted” for such a feature offer an example of how it would make life easier for you? It doesn’t seem like it helps much for DrawArrays-style rendering, except maybe allowing for more modular code. For DrawElements, when is it not possible/OK to just factor this base offset into the indices? I can certainly see how something like this could be useful, I’m just not sure how useful.
Such an extension is certainly possible, but besides driver maintenance, there are various other complications: interaction with vertex ID, interaction with restart indices, all the different APIs (DrawArrays, DrawElements, ArrayElement, MultiDraw*). Such an extension would make sense if its value justifies the driver work involved.
If that ability is ever going to be added (which it should) it will be in GL3.0, with the new object model, agreed by the whole ARB, not just nvidia.
Here are the threads that I can remember that talk about this
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=012219
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=014659
http://www.opengl.org/discussion_boards/ubb/ultimatebb.php?ubb=get_topic;f=3;t=012219;p=2#000078
I think it’s rather simple.
The idea is to pack lots of objects into a large VBO.
For example, make 1 large VBO and another large IBO.
Read model #1 from disk, put vertices into VBO, put
indices in IBO.
Read model #2 from disk, put vertices into VBO, put indices in IBO.
Yes, we are using ushort for index.
Indices for model #2 need to be offsetted or we need to make calls to glVertexArray and the other gl****Array
I am offsetting with my own code. It’s not such a big issue, but if the feature is available for D3D, why not GL?
The problem I am having that requires this is my current terrain rendering implementation.
I have a 129x129 terrain page that is only the height values. I store this in one of the vertex attribute arrays. So for a 1025x1025 terrain I would have 16 of these, 8x8.
I then have a 129x129 xz patch that act as x, z coordinates. Inside the vertex shader I grab the appropriate y value from the above attribute array.
I then define several 33x33 patches that make up the 129x129 page. For each 33x33 patch, it indexes into an index buffer containing the correct precomputed indices for whatever LOD level the patch is at.
Currently after choosing the correct indices, I have to manually go through and offset the indice values on the CPU to correctly point to the right vertices in the page. This also prevents me from having the index buffer be stored on the GPU.
But if OpenGL had a BaseVertexIndex extension I could simply specify some offset, in this case 33, and for each 33x33 patch, their indices would automatically be offset to the correct vertex id once they reach the gpu.
And no, you cannot accomplish the same thing by using glVertexPointer. That would assume that your vertex buffers are aligned such that for each 33x33 patch, all its x, y, z values are stored consecutively. So it would be (33x33), (33x33), (33x33)…
But since this is not the case, and the 129x129 vertex buffer is simply stored (129x129) offsetting in glVertexPointer won’t work.
Originally posted by V-man:
[b] Indices for model #2 need to be offsetted or we need to make calls to glVertexArray and the other gl****Array
I am offsetting with my own code. It’s not such a big issue, but if the feature is available for D3D, why not GL? [/b]
Right, it seems that index offsetting is easy enough in such cases that it’s only a minor annoyance. Perhaps a stronger argument might be to allow developers to unify OpenGL and D3D renderers, if they support both. The main argument not to do something like this is that it’s one more code path to implement and verify in the driver, and one more thing that can break.
If we decided to do such an extension, I agree that it would make sense to do this as a multi-vendor extension and/or OpenGL 3.0, schedule permitting.
I then define several 33x33 patches that make up the 129x129 page. For each 33x33 patch, it indexes into an index buffer containing the correct precomputed indices for whatever LOD level the patch is at.
Isn’t that going to create a lot of draw calls? I mean, for each patch, you’ve basically got to make 16 draw calls instead of just one for a patch.
And I know GL’s draw calls are cheaper than D3D’s, but they’re not free. Your indices wouldn’t break the 16-bit boundary, so you wouldn’t need to use ints for them. You’d only lose 15552 * 2, or 31104 bytes; hardly worth mentioning.
In your case, I think it would be better to sacrifice a small quantity of memory than to make over a dozen draw calls like that.
Well I worried about having to refill index buffers for each page every frame. Then for each index buffer as I’m filling it, having to offset the index values. Is this worth it?
I think there are better ways to render terrains on modern graphics cards, especially the NV40+ hardware, like clip-mapping. Clip-mapping allows you to create static vertex/index buffer footprints and use uniforms to scale and translate these tiles while sampling the per-vertex elevation data, all from within the shader. Right now this requires the ability to sample textures in vertex shaders, for best performance, but I would think equivalent functionality (currently only NV40+) should be ubiquitous in the near future. I imagine the situation gets even better with G80+ hardware.
Well I worried about having to refill index buffers for each page every frame.
You wouldn’t have to; you just reuse the index buffer.
Each page lives in a separate buffer object, yes? And the shared X,Z data is in its buffer object, right? So all you should need to do to render a page is to bind the new Y buffer object, along with the color/texture coordinates (assuming the text coords change), and make another draw call.
Or, do what Flavious said, except that you substitute the vertex texture access with simply getting the value from an attribute (the Y buffer object). They’re both the same.
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.
There are things, that could definitely benefit from a base-index.
Also, IMO, geometry clipmaps are not really such a great way to render terrains, they are just ONE way to do it. I don’t know of any real application, that uses the GPU based method, so i don’t think, one can say, that it is better than all the other methods that are successfully used today.
Just my 2 cent, but actually the topic has been discussed to death in the other threads some time ago.
Jan.