Josh

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.

It's working fine here. If you have the create tool selected you won't be able to select objects.

The biggest difficulty with getting consistent shadow map offsets is the fact that depth textures are stored in non-linear space. This is good for camera depth testing but terrible for shadows. You can see in this image the area near the light source has higher precision than the area further away from the camera. If the precision was equal for all distances it would be much easier to set or calculate an offset that would prevent the "shadow acne" artifact. My idea is to modify the gl_FragPosition.z value in the output of the vertex shader, in order to reverse the linear-to-depth transformation before it is stored in the shadow map, which will equal a linear value that can then be compared to a linear position in the shadow sampling step in the lighting shaders. I am having no luck getting this to work so far.

If you edit a map file by hand you will destroy its contents, because there is some binary data at the end.

Can't profile a video!

I wanted to talk to you guys about this topic. In the Vulkan renderer we had a transfer and render hook. I don't see any need for these two hooks anymore. Do you? What information needs to be passed to the hook? I think everything can be retrieved with functions: wglGetCurrentContext(); glGetIntegerv(GL_FRAMEBUFFER_BINDING, &fbo); At what point in the renderer should this hook be called? I am thinking after all objects are rendered, before post-processing effects. Should it be set per-camera instead of per-world perhaps?