klepto2

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.

I have the same issue and it started after adding a new gltf model (a larger one) into the project. Now everytime the editor is started, it takes a lot of time. In the log i can see, that the model is reconverted everytime to mdl (including all textures etc).

it is more realistically than the brightness > 1.0 of the diffuse channel. In addition to what Dreikblack said, you can use the emission for much more: glowing signs, monitors with text on it and much more. Another benefit of having a brightness value (adjustable from the MaterialClass) is an easy way to implement flickering materials or ways to turn glow on/off. This looks right, but it has a major downside (at least in my opinion): Once you set the brightness to 0.0 you lose the color information. In my opinion you should always store the color and brightness independently in the material file. How it is then used in the engine doesn't matter, but it will prevent users from accidentally delete the color information.

Ok, i don't know why, but it works now. But i would suggest to add the same functionality to the emission color.

This is a small collection of reworked posteffects including: DOF Features: Bokeh Filtering Autofocusing FocusStart and focus Length values SSAO Features: Denoising Temperoal Reprojection More Samples than the original Tonemapping Features: More or less the same as the original, but with more configurable options and usage of the original Kkronos tonemapping Bloom Features: Multipass downsampling and Tentupsampling More natural bloom effect based on this great video: And a completely new (well actually it is based on an early idea from @Josh) Volumetric Lighting effect which can be configured by using the TextureScale.y component of the light to adjust the volumetric intensity for each light. more configuration options will come later. Download: KL_Effects.zip License: MIT As a start the preffered order of posteffects is included in here:KL_Preffered.json As always feedback is always welcome, also ideas for other effects are welcome as well. Please share if it doesn't work for you or if you experience some big performance drops or any other thing which might be related to these Effects.

thats what i thought as well, but when you choose another brightness than 100, the colors are safed normalized and after reloading it, the editor shows again 100 instead of the original value.

If you open up a material in the editor or try to save it manually via code. The Brightness is not saved.

Currently a map can only have 1 set of baked GI probes. Lets say i have big level (eg.: a city), now i want to have a GI for the daytime and one for the night. currently I need to save the map 2 times with different names. Maybe it is better to store the GI with keys and then have something like this in the code: world->SwitchGI("night"); the list of GI should have a flag for the default key, which is used when the scene is initally loaded.

I have some suggestions to the posteffectsystem: These ideas for function might make the managing of posteffects much easier: RemovePostEffect(camera,index) GetPostEffect(camera,index) GetPostEffects(camera) SetPostEffectOrder(camera,index,newindex) Enable-/Disable- PostEffect(camera,index) The editor currently lacks access to configuration of posteffects, while some already define uniforms, they currently can only be changed by code, not in the editor. As a start, i would suggest something like this: { "posteffect": { "uniforms": [ { "intensity": { "label": "Intensity", "type": "float", "default": 1.0 }, "color": { "label": "Effect Color", "type": "vec3", "default": "1.0,0.0,1.0" } } ], "textures": [ { "size": [0.25, 0.25], "format": 37 } ], "subpasses": [ { "samplers": ["PREVPASS"], "colorattachments": [0], "shader": { "float32": { "fragment": "Shaders/PostEffects/GodRays.frag" } } }, { "samplers": ["PREVPASS", 0], "shader": { "float32": { "fragment": "Shaders/PostEffects/GodRaysResolve.frag" } } } ] } } This way the uniforms can be parsed by the editor and a ui can be generated. Maybe with an optional groupname to make it more clear.

