On 02/02/2015 04:44 PM, blizzard [via jogamp] wrote:
> Hello again
>
> sorry about my base level questions Iḿ still searching for the best way to go :-)
It usually depends on your application and goals.
For example, there was a short discussion about PMVMatrix/FloatUtil/etc
and as it was mentioned it is high performance and efficient
it may not offer a convenient OO style API.
The latter usually goes w/ extra costs in memory footprint
and disability of handling stream data etc.
Everybody there own tool :)
>
> Are the ShaderCode and ShaderState classes the recommended way to handle
> shaders for the future ?
First, it will be future proof, since we use it all over the place
in our unit tests.
It is also used in customer applications, as well as internally in JOGL.
The one backside of ShaderState is its management overhead,
hence if you have a very well known application and shader state
you may want to manage it on your own. That is: shader program switching
and uniform data updating, etc.
I for one, start w/ using ShaderState and then maybe handle the transitions
'myself' more efficiently based on the application logic.
One example of this process was the removal of ShaderState usage in 'graph'.
>
> I want to use GL 3.3
The shader utils work well for all supported platforms and profiles, ofc.
ShaderCode also helps dealing w/ differences of the GLSL of each GL profile,
have a look at our demo code, e.g. GearsES2.
Here it supports and helps to:
- load shader code across platforms (from jar or apk file, ..)
- puts the proper qualifiers / statements into the code,
reflecting the used GLSL version - etc.
In short:
- Read the code
- Understand
- Decide
~Sven
>
> thanks