Intermediate vertex buffers

Ok I kdont know you but me, when I do mesh skinning I have a problem… Imagine I am using shadow mapping… I need first to render from light view point… so I need to sking the model one time…and when I am rendering from the “real” camera viewpoint I need to re-skin and draw…

So… why not better to use a “vertex shader” to sking the data into “local or global space” and store it in an intermediate buffer that could I reuse it on various renders so I wont need to skin TWICE the char model?

Imagine:

  1. Skin the model. V = tm*weight[bone1]local.pos + tmweight[bone2], blah blah…

  2. Render from light point: Vhclip = tm*IntermedVB.V

  3. Render from camera: VHclip = tm*IntermedVB.V

ps: I am not sure if I can use the compiled vertex arrys for this…

[This message has been edited by santyhammer (edited 02-28-2004).]

Essentially you’re asking for render-to-vertex-buffer (as opposed to render-to-texture) functionality. The uberbuffers proposal (mentioned on the previous ARB meeting minutes) should support this nicely.

Aye aye, “render to vertex buffer”, that’s it. Was already proposed? Basically I mean a dx->ProcessVertices but done by HW …

[This message has been edited by santyhammer (edited 03-17-2004).]

Aye aye, “render to vertex buffer”, that’s it. Was already proposed

This is the kind of thing Zeckensack was talking about in the other thread. You aren’t paying attention to what is already coming down the ARB pipe. You don’t know what should or should not be an OpenGL feature. Which is why the vast majority of your posts here are not helpful, and only contributes to the noise on this forum.

Well… sorry if was already proposed but can’t see nothing realated to this in ogl2x suggestions, neither in the whole OGL web… perhaps i am blind… Pls, can you LINK me where was proposed? Can’t find anything about “uberbuffers”…

You might look for ‘superbuffers’ as well. It’s another name for…uh…it’s a long story.

[ul][] December 2003 ARB Meeting minutes []September 2003 ARB Meeting minutes, part 1 and part 2 [*] March 2003 ARB Meeting Minutes [/ul]

thx idr!

But that is NOT what i am proposing really… I want a function like dx9->ProcessVertices, but in hw and with support for display lists too… Current VBO/PBO model only works with a reduced set of vertex arrays …

Originally posted by santyhammer:
[b]thx idr!

But that is NOT what i am proposing really… I want a function like dx9->ProcessVertices, but in hw and with support for display lists too… Current VBO/PBO model only works with a reduced set of vertex arrays …[/b]
Yes… You are right… We need way to disable resterizing primitives… It can be done using glFeedbackBuffer call, but without specifying type and pointer can/should be a VBO. Implementation should process all vertices between glBegin() and glEnd() call, using fixed function pipeline or vertex program and put processed vertices to out buffer. Maybe, add new funcion, and app must provide sizeof outcoming vertex (because vertex program can calculate additional vertex attributes).

yooyo

Yes… You are right… We need way to disable resterizing primitives… It can be done using glFeedbackBuffer call, but without specifying type and pointer can/should be a VBO. Implementation should process all vertices between glBegin() and glEnd() call, using fixed function pipeline or vertex program and put processed vertices to out buffer. Maybe, add new funcion, and app must provide sizeof outcoming vertex (because vertex program can calculate additional vertex attributes).

And one more bit… Can be possible to VBO have additional attribute for example GL_SOURCE and GL_DESTINATION, so we can bind at the same time one source and one destination VBO.

yooyo