Any word on ANY render to texture spec?!

I am trying to do some stuff with shadow maps and I’am tired of the pbuffer crap. :mad:

Where the heck is super buffer and EXT_render_target?! We haven’t heard anything from EXT_render_target and it has been almost 5 months and then I read that super buffers may be left out because there is almost no hardware support.

EXT_render_target started good with a lot of discussion, but then nothing more from it. Is it dead? Is it ready? Is it out on vacation? What?

I am really tired of waiting! :mad:
We don’t even have any news or info regarding both extensions, so I can wait 1, 2, 3 or 9 more months (nobody knows) for a simple thing like this?

If there is no solution until the end of the year, tell us (so I might start porting to D3D).

To ATI and NVIDIA people out here: any news?!

(and sorry to create a thread mostly to complain, but anyone can join in… :smiley: )

joined…

Me too !

I’m in to get not only news but at the very least an EXT, would prefer an ARB though.

Same here, i’m definitelly waiting for this extension, some news would be good to hear :wink:

I want it too. Todays engines use image compositing rendering approach and good RTT is necessary for that. PBuffers are good but not enough. For example I need to share depth buffer between main backbuffer and some PBuffer. MRT can help but MTR is just a set of backbuffers (not textures!).

@KRONOS

I hear some rumors about RTT in D3D. RTT in D3D are slower than pbuffers! So stick to GL. :slight_smile:

yooyo

We’re working on it. Just like with a Carmack game, it will be ready when it’s ready. :slight_smile: If you think about it, we’re making a pretty significant change to the way OpenGL works. It would really be a shame to botch it up, don’t you think?

Like was said the the OpenGL BoF at SIGGRAPH, pretty much all of the major issues with the current spec have been worked out (finally!), and we’re polishing off the last details. There’s still a few things left, but I can see a light at the end of the tunnel. I’m pretty sure it’s not a train, too.

Originally posted by idr:
Like was said the the OpenGL BoF at SIGGRAPH, pretty much all of the major issues with the current spec have been worked out (finally!), and we’re polishing off the last details. There’s still a few things left, but I can see a light at the end of the tunnel. I’m pretty sure it’s not a train, too.
Working on what? Is it the super buffers after all? What about EXT_render_target?! What can we expect?

Can we see a spec? Please… :smiley:

yooyo: are you sure?! :smiley:

They, basically, said that ARB_superbuffers is dead, and that they’re going with render_target (which will now be ARB_render_target).

Can we see a spec? Please…
I imagine it isn’t much too different from what we saw in the preliminary EXT_render_target spec, but obviously a bit more mature. My real question is this.

During the EXT_RT discussions, a lot was made of making this extension very restrictive (buffers needing to be the same size, etc), and building on top of it to allow for hardware that can loosen the restrictions. Also, a lot was made on having another extension based on EXT_RT to allow for render-to-vertex-array-esque functionality. Are either of those fronts progressing, and will they be available when ARB_RT comes out?

Well seeing as though you can now sample a texture in a vertex shader a render-to-vertex-array extension is kind of redundant, don’t you think?

Seconded. I’d prefer a {EXT|ARB}_render_target. Superbuffers would be amazingly cool, but it’s not as urgent. And I understand that it’s a very complex approach to tackle. Complete overkill for the real issue at hand (which is, of course, elegant R2T).

Originally posted by yooyo:
[b]I hear some rumors about RTT in D3D. RTT in D3D are slower than pbuffers! So stick to GL. :slight_smile:

yooyo[/b]
I doubt it.
Whatever you saw may have been the usual batching overhead disadvantage of DirectX Graphics, but I very much doubt that R2T itself is inefficient compared to the song-and-dance that OpenGL requires.

PBuffers for R2T are a complete mess. Because they exist in a different rendering context, you get all the context management overhead. Namely context switching and object sharing.

Now this obviously works, but it’s by no means easy to do nor efficient. That’s a lot of driver complexity and it also presents a lot of opportunities to developers for shooting themselves in the foot, especially to the more inexperienced folk.

PBuffers work for R2T at all because they piggy-back on infrastructure that was designed to support multi-threaded, multi-view modeler/editor-type applications. This infrastructure was certainly never meant to be used in this way.

OpenGL is quite easy to get started with in a number of ways. But that just doesn’t apply to developers who want R2T functionality.

Originally posted by knackered:
Well seeing as though you can now sample a texture in a vertex shader a render-to-vertex-array extension is kind of redundant, don’t you think?
Not quite.
a)Pulling a vertex attribute is faster by an order of magnitude than sampling a vertex texture

b)Vertex textures are not (yet) widely supported, and aren’t cross-vendor portable. Rendering to floating point buffers is much better in these respects.

A lousy and near-obsolete Radeon 9600SE could do render-to-vertex-array, if you could just rebind a render target as a VBO …

Here too! I’m waiting all day for news about this topic… :wink:

Originally posted by zeckensack:
[b] [quote]Originally posted by yooyo:
[qb]I hear some rumors about RTT in D3D. RTT in D3D are slower than pbuffers! So stick to GL. :slight_smile:

yooyo[/b]
I doubt it.
Whatever you saw may have been the usual batching overhead disadvantage of DirectX Graphics, but I very much doubt that R2T itself is inefficient compared to the song-and-dance that OpenGL requires.
[/QUOTE]I have to explain my post a bit better…
I was read somewhere (Im not sure where) that setting render targer in D3D are slower than context switching between pbuffer and main rc.

yooyo

@Yooyo

Can you elaborate on this topic a bit more in detail? Maybe even find the post you are referring to? Are you sure that its the general case and not just a vendor limitation?

@KRONOS

Sign me up for the list too.

There´s absolutely nothing, i am waiting for, more impatiently.

Like everyone else, I’d like some news too.

At the Siggraph OpenGL BOF I remember hearing about 2 things: EXT_framebuffer_object, which they said is intended to simplify RTT, and uber buffers. Some news or comments on either of these would be nice…

Add me to the list. I’m desperate for this feature too.

According to John Carmack (in his QuakeCon video), Ati and nVidia are arguing over “stupid, petty little things” when it comes to render to texture which I am assuming is the EXT_render_target spec.

He also describes the pbuffer API as “God awful” and using it was the closest he came to dropping OpenGL and switching to D3D.

Matt

PBuffers are ugly. EXT_render_target is a very elegant extension and I hope it is implemented soon.