Counters should be tracked per thread but I'm using CPU core numbers for indexing in some places. This is definitely wrong and sometimes causing a program crash.

Also, counters are just being printf'd. Visual rep. is required, like PIX on Windows does in above image.

I'm really bad at categorizing things :/

This is what I wanted when I was implementing render thread, but currently the engine is not working like this.

Currently main thread tick is somehow bound at glutDisplayFunc's frequency, and I don't remember why I did this??? :(

Old render thread PR: #24

Overview

Implemented in #26 but have following issues:

1. HiZ tracing is just wrong
2. SSR jitters when TAA is enabled

References

• GPU Pro 5, "Hi-Z Screen-Space Cone-Traced Reflections", Yasin Uludag
• https://gpuopen.com/fidelityfx-sssr/
• https://jcgt.org/published/0003/04/04/
• https://lettier.github.io/3d-game-shaders-for-beginners/screen-space-reflection.html
• http://roar11.com/2015/07/screen-space-glossy-reflections/

Sample images

SSR disabled

SSR only

Composite result

Test dump

[Frame 257]
main thread
    WorldTick: 1 ms
        FlushLoadedAssets: 0 ms
        UpdateCurrentWorld: 0 ms
        CreateRenderProxy (MainScene): 1 ms
        CreateOverlayProxy: 0 ms

Render Thread
    Present: 0 ms
    Frame 257: 0 ms
        ExecuteCommands: 0 ms
        DestroyRenderProxy: 0 ms
        WaitForGPU: 0 ms
    Frame 257: 1 ms
        ExecuteCommands: 1 ms
        DestroyRenderProxy: 0 ms
        WaitForGPU: 0 ms
    Frame 257: 20 ms
        ExecuteRenderer: 6 ms
            UpdateUniformBuffer: 0 ms
            RenderPreDepth: 0 ms
            RenderCascadedShadowMap: 0 ms
            RenderOmniShadowMaps: 0 ms

Almost all counter items are estimated to 0 ms. Though my clock resolution is in milliseconds, there's no way these counters take less than 1 ms.

This is current state of my volumetric clouds, implemented several years ago, but it never worked as I wanted. This is just a result of random luck from random math on volume noises.

Currently every aspect of cloud rendering isn't working as expected:

• Weather map's cloud coverage and cloud type
• Contribution of base noises and erosion noises to cloud shapes
• Density gradient for cloud coverage
• Cloud lighting
• Raymarching

It's time to fix it.

Fixed things so far:

• Cloud coverage and cloud type works as intended.
• Base noise determines overall shapes of clouds and erosion noises only contribute to small carving.
• Density gradient works as intended.
• Cloud lighting does not result in random number.
• Adaptive raymarching.
• Banding artifacts (thanks to NVidia STBN).

Now temporal reprojection remains but it's a different situation than TAA. I can't derive exact world positions of prev/current cloud particles that first-hit camera rays. Fast temporal reprojection without motion vectors looks promising.
-> I reviewed the paper but it uses too much memory :/ I'll need 25 textures of the scene size for 25 different offsets. Can't alias them because the merge kernel accesses all of them.

Remove dev branch and use master as an usual work branch.
Make a release branch to stash stable versions.

~2021

2022

Area light test

Old demo world with new lighting

Old RC1 world with new bloom

Yet another GLTF asset

Latest version of syoyo's tiny_obj_loader is moved from 0.9.x to 1.0.0.

Problem

• A shape can be consisted of several faces. Each face can have its own material.
• My engine converts this shape into a Geometry, but a Geometry is paired with only one Material.
• So if a shape uses several materials I can't deal with this.
• Solution: not shape -> geometry, but face -> geometry? But there is too many faces! Millions of buffers = unnecessary tremendous overload.
  • Each buffer should hold all vertices/normals/texcoords. Somehow distinguish the faces and apply different materials!

attrib {
  vector<float> vertices
  vector<float> normals
  vector<float> texcoords
}

index_t {
  int vertex_index
  int normal_index
  int texcoord_index
}

mesh {
  vector<index_t> indices
  vector<uchar> vertices_per_face
  vector<int> materialID_per_face
}

So, I have to group faces by their corresponding material IDs and convert each group a Geometry!
No, one Geometry for one shape. I only need to create separate index buffers for each material ID.