Need assistance using MOAIShader:setVertexAttribute

[joarb]

I'm trying to apply MOAIShader to a MOAIScriptDeck, as described here: http://getmoai.com/forums/shader-for-moaidraw-t758/. So far I'm using nothing but the existing code base. I'm able to apply shaders to primitives by following the gl-shader-attributes sample, replacing the tileDeck with a MOAIScriptDeck, and drawing primitives manually to the prop. (In addition, I had to modify the vertex shader program as described here: problem-running-gl-shader-attributes-sample-t816/).

At one point, I'm a little lost though. I need to input custom vertex attributes to the vertex shader. The gl-shader-attributes sample does the following:

Code: Select all

1. shader:setVertexAttribute ( 1, 'position' )


2. shader:setVertexAttribute ( 2, 'uv' )


3. shader:setVertexAttribute ( 3, 'color' )

To me, it seems as indices 1, 2, and 3 are hard coded into the SDK at some point, since I can't see any place where they are defined. Is this correct? (Does this have anything to do with NVIDIAs supposedly non-conformant usage, as described here: http://www.opengl.org/sdk/docs/tutorials/ClockworkCoders/attributes.php ?)

Second question: is it possible to define custom vertex attributes to be passed into the vertex shader? Is this what MOAIVertexBuffer/MOAIVertexFormat is for? If so, how are they used in the context of MOAIShader? (The gl-vertexBuffer sample only demonstrates usage together with MOAIMesh.)

Any illuminating comments would be greatly appreciated. Thanks!

[adam]

If I'm understanding your question correctly...

The vertex attribute indices only determine the order you will be passing the data in. You can set them to whatever you want, as long as when you 'write' the data, its in that order.

[adam]

additionally, you can add all the custom attributes you want.

[joarb]

Thanks adam. The problem isn't actually the labelling of index 1 as 'position' - this is arbitrary I recon. To improve on the original question phrasing: how is the data describing the vertex position associated with index 1? It seems that something magic is going on behind the curtains ... in fact, gl-vertexBuffer gives away a clue:

Code: Select all

1.  -- Moai's default shaders expect loc, uv, color


2. vertexFormat:declareCoord ( 1, MOAIVertexFormat.GL_FLOAT, 2 )


3. vertexFormat:declareUV ( 2, MOAIVertexFormat.GL_FLOAT, 2 )


4. vertexFormat:declareColor ( 3, MOAIVertexFormat.GL_UNSIGNED_BYTE )


5.  

So in the default shaders, at least, it seems like there is a predefined relationship between index 1 and position data, index 2 and uv data, and index 3 and color data. Is that correct?

For reference, see https://github.com/moai/moai-dev/blob/master/samples/graphics/gl-vertexBuffer/main.lua

[dana]

The index specifies the position of the data in the stream.

So to explain using that sample that you linked...

Code: Select all

1. vertexFormat:declareCoord ( 1, MOAIVertexFormat.GL_FLOAT, 2 )


2. vertexFormat:declareUV ( 2, MOAIVertexFormat.GL_FLOAT, 2 )


3. vertexFormat:declareColor ( 3, MOAIVertexFormat.GL_UNSIGNED_BYTE )

Is saying that the stream is going to be formatted in chunks of 3 numbers and they will be of the order float, float, byte. We know that these numbers are going to be in the order position, uv, color, however the shader does not know yet. All the shader knows is it'll get float, float, byte, it has no idea yet what these numbers represent. We will tell the shader what they represent later.

Because we know what they represent, we can go ahead and put some data into the stream. That's what happens next in the sample, we add 4 vertices, and add the position, uv, and color for each one.

Code: Select all

1. vbo = MOAIVertexBuffer.new ()


2. vbo:setFormat ( vertexFormat )


3. vbo:reserveVerts ( 4 )


4.  


5. vbo:writeFloat ( -64, -64 )


6. vbo:writeFloat ( 0, 1 )


7. vbo:writeColor32 ( 1, 0, 0 )


8.  


9. vbo:writeFloat ( 64, -64 )


10. vbo:writeFloat ( 1, 1 )


11. vbo:writeColor32 ( 1, 1, 0 )


12.  


13. vbo:writeFloat ( 64, 64 )


14. vbo:writeFloat ( 1, 0 )


15. vbo:writeColor32 ( 0, 1, 0 )


16.  


17. vbo:writeFloat ( -64, 64 )


18. vbo:writeFloat ( 0, 0 )


19. vbo:writeColor32 ( 0, 0, 1 )

The shader is happy with these because all the values correspond to the data types that it was expecting to see.

Then a little further down, after we load in the vertex and pixel shaders, you will see the code where we tell the shader what each value in the stream corresponds to.

Code: Select all

1. shader:setVertexAttribute ( 1, 'position' )


2. shader:setVertexAttribute ( 2, 'uv' )


3. shader:setVertexAttribute ( 3, 'color' )

The index numbers themselves aren't so important. I could've done this whole process using index 2 for position, 3 for uv, and 5 for color if I wanted.

I hope this helps you understand a little better and answers your question.

[joarb]

@dana: thank you very much for such a detailed answer! Sorry about the delayed answer; I've been on a short holiday without an internet connection. However, what I did have access to was my OpenGL SuperBible fifth edition. Did some reading up on VBOs, shaders, and vertex attributes, and it all seems quite clear now.

Your answer made perfect sense with my newly obtained knowledge. Thanks!

[joarb]

For those of you who've been interested in applying shaders for primitives and haven't figured out the solution for yourselves yet, I'd like to share with you one way to do it with the existing host. (It's kind of embarrasing that the answer was there all along, but hey - sometimes you just can't see what's right in front of you.)