As posted on discord I have tried to improve the existing Bloom shader to go more to the current industry standard. While the bloom shader is good and solid, its technique is a bit outdated and normally not used anymore. Also a lot of posteprocessing effects, overall lighting in PBR reflections, etc might look better when switching to a full HDR pipeline. Current state (from my investigations): The framebuffer uses RGBA8 format This framebuffer is passed to the posteffect pipeline as an "entry" texture So no posteffect can use real HDR operation Proposed state: The framebuffer should use GL_R11F_G11F_B10F or GL_RGBA16F With this colors can be stored in their HDR form Before displaying a tonemapping should be applied Why: Lets take a closer look to Bloom (I have just focused on it, but can provide more samples if wanted) Lets say you have a very green object with a Color RGB = 80,255,74 or in Vec4 it would be (0.31,1.0, 0.29). SDR: When adding lighting etc. to it or change the brightness to something above lets say 400 The resulting color in the rendering will always be 1.0,1.0,1.0 It is clamped by the RGBA8 format Adding thinks like tonemapping, reflections etc will look washed out : HDR: Same as for LDR Without any lighting the stored color will now be vec3: 1.24, 4.0, 1.16 this can properly be used for bloom to define where bloom will occur with the current approach white areas (1.0,1.0,1.0) are considered blooming even if they shouldn't with hdr those pure white areas stay uneffected and only real emitting surfaces are providing bloom. not only that, the bloom will be more physically correct: like in this sample: you can see that in the middle: the emmision accumulates up in the middle and the emission fades out with the distance. Some more resources: https://www.youtube.com/watch?v=tI70-HIc5ro https://www.iryoku.com/next-generation-post-processing-in-call-of-duty-advanced-warfare/

If we take a deeper look to the shader code (MeshLayer/Vertex.glsl) the reason is, that the mesh layers rely on the heightmap and terrain resolution. The instances are passed all at height 0 and the height and alignment is calculated in the vertex shader on the fly. this way the in editor painting is fast (no picking involved), but i agree that this would be a nice feature. Maybe a more detailed sample why this would be a nice feature: the nature of heightmap terrains is that they don't allow overhangs etc. so to add those, we need to add meshes to simulate them. With the current meshlayer system we need to place custom instances of the foliage ourselves on these meshes. (including syncing lod settings) This will (at least until the new culling is introduced) be a potential bottleneck for detailed terrain maps, or pure mesh based levels. My idea would be to introduce a new paint mode (maybe a checkbox called include meshes) if this is on, a pick is done and the height and normal is stored in a seperate texture or taken directly from the meshlayer instance when the height is != 0.

also it would be nice (if possible at all) to have a cancel option. This way it could be possible to have something like this: void DepthOnlyRenderHook(shared_ptr<Object> o, shared_ptr<Object> extra) { auto renderer = o->As<OpenGLRenderer>(); auto camera = extra->As<Camera>(); //what is the cameraid actual? if(camera->GetId() == renderer->cameraid && (pass & RENDERPASS_DEPTH) == 0) { // disable all other passes and just draw the depth pass // might be much cheaper for much scenarios where later computations are just dependend on the depth. renderer.cancel = true; } }

Very nice, thank you. Will take a closer look into this soon I have 2 more requests: Maybe we need a HOOKID_COMPUTE_AT_START and a HOOKID_COMPUTE_AT_END This is because some computations may rely on data produced after the whole rendering is done. It would be nice to have also access to camera frustumn (if possible) Some geometric code might need this (like my quadtree implemntation)

Hi, no I think this is incompatible with the latest version. I will try to fix it tomorrow.

I didn't use that command in the code which causes the high culling time. I will investigate it further, i have tried a switch to the stable version and get the same results (with a clean project) as you with the start map and the dev branch. With my test maps and ocean rendering though it is something different, i still get much higher culling times (especially in debug builds > 400 ms), but can't compare it with the stable release.

Since the last update the performance and culling has decreased drastically. While in the previous build i got around 7ms in release for the culling i now get > 100ms with very simple maps. Also the FPS now drops to < 10 where i previously got 60+ fps. The editor is also now laggy as hell. After some more investigations: The culling time increase remains valid, while the fps and laggy behaviour of the editor might be related to missing shader updates. After updating the shaders, the FPS drop is not that much as before. But the culling time increased by the factor of 10 compared to the previous versions. Release: Previous: 4-5 ms Current: 40 to 50 ms Debug: Previous: 40-50ms Current 400 to 500ms.