Josh

There's a checkbox in the Appearance options. Static lights will use one shadow map for all static objects, and another for dynamic objects. This can greatly reduce the amount of shadow polygons that have to be drawn when an object moves: https://www.ultraengine.com/learn/Entity_Staticize In that example, only the spinning fan has to be drawn when the shadow is updated each frame. The rest of the scene is just copied from the static shadow map. id Tech does something similar to this, I think.

Found the cause, uploading the shader file now...

It's actually not a problem with clipping region, which was my initial guess. The texture is on that block is being read in the shader and the block is showing up. The application just seems to be reading (0,0,0,0) for the color, for some reason. Texture coordinates look correct as well...

Oh, I understand now. You are looking for a max view range at which the entity will be automatically hidden. We do have a SetViewRange method in the Entity class, but there is no interface in the editor to set this visually. I should add this in...

Thanks, I will check this out tomorrow. This is very likely just a small shader error. The entity data layout was modified to add more information. I did test a GUI sample, but it did not use an icon.

Full build uploaded now.

0.9.7 Added texture auto-scrolling for material, currently only in editor. You can use this for conveyer belts, water, or other effects.

Wouldn't that just be making it hidden?

It's hard to say without seeing the scene. 4060 is a midrange card, not the extreme high-end, but pretty good and should be fast for almost everything.

0.9.7 Added per-entity emission color. Only works if an emission texture is present in the material, otherwise it is ignored. Added per-entity texture offset and scale, for all meshes or for decals. These features are currently only available in the editor.

What GPU do you have? Some of the post-processing effects were initially designed to push high end cards more, because originally I thought we would have higher spec cards now than in the past, but it seems more like most people just have the same cards they had a few years ago. So with SSAO in particular, I was thinking we might scale it back to the same approach Leadwerks used. MSAA will also have a big effect on performance.

I hope that information helps you!

0.9.7 Decal layer filtering now implemented in the editor, in the Appearance properties as a bitwise flag. A shader update is required to get extra logic code for handling this.

0.9.7 Entities now include extended information in their data stored on the GPU for features that are to be implemented very soon. This includes a decal layer value for control of what surfaces decals appear on, render layers value stored on the GPU in anticipation of GPU culling, entity emission color (to be implemented soon), and per-entity texture mapping features. Project sync is required to get the latest shaders. Custom shaders that use the ExtractInfo() type commands will work with no changes, although in the future I want to move towards the version of the command that uses the EntityInfo structure defined in Shaders/Base/EntityInfo.glsl.

1. I have no immediate plans for this. Mesh shaders by themselves are not very useful. You need content that is designed to work with mesh shaders. Of course, mesh shaders can be used directly if you write OpenGL code. I am planning to add new rendering hooks in soon, and it will be a lot easier to handle than it was in the Vulkan renderer. 2. This is doable without much trouble. You can probably access it already if you just go into the Render:: namespace. 3. I plan to keep terrain in the editor as a static object oriented at the center of the world for the immediate future. Future development is going to go in the direction of very large scale terrains, and then finally planet rendering. 4. This is possible,. but it sounds like a very niche feature not many people would have use for. 5. I expect version 1.0 will be done by Christmas at the latest, maybe by Halloween. The only major features left to implement after the next update are particles and GPU culling. 6. Since 64-bit floats require a lot of auxillary features to be useful, I have no estimate of when this will be added. It's tied to large-scale terrain and geo-spatial features. I am also very interested in multi-material painting, which would be a big change in paradigms. If that were in use, every object effectively becomes a paintable terrain. That might be the first thing I add for a version 1.1. I think it would take about 6 weeks to implement.

Should be an easy fix!

There's also a "Reset Transform" menu item that will keep the same size but reset the scale to 1.0.

You can set the model's scale. Select the top-most entity in the model and in the properties below you can modify the scale.

Reported to Nvidia here: https://developer.nvidia.com/bugs/4787960

Specifically, it's the call to glMakeTextureHandleResidentARB that causes memory to continously leak.

I narrowed the problem down further. Bindless textures have a huge memory leak in Nvidia's current drivers. Simply getting the bindless handle and making the texture resident causes memory to be allocated each frame, even when no camera is in use.

IPB is the forum system we use, btw.

This is interesting: https://preview.invisionalpha5.com/

It's a memory leak in Nvidia's driver. I just installed driver 560.70 and now I see the same behavior as @Dreikblack

It's also worth checking if this behavior occurs when shadows are disabled on the lights, and if the ground model is not created. There is also a memory monitor built into Visual Studio 2022 that runs when the app is being debugged. I suspect this memory allocated might be in the graphics driver DLL.