The answer is not to use MOAIDraw at all to draw the primitives, but rather MOAIMesh and MOAIVertexBuffer to specify the primitive vertices (or coordinates if you like). The following code is based on gl-vertexBuffer sample. All I've done is to remove the texture references (and accompanying uv-attributes) throughout:

Code: Select all

1. MOAISim.openWindow ( "Gradient triangle using VBOs", 320, 480 )


2.  


3. viewport = MOAIViewport.new ( )


4. viewport:setSize ( 320, 480 )


5. viewport:setScale ( 320, 480 )


6.  


7. layer = MOAILayer2D.new ( )


8. layer:setViewport ( viewport )


9. MOAISim.pushRenderPass ( layer )


10.  


11. vertexFormat = MOAIVertexFormat.new ( )


12.  


13. -- Moai's default shaders expect loc, uv, color


14. vertexFormat:declareCoord ( 1, MOAIVertexFormat.GL_FLOAT, 2 )


15. vertexFormat:declareColor ( 2, MOAIVertexFormat.GL_UNSIGNED_BYTE )


16.  


17. vbo = MOAIVertexBuffer.new ( )


18. vbo:setFormat ( vertexFormat )


19. vbo:reserveVerts ( 3 )


20.  


21. vbo:writeFloat ( -64, -64 )


22. vbo:writeColor32 ( 1, 0, 0 )


23.  


24. vbo:writeFloat ( 0, 64 )


25. vbo:writeColor32 ( 0, 1, 0 )


26.  


27. vbo:writeFloat ( 64, -64 )


28. vbo:writeColor32 ( 0, 0, 1 )


29.  


30. vbo:bless ( )


31.  


32. mesh = MOAIMesh.new ( )


33. mesh:setVertexBuffer ( vbo )


34. mesh:setPrimType ( MOAIMesh.GL_TRIANGLE_FAN )


35.  


36. if MOAIGfxDevice.isProgrammable () then


37.  


38.         file = assert ( io.open ( 'shader.vsh', mode ) )


39.         vsh = file:read ( '*all' )


40.         file:close ()


41.  


42.         file = assert ( io.open ( 'shader.fsh', mode ) )


43.         fsh = file:read ( '*all' )


44.         file:close ()


45.  


46.         shader = MOAIShader.new ( )


47.  


48.         shader:reserveUniforms ( 1 )


49.         shader:declareUniform ( 1, 'transform', MOAIShader.UNIFORM_WORLD_VIEW_PROJ )


50.  


51.         shader:setVertexAttribute ( 1, 'position' )


52.         shader:setVertexAttribute ( 2, 'color' )


53.  


54.         shader:load ( vsh, fsh )


55.  


56.         mesh:setShader ( shader )


57. end


58.  


59. prop = MOAIProp2D.new ( )


60. prop:setDeck ( mesh )


61. layer:insertProp ( prop )

The code declares three vertices (or techincally vertex attributes), assigns them with some data and pass them to OpenGL. The vertex shader looks like this:

Code: Select all

1. uniform mat4 transform;


2.  


3. attribute vec4 position;


4. attribute vec4 color;


5.  


6. varying vec4 colorVarying;


7.  


8. void main () {


9.     gl_Position = position * transform;


10.     colorVarying = color;


11. }

and finally the fragment shader like this:

Code: Select all

1. varying LOWP vec4 colorVarying;


2.  


3. uniform sampler2D sampler;


4.  


5. void main() {


6.         gl_FragColor = colorVarying;


7. }

Now, the cool thing with this setup, is that OpenGL will interpolate the "missing" data between the vertices. In other words, gradients are amazingly cheap to create. By supplying more vertices, you can control the gradient pretty much however you'd like. A link that might come in handy when you need to deal with primitives is this: http://www.opengl.org/wiki/Primitives Good luck!

[nosheet]

Thanks @Joarb, great stuff!
I can also easily imagine that with linking uniform vec4 color attribute, and blending colorVarying (vertex color) with an animated uniform attribute (similar to what's done in shader color sample), we can easily have animated tinted gradients!
Fantastic
N

[joarb]

@Nsheet: no problemo! Glad to be of any assistance. And that animated tinted gradient sounds pretty awesome - would be really intriguing to see any results.

[rhoster]

Fantastic example joarb, thanks so much for posting. I'm actually in the process of implementing our UI layer right now and was learning more about OpenGL primitives to draw the boxes. I'll now be adding a gradient feature as well

[joarb]

Always happy to help rhoster! I've been doing the same, although I found myself slightly limited due to the fact that MOAIMesh do not support (yet) support index buffers (http://openglbook.com/the-book/chapter- ... ive-types/). (At least that's how I interpret the first sentence in the docs for MOAIMesh: "Loads a texture and renders the contents of a vertex buffer. Grid drawing not supported.".)

In my experience, drawing buttons using images will still beat drawing using primitives when it comes to visual quality, so I had to settle for that option this time. I've also been tipped about a gui framework by Derick Dong which might be interesting: http://code.google.com/p/moaigui/ (It support images for the buttons, and I'm probably gonna go for his framework myself, contrary to earlier posts.)

[derickdong]

I've also been tipped about a gui framework by Derick Dong which might be interesting: http://code.google.com/p/moaigui/

Just to let you know, I've moved the repository to github, so that it and MOAI are available through the same system. Currently, everything at google code is up to date, but that will probably change in the future. Unfortunately, I can't edit the original post in the forum to update the location. Here is where the most current version will be for the foreseeable future:
https://github.com/derickd/moaigui/downloads

[joarb]

Thanks for the heads up Derick, I'll definitely fetch that repo. And thanks for a great contribution, by the way!

[ibisum]

Both Hanappe and moaigui are terrific frameworks! I'm really learning a lot from these projects .. surprising how inspiring MOAI seems to be, reading both codebases ..