Unsupported warnings setting USE_OPENGLES20_IF_AVAILABLE to 0

My app runs much smoother in OpenGL 1.x. however in Xcode I receive these warnings(I guess):

Code (csharp):

1. Unsupported: Hidden/TerrainEngine/Details/BillboardWavingDoublePass
2. Unsupported: Hidden/TerrainEngine/Splatmap/Lightmap-AddPass
3. Unsupported: Hidden/TerrainEngine/BillboardTree
4. Unsupported: Hidden/Nature/Tree Soft Occlusion Bark Rendertex
5. Unsupported: Hidden/Nature/Tree Soft Occlusion Leaves Rendertex

While I do have terrains in the game, they are very small and I use no trees, grass, etc., nor do I use any nature shaders. I also made sure that none where referenced in the terrains as brushes in the inspector.

Are these messages cause for concern? The app runs through completely on device without issue, but I hate warnings.

I'm on the verge of submitting the app, but do not want to until I'm clear on this. It runs well in GL 2, but the improvement seen stepping it down is noticeable and I really don't require it for this game. Any and all insight is greatly appreciated.

 

Don't use fixed function shaders. The "Mobile" shaders supplied by Unity aren't suitable for non-obsolete mobile devices. Neither is OpenGL ES 1.1.

 

Thanks Much, Jessy.

I'll try and swap them out and test it. When you say "aren't suitable", do you mean from a performance standpoint, aesthetic , or both?

I went with what I thought were simple shaders assuming (I know, I know) that they would be less demanding of the hardware.In some cases the editor itself suggested using a shader from this category.

I really appreciate your insight. This is clearly an area in which I need to better educate myself.

 

Performance. I don't know the full details of what happens, but here's some info:

- http://unity3d.com/support/documentation/Manual/iphone-Hardware.html

- http://developer.apple.com/library/...html#//apple_ref/doc/uid/TP40008793-CH106-SW5

And then there's the anecdotal evidence; various people have complained about framerates on iOS. Then I wrote them GLSL shaders, when they had been using the pure ShaderLab shaders that Unity provides, and their framerates went up.

Now, this doesn't mean that a native GLSL shader is always going to be faster than a translated fixed function one, but if you write it well, you can either get the same effect with better performance, or potentially better effects with the same or better performance. All current iOS devices have the potential to run better if you abandon OpenGL ES 1.1. Part of that is on us, the other part is on Unity. The shaders portion is on us, but Unity really doesn't help much. My impression is, the team doesn't have an interest in us writing GLSL directly because it doesn't fit in with their cross-platform goals. My opinion is, today's hardware isn't fast enough to be able to use surface shaders on mobile devices, and Unity isn't doing a good job making it easy on us to push graphics quality on the platform forward: documentation is nil.

 

Again, Thank you very much. Your second block regarding the on-the-fly generation of the shaders puts much in perspective. I'll be spending some time on your site going through the tutorials

 

I agree with jessy, the shader stuff for mobile needs some proper tlc.

 

Great post Jessy,

why did you choose GLSL to write them in GLSL?

If i'm targeting iPhone 3gs+ (opengl 2.0 mobile devices), are there any difference (in performance) if i write shaders in GLSL or CG?

thank you!

 

How about fixed function shaders vs a Surface Shader (that as far as I know gets compiled to GLSL, although it obviously won't be as optimal as writing by hand).

 

all shaders get compiled to GLSL on iOS / Android, cg is not supported at all.
Thats further backed up by Aras nice little optimizer that ensures that the cross compiled shaders run with as little 'unneeded stuff' as possible as the default cg output would be devastating. (compare the first public 3.0 beta vs 3.2 vs 3.4 to see the progress on the optimizer)

Its normally only surface shaders that are a problem and thats cause they assume presence of pixel lights and make full use of it. if you go with traditional pixel + vertex shader cg you don't have that fillrate overhead nor do you really have it if you don't use pixel lights, only vertex ones (set lights to unimportant)

 

My problem is that writing a shader with GLSL that uses lightmaps and plays well with beast was kind of a pain. I wanted to to do fresnel cubemap reflection + lightmap, I got something *almost* working in GLSL, but it was a headache to write (well, my GLSL knowledge is minimal though). And then I did the same thing in Surface Shaders in like 3 lines.

 

CG shaders compile into GLSL on iOS/Android.

But does that means that if i write the shaders on CG instead of directly in GLSL would be signifcantly slower? (slower in CG)

 

ok nevermind, i have been doing some research and i found that unless i can write great glsl code it would be the same or maybe slower than the Cg.

 

The optimiser is not perfect, but aras has stated in the past if you find cases which it's slower at converting why not send him the test case ? will help to improve the optimiser.