klepto2

When you edit a value like the range of a layer-variation and switch to another variation without leaving the previously edited control the new value is passed to the new variation. The same happens for a lot of other editable fields like colors, etc in the default scene tree.

When you set the camera far-ange to something higher than the default 1000 the layersystem is not displayed correclty anymore and start flickering when you move the camera. The bug is more visible with higher farranges but also noticable when the range is somewhere like 5k or 10k. This is a small gif to show the bug: and i have add a small sample map demonstrating the bug. The zip contains a map with a terrain and the box mdl used as a vegetation layer. Also the "CameraControls.lua" is modified so that when you press "F" the range is set to 1.0 and 100000.0 and to default when "F" is not pressed down. VegetationLayerBug.zip

This might be because of the predefined steps for down and upsampling. Normally you would calculate the needed steps in code and choose the correct steps based on the resolution. The downscaling and upsampling is normally calculated like mipmapping.

I get the same, instead of rgb it is bgr.

Might be related to this: it happens as soon as generated meshes or instances go beyond a certain value.

yes it will , but in the meantime i think Josh will have a native waterplane integrated.

Thank you Its nice to see it in action. the default threshold is 1.0 because you normally just want bloom for colors brighter than the normal color range ( < 1.0). this is why you always need to use bloom before you do any tonemapping (normally tonemapping will try to bring the colors back to 0.0 - 1.0 ranges). the auto exposure should come before that.

Hi, thanks for pointing this out. I will take a look as soon as possible, I think it will just be some small details.

not that i am aware of. I mainly see the info included in the description or depending on the editor in the project files of the used editor.

Maybe for import of heightmaps, ask for the minimum and maximum height in meters. This info comes with most terrain generators and also allows the calculation of "below sea level" (< 0) positions. Maybe these values should be set to a default range of min= 0 and max = 100.

I know that it is expensive, and I usually use just 1k textures, which are much faster to compress. The model I have used is from Kitbash and "pipelined" via (KitBash3D) Cargo and blender 4.1 (gltf-export) (I downloaded the 4k by "accident"). The problem with these models are that they use up to 200 textures which is very much and this is why I experienced the long loading time (with normal models with baked textures or lower texture count you might not notice it) I know that bc7 (and bc6) are expensive, and you have done a great job with it. But I would still suggest some important UX improvements on this part: The process should not block the editor rule of thumb → if something takes longer than 100ms, show a progress screen with proper update/progress info if it is non-blocking, show progress in the status bar with information of what file is processed right now. In general, for a better UX you should report more info to the user on certain actions. Just a few samples where this might apply: Model/Texture-Conversion GI-Building Scene-Loading

Converting textures alone, works flawless and only takes a few few seconds (even when the size is above 2k). But when converting a gltf model to mdl it is painfully slow. As you can see it takes more than 5 minutes for just 23 textures. (around 5 materials) and i have killed the preview exe to not disturb the process. With the preview exe running it doubles the amount of time.

Normally this shouldn't be needed as it would only require additional GPU memory. The textures in the background are already smaller in size due to mipmapping so using lower res textures for lower lods is not needed.

Ok, i think the bottleneck were some textures saved originally in png with a size of 4k. These textures take a lot of time to convert. jpgs of the same size worked fast. Will test it a bit more and provide you the textures which convert slow later.

As a sidenote: The main reason for the long loading time (regardless the not wanted conversion) is, that the conversion of texture to dds seems to be extremely slow in the latest build. It takes minutes for just a simple 2k jpg.