Josh

Okay, it will work in the build that goes up later today.

I cannot fix this without the file that causes the error.

I added the missing format. However, there are a few rules for terrain textures in 0.9.5 to take note of: All textures on one terrain must be the same size. There is an additional argument in the CreateTerrain function that lets you specify this size. I have not added a control in the editor yet to let you adjust the size of a terrain that is being created. The default size is 1024. Base color, metallic-roughness, and emission textures used in a terrain must be in format BC7. Displacement textures used in a terrain must be Luminance format (single channel 8 bit grayscale). Normal maps used in a terrain must be BC5 format. The reason for this is that array textures are now being used for terrain rendering. This solves the problems we were seeing with pixels on the borders invocation groups and will help make the engine runnable on a wider range of hardware. This zip file does not include any textures.

I found the cause. In the visibility list, meshes are grouped by pipeline settings. This is all the different rendering settings, plus the shader in use. The pipeline settings has a < operator for sorting. This is how the grouping is done. I added a setting in the shader family to force bindless textures off, but did not add any sorting for this in the < operator in the pipeline settings class. As a result, your sphere was probably getting rendered using the terrain shader. Once I added the needed fix the problem went away.

At this point I suspect a nasty memory overwrite in the terrain system. I am seeing behavior that does not otherwise make sense...

This is a strange one. Has this every happened without the terrain present?

I cannot fix this without seeing the texture files.

Do you know what folder is selected when this happens, and what files are in it that might be causing this?

The entire renderer backend was replaced in 0.9.5.

For each mesh, if its material does not use shadows, it will not cast a shadow.

It's both. Both the material and entity must have shadows enabled for a shadow to be cast.

I see nothing in this model that would cause the lowest resolution LOD to not cast shadows. However, the wrong LOD might be getting selected when rendering shadows. Directional lights are made up of four box lights.

When an LOD is loaded from a model, it just adds the meshes found in that model into a new LOD. No entity properties are copied from the LOD model file. A model with several LODs is just a single model.

Fix is incoming.

When I tried it on mine, I found a bad driver bug with one of the more advanced commands. I'll report it to Intel and hopefully get it fixed.

0.9.5 Editor updated with some fixes.

I am changing it to use the highest-res LOD.

Ah, I see. The pick routine uses the lowest LOD available, but in your case the model geometry is very different from the full-res model.

Hold on, I was looking at one of the LOD models. For the main model, it looks like the branch material can be picked, but the trunk cannot...

If you scene has an IBL intensity of zero or no specular and diffuse reflection maps set, things will appear very dark. However, I did also notice that the light in the asset editor world was being hidden all the time, so I am fixing that.

The error above indicates there is some pixel format being used that I have not written support for yet. This is why the texture ID is zero.

This occurs when you add a new material layer to the terrain? What material are you using? The error you are seeing indicates that an unsupported texture format was probably used. I would like to know what texture file it is.

If you look at GPU utilization on the 1080, the numbers are like this: 0.9.4 / 0.9.5 Instances: 96% / 85% Lighting 96% / 96% Animation 96% / 93% Batches 76% / 67% Again, they are for practical purposes identical in lighting and animation. The batches test had lower GPU usage, which may be caused by small changes in the visibility list processing step, since this involves 1000+ separate batches that have to be iterated through and processed in the rendering thread. The GPU usage in the instances test is strange because 0.9.5 has lower GPU utilization but higher performance. This may be attributed to small changes in shader code, although I do not know what those changes would be. 0.9.5 does use one fewer vertex attribute, but I don't really see that doubling the framerate. All in all, it looks like OpenGL 4.6 gives AMD a major performance boost and runs about the same as Vulkan on Nvidia cards in these tests.

I tested on my GEForce 1080, and these are the numbers I got: 0.9.4 / 0.9.5 Instances: 1206 / 2320 Lighting: 863 / 810 Animation: 1067 / 1032 Batches: 5199 / 3300 So on Nvidia it's faster in one test, slower in the other, and about the same in the other two. When you are running at 1000+ frames per second, it's very easy for small things to have a disproportionate impact on the framerate. Adding something that takes 1/4 of a millisecond will drop 6000 FPS to 4000, so I don't think at that speed the results are very meaningful. Both the instances and batches tests could have been skewed by very small changes.