I’m new to JME, trying to learn step by step (although I’ve read entire documentation and watched a bunch of videos & etc), decided to 1st figure out everything about terrain.
So here are my questions:
Am I correct, that currently it is not possible to make PBR textured terrain in editor ? Since there is no way to set roughness/metallic or albedo maps. What would be the correct approach to use PBR textures while being able to model/design map in editor ? Since as I have understood PBR is way better then regular rendering for terrain and overall.
When I try to run from jme-test PBRTerrainTest/PBRTerrainAdvancedTest they both throw same exception:
com.jme3.renderer.RendererException: compile error in: ShaderSource[name=Common/MatDefs/Terrain/AdvancedPBRTerrain.frag (PBRTerrain.frag), defines, type=Fragment, language=GLSL150]
ERROR: 0:1294: 'mod' : ambiguous function signature match: multiple signatures match under implicit type conversion
ERROR: 0:1294: '' : missing #endif
ERROR: 0:1294: '' : compilation terminated
ERROR: 3 compilation errors. No code generated.
Looks like some syntax/logic error in fragment shader file. Is there way to fix it ? Or maybe updated shaders are available ?
So in SDK you can create NavMesh for the terrain. I’m a little confused about that whole thing. Is there some way, to edit that NavMesh, preferably somehow visually, so that I can specify which areas you shouldn’t be able to navigate through ?
Walkable buildings (also integration with NavMesh) - how those are implemented generally ? For instance, I’ve imported model of some castle/building - how to let engine know you can enter inside / tell NavMesh how to navigate inside ?
It looks like this error is due to a casting mistake I made at this line of code here:
I think it should be easy to fix by changing 4.0 to just be 4, so the mod() remainder function should be using all ints instead of mixing ints and floats.
Thanks for finding this error, shaders are always tricky like this, where some mistakes will be overlooked by certain GPUs and won’t cause any issues, but the same code will crash and throw an error on other GPUs. And unfortunately the PBR terrains (especially the advanced one) have not had much testing despite how long ago I wrote them.
But I will work on fixing this and will submit a PR soon once I’m certain this solves it.
If you want the fix sooner, you should also be able to copy the terrain shader’s .j3md file, .frag file, and .vert file to your local project and make the change to the .frag shader there. But hopefully this fix should be able to make it in the next jme version.
This is unfortunately correct still. It would be great if someone who has experience with the SDK were able to update the terrain editing tool to work with the PBR Terrains, but I never worked with the SDK myself so it isn’t something I have plans to do myself anytime soon. It should be fairly easy to make an editor for PBRTerrain.j3md, but AdvancedPBRTerrain.j3md uses texture arrays which make things more complicated, especially since JME’s material exporter is still missing the code needed to save TextureArrays when a material with a TextureArray is saved, so any TextureArrays need recreated every time the terrain is loaded. So in my project, I save/load my terains with the normal pbr terrain shader and then convert it to the advancePBR terrain when the game starts.
I do have a custom terrain editor that works with pbr terrains, however I’ve been reluctant about releasing it because its still pretty buggy, particularly with the AdvancedPBRTerrain, and there’s many little workarounds I have to do to get things to not break when I’m editing advanced PBR terrains. But I guess I might be best off just releasing it in an unstable state sooner than later since current there are no other ways to edit a pbr terrain in a visual editor.
It looks like this error is due to a casting mistake I made at this line of code here:
Nope, I’ve changed to 4 and it didn’t help. According to compiler error, it says there are multiple implementations of MOD function with different type parameters, so you need to explicitly specify type of the variable you are passing to the function. I’m not really familiar with shaders syntax/language yet - so I can’t really help here :D.
But I guess I might be best off just releasing it in an unstable state sooner than later since current there are no other ways to edit a pbr terrain in a visual editor.
Yeah, definitely, go for it, since there is no official support yet.
Hmmm I think it may be related to the $i variable, which is using some jme-specific shader pre-processor functionality.
I was assuming that $i is a standard int, but it sounds like the shader compiler might not think so.
So I have 2 more ideas:
First would be to cast $i to an int:
int x = int($i);
texChannelForAlphaBlending = int(mod(x, 4));
And if that still doesn’t work then I might just need to leave it all as floats, since some information I just read is stating that some older GL versions may not be able to handle integers with the mod function:
I wouldn’t typically keep asking you to try random things like this without testing it myself first, but due to the nature of this error I unfortunately cannot reproduce the error on my device. So I appreciate your help troubleshooting this issue and hopefully we can solve it soon
Edit: This may actually be a better solution, and won’t require changing texChannelForAlphaBlending to a float:
Glad to hear its fixed! Thanks again for reporting and testing this issue!
I will go ahead and submit a PR to jme-master to apply the fix to both shaders soon.
The advanced pbr terrain shader will typically be a lot slower than the regular pbr terrain, however that test-case is also not optimized at all, and could be fixed to run a lot faster.
I would typically recommend using both of those pbr terrain shaders in your jme projects, and make a togglable settting in your game (such as a “terrain detail” setting) so that userse with higher end devices can turn up their settings to enable the advanced pbr terrain.
But I should mention there are 2 critical flaws in the AdvancePBRTerrain test-case that are causing the framerate to be lower than it should:
First off I included way too many textures for a single terrain. I mostly did this as a proof of concept to show that the 16 texture-limit error goes away when using texture arrays in the AdvancePBRTerrain shader. So the test-case ended up with 6 albedo maps, 6 normal maps, and 6 metallicRoughnessAo maps, so that’s 6 full texture-slots which is way overkill. Typically you only actually need about 2-4 texture slots per terrain, and then rely on placing many smaller batched or instanced 3d objects for foliage and ground clutter, rather than trying to get more detail from adding more terrain textures.
And secondly, the terrain patch-size is way too small for a terrain of that size. The test case uses a size 1024 terrain with a 256 patchsize, so that ends up making 16 terrain-patches (which is way too much for a terrain that’s only 1024 units). I would typically recommend using only 4 patches per terrain (for example, a size 512 terrain wit patch size of 256) and make sure that each size 512 terrain is placed in a world that is scaled so that each terrain represents at least ~100 up to ~300 meters in world space. The terrain tests currently pack way too many terrain-patches and vertices into a small area, so that drastically slows things down. In my project, I can have 10+ terrains of size 512 loaded with triplanar and 2-5 texture slots on each, and still get >100 fps. But I get barely 30 when I run that test case with a single size 1024 terrain, so it is unfortunately a bad representation of that shader’s potential.
So I think I should maybe revisit the test-cases and make some improvements so it doesn’t run so slow. The terrain in that test-case also is missing mip-maps, so you may have noticed a lot of pixilation and sparkly artifacts all over the terrain when the camera moves. But I’ll try to fix all of that soon so the advanced pbr test case will do a better job at presenting that shader.
! Thanks for your help ! So mod takes both floats then it is ok. Advanced test though, gives 5-7 FPS and is very slow.