ShaderState with GLArrayDataClient and GLArrayDataServer explaining

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ShaderState with GLArrayDataClient and GLArrayDataServer explaining

kles4enko
Please, explain next points:
1. How to use ShaderState with GLArrayDataClient ?
2. How to use ShaderState with GLArrayDataServer ?
3. When used GLArrayDataServer and when used GLArrayDataClient, differences ?

Thank you!
Reply | Threaded
Open this post in threaded view
|

Re: ShaderState with GLArrayDataClient and GLArrayDataServer explaining

Sven Gothel
Administrator
On 02/20/2015 04:17 PM, kles4enko [via jogamp] wrote:
> Please, explain next points:
> 1. How to use ShaderState with GLArrayDataClient ?
> 2. How to use ShaderState with GLArrayDataServer ?
> 3. When used GLArrayDataServer and when used GLArrayDataClient, differences ?

Please read the unit test's demo code,
e.g. RedSquareES2, GearsES2, ..
and the API documentation.

All in jogl git repo ..

Related
  <http://forum.jogamp.org/Shader-utilities-td4033981.html#a4033985>

>
> Thank you!

Hope it helps.

~Sven



signature.asc (828 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: ShaderState with GLArrayDataClient and GLArrayDataServer explaining

kles4enko
Thank you!
Did not find needed tests.
Reply | Threaded
Open this post in threaded view
|

Re: ShaderState with GLArrayDataClient and GLArrayDataServer explaining

jedwards1211
This post was updated on .
In reply to this post by Sven Gothel
Sven,

I read through RedSquareES2.

The main thing that's not clear to me about the design is that you can associate buffers, uniforms, etc. with ShaderState, yet you still have to call st.uniform() in your draw code, as well as enableBuffer() on each buffer.  ShaderState already contains all the bindings, so couldn't it perform all of those things in one fell swoop?

Also, those demos don't really demonstrate data sharing as far as I can tell.  To share a vertex array with a different ShaderState and different variable name, I assume I do something like this?

GLArrayDataServer data = ...
GLArrayDataServer dataCopy = new GLArrayDataServer(data);
dataCopy.setName("otherName");
ShaderState otherState = new ShaderState();
otherState.ownAttribute(dataCopy, true);

Also, this brings up a seeming problem -- if `otherState` destroys `dataCopy`, won't that break `data`, since it has the same `vboName` as `dataCopy`?

Storing the shader variable name with GLArrayData, GLUniformData, etc. is what I'm most skeptical of about the design...

Another thing that's not obvious from the examples is why I would use attachShaderProgram() to switch programs on the fly instead of just creating another ShaderState for the other program.