Jump to content
  • Advertisement
Sign in to follow this  
Cypher19

More than 4 vertex/texture components when doing R2VB?

This topic is 4610 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So, I read over the R2VB Programming Guide in the recent version of the ATi SDK, and one restriction that ruffles my feathers a bit is the limitation of only 4 vertex components available for when rendering objects. I was wondering, since the rendering going on is just like a render to a texture, does anyone know if it would be possible to expand the 4 components to 8 or more by using stippling (or a mimick of)? For example, since the R2VB target is treated sequentially, and every 4 floats is supposed to be an individual vertex, with the vertex stream stride being set to 4 floats, what if the stride was set to 8 floats, with a new vertex being started every 2 "pixels" in the render target? Assuming this can be done, does anyone have any ideas as to how to do it? Right now I'm thinking one of a few things:
  1. Having a very rectangular texture, e.g. 2x256 or whatever, and drawing a line that covers the first column with a certain shader to generate, say, vert positions. And then drawing a second line that covers the second column with a different shader to generate vert normals.
  2. Bind a 2x2 stipple texture (i.e. in a checkerboard layout or something) for alpha testing, and when rendering the vertices to be used for rendering to the VB, have texture coordinates attached to those verts so that the stipple texture wraps, repeating again and again s.t. every other "pixel" in the VB render target is skipped, and re-render those vertices again with seperate shaders and an offset on the texture coordinate in order to generate more component data.
  3. Use a method similar to above, but do some branching in the shader code with texkill/clip() or something.
So, thoughts? (btw, if people feel that the language is too ambiguous, just let me know and I can try to explain it a bit more carefully).

Share this post


Link to post
Share on other sites
Advertisement
I was recently contemplating a similar thing as part of an unrelated algorithm [smile]

The two possibilities that I settled on (but haven't had time to implement) were thus:

1. Use some sort of reference texture - similar to your checkerboard idea I suppose. Read this in, and multiply the result accordingly:

float reference = tex2D( ... ).a;
float ValueIfTrue = ...;
float ValueIfFalse = ...;
return ValueIfTrue * a + ValueIfFalse * ( 1 - a );


Thus if the alpha value were either 0.0 or 1.0 you'd get either result. Effectively the same as how dynamic branching is simulated by the HLSL compiler.

2. Use arithmetic to determine odd and even pixels. If the reciprocal height/width of the target is passed in as a constant then you can decode the integer pixel value for the current invocation. Simulating a modulus operator using floor() and ceil() type operations (I don't have the exact workings to hand) should reveal if it's an odd/even pixel and you can then process accordingly..

Whether either of those would work for R2VB I don't know - I've not got the hardware for it so I can't try it out.

hth
Jack

Share this post


Link to post
Share on other sites
I'd like to throw another idea into the mix.

Have the texture Jack suggested, but use it to set the stencil buffer. Then draw to times with different shaders and the two different stencil values.

If you keep that stencil buffer aside and don't clear it, you should be able to reuse it, and then you could create it once. The rendering itself will be faster, since the stencil check happens before the shader.

By setting several values into the stencil it should be possible to extend this to more components without significant overhead.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!