Zylann / godot_heightmap_plugin

HeightMap terrain for Godot implemented in GDScript

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

GLES2 support ?

avril-gh opened this issue · comments

commented

the info reads that it support gles2
While it do work on gles3 renderer, then while switched to gles2, the terrain surface is not visible and there are spam of shader compile errors.

Does it support gles2 or .md info is wrong ?

commented

To my knowledge, the terrain itself doesn't use features that GLES2 doesn't support. However I never took the time to test that in Godot... #87 already hinted this but I've been busy on other projects.

In doubt, the README could be considered incorrect, but it should be investigated why, because it could be a bug with Godot or something to adjust in the plugin, if not too much of a hassle.

One of the few things I know about GLES2 implementation in Godot is that it doesn't support HDR. The plugin doesn't use HDR... almost. If "HDR" means "16-bit viewport", then some of the tools provided in the editor part of the plugin will not work, or badly work: GPU-accelerated terrain generation and normals baking, mostly. So editing a terrain might require GLES3, but the terrain alone doesn't.

This compilation error is present in the log when I'm trying to use it under GLES2:
error C7532: global function textureSize requires "#version 130" or later
According to the following issue
godotengine/godot#28885
this is because the OpenGL ES2.0 and OpenGL 2.1 (the versions of opengl that GLES2 uses) do not support TextureSize() this is documented in the official docs http://docs.godotengine.org/en/latest/tutorials/misc/gles2_gles3_differences.html#shading-language
Right now I'm trying to implement the workaround suggested by @clayjohn in this discussion, when the texture size is passed as the shader parameter. I do not know, will it help or not, but I'll try it :)

commented

@Antokolos ugh, that sucks... well at least it's doable with a uniform, if it was a shader feature it would have needed a copy/paste of all shaders^^" (since Godot still doesn't have godotengine/godot#17797)

Well, the workaround for TextureSize() worked, but I've experienced some more errors.
This is the terrain in GLES3
image
And this is the same terrain in GLES2
image
By the way, the collider seems to be OK, I've tested it in another project.
Also, when I try to edit the terrain in GLES2 mode, nothing happens, because the following error is present in the log:
drivers/gles2/rasterizer_storage_gles2.cpp:738 - Not implemented (ask Karroffel to do it :p)

P.S.: I use Godot 3.1.1 stable for Windows.
Hope that the fix will be released someday, because your project is really promising!

commented

@karroffel :p

If the terrain looks flat, it means the heightmap couldn't get to the GPU somehow... I reaaaaally hope GLES2 supports 16-bit textures, because if it doesn't, the plugin just straight won't work xD (or will have lots of bumps and be a pain to support in 8-bit).

Edit: ok that error you got mentionning Karroffel is partial texture update. The plugin can work without that, it will just be slower to edit large terrains. Normally GLES2 supports this, but in the meantime you could add a renderer check here so it uses the fallback:

if VisualServer.has_method("texture_set_data_partial"):

@Zylann I think 16 bit textures are enabled with an extension in GLES2. So likely not gonna have full support for it.

commented

Oh well... if half-float textures don't work in GLES2 that plugin might just not support it officially then. That's really too bad because it would basically cut away mobiles without Vulkan and web.

@Zylann just looked into it. GL 2.1 supports it natively and GL ES 2.0 requires an extension that Godot looks for and uses automatically.

commented

I tried taking off all textureSize calls from all shaders. All errors went away, but the terrain still looks like this:
image

I have a feeling that texture(u_terrain_heightmap, UV).r is clamping all values to 0..1, as if higher range wasn't supported at all.

commented

in gles2 on mobiles, reading from textures in vertex shader is not supported at all.
why not 'smuggle' height data within vertex color, theres 4 bytes per vertex free for use,
could be color.a for height and color.rgb for normal, tangent and binormal.

commented

@avril-gh if vertex displacement from texture is not allowed, then this plugin won't ever work on such mobiles. This terrain works decently because it does not generate meshes, and that would require a complete rewrite of the plugin just so it supports those devices...

commented

as said many times this plugin does not support GLES2 at least for now.
closing to decrease issues count and let the author concentrate on his work.