Feature Request: For ofShader Add UBO (Uniform Buffer Object)

[yty]

http://www.opengl.org/registry/specs/ARB/uniform_buffer_object.txt
http://www.opengl.org/wiki/Uniform_Buffer_Object

for example:

enum _ofUboDataType { OF_UBO_DATA_TYPE_INT, OF_UBO_DATA_TYPE_FLOAT, OF_UBO_DATA_TYPE_INT_ARRAY, OF_UBO_DATA_TYPE_FLOAT_ARRAY, OF_UBO_DATA_TYPE_2INT_ARRAY, OF_UBO_DATA_TYPE_2FLOAT_ARRAY, OF_UBO_DATA_TYPE_3INT_ARRAY, OF_UBO_DATA_TYPE_3FLOAT_ARRAY, };

ofShader::setUBO()

[Ahbee]

I added created an addon for Ubos. https://github.com/Ahbee/ofxUbo . It automatically queries layouts from GLSL and uploads,but you can also manually pad. Please let me know if a structure is not being uploaded correctly. I will take a look at. I could also use help porting examples to other platforms, right know it is just mac osx. Any help would be appreciated thanks.

[admsyn]

Just taking a look at ofxUbo right now, @Ahbee. It's working great for me on OSX 10.9. Very nice examples too, btw.

[tgfrerer]

excited about this - will give it a test run on windows come Monday =)

UBOs could be a great & clean way to define the "built-in" shader uniforms we are currently handling under the hood in the programmable gl renderer. It could also make it a bit easier to hande custom & built-in uniform locations side-by side in a more self-evident code base. what do you think @arturoc?

Cheers #

T

On 16 Mar 2014, at 22:10, Ahbee notifications@github.com wrote:

I added created an addon for Ubos. https://github.com/Ahbee/ofxUbo . It automatically queries layouts from GLSL and uploads,but you can also manually pad. Please let me know if a structure is not being uploaded correctly. I will take a look at. I could also use help porting examples to other platforms, right know it is just mac osx. Any help would be appreciated thanks.

— Reply to this email directly or view it on GitHub.

[julapy]

wow, that is such a nice way of passing data in shaders. great work on the addon.

On 17 Mar 2014, at 9:22 am, Tim Gfrerer notifications@github.com wrote:

excited about this - will give it a test run on windows come Monday =)

UBOs could be a great & clean way to define the "built-in" shader uniforms we are currently handling under the hood in the programmable gl renderer. It could also make it a bit easier to hande custom & built-in uniform locations side-by side in a more self-evident code base. what do you think @arturoc?

Cheers

T

On 16 Mar 2014, at 22:10, Ahbee notifications@github.com wrote:

I added created an addon for Ubos. https://github.com/Ahbee/ofxUbo . It automatically queries layouts from GLSL and uploads,but you can also manually pad. Please let me know if a structure is not being uploaded correctly. I will take a look at. I could also use help porting examples to other platforms, right know it is just mac osx. Any help would be appreciated thanks.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub.

[Ahbee]

Sorry about that guys. I was accidentally adding the complied examples to the git repo. I removed them and added them to the git-ignore. Download time should be a lot faster now. I also fixed a bug with the manual padding. @tgfrerer did you manage to get it to work on windows?

[tgfrerer]

@Ahbee yes i did! what a beautiful example =)

(the missing border is courtesy of some custom GLFW Window code, so nothing to worry about)

It took me a little bit of fiddling to get it to run on VS2012 / Windows, mainly because of dynamic c-style arrays, which are, i believe, something XCode is a bit laxer with.

I've sent you a PR that uses vectors instead, this should work on linux, too.

Cheers

T

oh, and one other thing: the examples use testApp.cpp + testApp.h for the example projects, it would be nice to have these ofApp.cpp & ofApp.h (as is the new naming scheme from oF 0.8.0 onwards), so that the projectGenerator can generate the project files with the right links automatically.

[Ahbee]

@tgfrerer. I will merge your commit. but there is still one more problem. The order of the uniforms is not correct. Looking at the flower, the parameters do not match the image. I think I can fix this by sorting the uniforms based on their offset value. . I assumed opengl retrieves uniforms in the order they are listed in GLSL. But lookng at your output I guess thats not true.When you call shader.printLayout("SwirlSettings") on my computer it prints in this order

Block Name: SwirlSettings
Layout Size: 16
    SwirlSettings.center
        GL_FLOAT_VEC2
        offset: 0
        size: 8
        array Stride: 0
        matrix Stride: 0
    SwirlSettings.radius
        GL_FLOAT
        offset: 8
        size: 4
        array Stride: 0
        matrix Stride: 0
    SwirlSettings.angle
        GL_FLOAT
        offset: 12
        size: 4
        array Stride: 0
        matrix Stride: 0

I am working on a fix ,I'll let you know when you can retest. Thank so much for your help!

[tgfrerer]

OpenGL (or better the driver) might reorder stuff around in order to optimise as best as possible...

There is some info on page 65 ff. in the latest ed. of the OpenGL programming guide about glgetuniformindices() & glgetactiveuniformsiv() to get offset and size for particular indices, maybe that's helpful?

sent on a touhc device

On 17 Mar 2014, at 23:36, Ahbee notifications@github.com wrote:

@tgfrerer. I will merge your commit. but there is still one more problem. The order of the uniforms is not correct. Looking at the flower, the parameters do not match the image. I think I can fix this by sorting the uniforms based on their offset value. . I assumed opengl retrieves uniforms in the order they are listed in GLSL. But lookng at your output I guess thats not true.When you call shader.printLayout("SwirlSettings") on my computer it prints in this order

Block Name: SwirlSettings Layout Size: 16 SwirlSettings.center GL_FLOAT_VEC2 offset: 0 size: 8 array Stride: 0 matrix Stride: 0 SwirlSettings.radius GL_FLOAT offset: 8 size: 4 array Stride: 0 matrix Stride: 0 SwirlSettings.angle GL_FLOAT offset: 12 size: 4 array Stride: 0 matrix Stride: 0 I am working on a fix ,I'll let you know when you can retest. Thank so much for your help!

— Reply to this email directly or view it on GitHub.

[Ahbee]

@tgfrerer can you try the example again. I made some changes to the shaders as well. Also if you don't mind is it possible for you to test the lights example for windows. But if that's not possible,can you send me a pull request to with the Swirl example. Just create a new directory at the same level as the other examples and call it "example_BasicUsageVS".

[tgfrerer]

Hey @Ahbee , that worked beautifully !

I'm sending you a PR with the windows specific project files, and testApp renamed ofApp - you might have to udpate the os x project files using the project generator, tho.

One detail: in the light shader example you're updating the shaders in the update() function - that has tripped me up in the past, too - but since you're using the easycam and easycam does some tweening of its own in the background its possible that the camera matrices get changed by ofEasyCam internally due to the tweening when the renderer finally reaches draw() - and so the lights might be calculated with slightly "older" and thus slightly off positions.

if you calculate your lights & any other values you pass to your shader in draw() you can be sure to be using the same matrices.

keep up the good work =) ! cheers

T