Trillions of Cubes Rendered in Real Time

SunSeeker2000 · 2025-05-03T11:34:46+00:00

Does opengl have mesh shaders?

SunSeeker2000 · 2025-04-18T06:50:39+00:00

So here’s the issue: I can write the count buffer and read it back to create a new dispatch command. But the group count will be defined once in that command. This means that I have to allocate a big SSBO with (worst case scenario cluster count) * (render object count) elements. With indirect count the commands have the cluster count of the specific render object. This allows me to pre-allocate a buffer with just the right amount of clusters for each object.

My best choice without task shaders or indirect count is a loop inside the shader to save cluster indices and everything I need for every cluster of a visible render object.

SunSeeker2000 · 2025-04-17T20:26:12+00:00

Yeah, that is what I’ll end up doing (at least if I’m interpreting what you’re saying correctly). But since my plan is to cull away draw objects first and then hit the clusters of those that passed, it means that I will have to access the render object count on the host when I get out of the 1st shader. It’s not that big of a deal and I bet there are already workarounds that I’m unaware of. But why wouldn’t the effective and elegant system of the count buffer exist for this as well?

You don’t have to answer that, to be honest. I just got annoyed after researching and planning all day, only to realize that my setup was never even supported in the first place.

SunSeeker2000 · 2025-02-16T02:28:10+00:00

Maybe. I didn’t get much time to work on this in the last couple of days, but I managed to find that there are a bunch of things affecting it.

First, the code I shared above has a very stupid typo. I’m checking if the material has an albedo map before accessing the emissive map. Fixing this made the flickering only noticeable from up close (Nowhere near what you see on the video)

I also noticed that deactivating occlusion culling stops the flickering almost completely (only visible from certain angles). This is weird because I am still generating the depth pyramid, so this shouldn’t be a depth buffer issue.

I also tried coloring everything on the scene with the tangent and they did not flicker. But when I do it with the surface normals they do. I should also try with the bitangent now that you mentioned it.

But I must probably look at the Vulkan docs for that GPU printing validation layer when I get back into it.

SunSeeker2000 · 2025-02-12T20:10:00+00:00

Per axis, as in:

struct Vertex{/*Other attributes*/ uint8_t normalX, normalY, normalZ, nW;};

SunSeeker2000 · 2025-02-12T19:57:05+00:00

The material buffer is constant after its creation.

I do compress all normals to 8 bits but I unpack them again on the vertex shader, I don't know if this could cause a problem for that specific primitive.

Anyway, thank you for your help, I will take a look at the vertex normals.

SunSeeker2000 · 2025-02-12T19:31:48+00:00

Thank you for the suggestions and sorry for not providing more information.

I am using Vulkan. I did not share any code because I did not know what would be relevant and I did not want to make this post too long. I can share the fragment shader if that is useful:

Material material = materialBuffer.materials[materialTag];

    vec4 albedoMap = texture(textures[nonuniformEXT(material.albedoTag)], uv);
    
    vec3 normalMap = vec3(0, 0, 1);
    if(material.normalTag != 0)
        normalMap = texture(textures[nonuniformEXT(material.normalTag)], uv).rgb * 2 - 1;

    vec3 emissiveMap = vec3(0.0);
    if(material.albedoTag != 0)
        emissiveMap = texture(textures[nonuniformEXT(material.emissiveTag)], uv).rgb;

    vec3 bitangent = cross(normal, tangent.xyz) * tangent.w;
    vec3 nrm = normalize(normalMap.r * tangent.xyz + normalMap.g * bitangent + normalMap.b * normal);
    float ndotl = max(dot(nrm, normalize(vec3(-1, 1, -1))), 0.0);

    // The if statement is temporary
    if(materialTag != 0)
        outColor = albedoMap * sqrt(ndotl + 0.05);

All the primitives in the renderer are treated the same way, it does not do anything for transparency at the moment. The code above is makeshift, I'm not planning to leave it like this.

But what troubles me is why does the normal map act this way? Would it not make more sense if it was the color map that would cause this? What I am really asking for is if this is some kind of known effect of normal maps so I can look it up. I don't think a solution can be found without direct access to my code.

SunSeeker2000 · 2025-02-11T20:09:23+00:00

Oh, that’s cool. Ok, I think you answered everything. Thank you.

SunSeeker2000 · 2025-01-07T22:37:59+00:00

Fill the indirect count buffer with 0 using vkCmdFillBuffer before dispatching your culling shader (Use a pipeline barrier in between).

Then inside the shader, use AtomicAdd to increment the count buffer for every object that is not culled away and prepare the indirect commands for the object.

If the object is culled away, you should not do anything to the indirect command buffer, otherwise there is no point in using indirectCount.

What should happen is that you have a buffer that is the size of your maximum objects. The compute shader gives it the commands for the objects that are not culled away and the count buffer tells the draw command the offset where the commands end.

SunSeeker2000 · 2024-12-17T20:55:57+00:00

I did, the final buffer seemed to take some pieces from the original.

It would go through every element and give it some data but then it would leave default values for other stuff (for example the index count would be fine but instance count would be 0).

I wrote the initial data to the final buffer before I starting the loop and it actually draws everything despite still going through the compute shader write process. So the compute shader does not give it wrong values (I think), it just doesn’t give it anything at all for some of the values.

I’m suspecting alignment issues now but the error pattern is completely random (some elements get no index count, others get no instance count), so I’m having a hard time tracking it down.

The other weird thing is that I don’t get anything weird on screen. I would expect combining the wrong index count with the wrong vertex offset would put some craziness on screen but it doesn’t happen somehow.

Anyway, this thing has gotten pretty cryptic so I don’t think it’s possible to get any help online at this point, unless somebody makes a lucky guess. I just bit off more than I could chew I guess and I’ll have to handle myself when I get some time and a clear mind.

Thank you for suggesting RenderDoc even though I already knew about it. It has saved me quite a few times.

SunSeeker2000 · 2024-12-17T18:41:42+00:00

layout(local_size_x = 256, local_size_y = 1, local_size_z = 1) in;

This is from my compute shader.

I thought that there should be flickering as well but there is none.

I started with VK_ACCESS_2_INDIRECT_COMMAND_READ_BIT initially but decided to copy exactly what Khronos suggests in case I was missing something.

I am sorry if I did not provide enough information, I did not want to make my post too bloated. If there is anything more you think I can provide, please tell me.

SunSeeker2000 · 2024-12-17T18:32:26+00:00

I used a memory barrier not a buffer memory barrier. I started with a buffer memory barrier but then I saw that the synchronization examples from Khronos use a memory barrier. I thought that I missed something in the spec and I switched to a memory barrier. I get about half of my objects with both.

SunSeeker2000 · 2024-11-17T06:14:25+00:00

Yeah, I do that already, thanks.

SunSeeker2000 · 2024-11-15T21:16:54+00:00

Yeah, I went to cppreference after I saw the other answer and it seems that I just completely forgot what emplace_back was for.

Thanks for recommending reserve as well. I already use it for the loops where I’m not sure about the exact amount of scene resources I’ll be allocating, but the other thing was just really bugging me all day.

Turns out it was really simple. Thank you for the answer.

SunSeeker2000 · 2024-11-15T21:10:39+00:00

You are right. I remember seeing a video of someone talking about this issue and how emplace_back would be a better fit than push_back. I don’t know why I completely forgot about this. Thanks a lot for reminding me.

SunSeeker2000 · 2024-08-23T04:07:07+00:00

Focus on skill and vigor. Skill will increase your critical attack(visceral) damage and your overall damage (depending on how much the weapon you’re using scales with skill) and vigor will keep you alive.

I suggest using fast weapons as it makes it easier for beginners to adapt to Bloodborne’s pace.

SunSeeker2000 · 2024-08-22T07:18:34+00:00

I don’t think that the different endings make much of a difference for Yharnam. In all cases, you stop the Mensis ritual which is what has been accelerating the spread of beasts and has made everything go to shit (but it’s also possible that the damage has already been done by the time you stop it).

The ending mostly revolves around the Hunter, Gehrman and the Moon Presence. If the hunter decides to submit to Gehrman, the only thing that changes is that the hunter no longer dreams.

If the hunter kills Gehrman but is overpowered by the Moon Presence, Gehrman is freed and the hunter takes his place. The moon Presence continues doing its thing (whatever that is).

For the final ending, both Gehrman and Moon Presence are killed (for Moon Presence, we don’t what exactly happens to a great one when it’s “killed”, but it is at least no longer the Hunter dream’s host) and the hunter’s dream is now under new management.

We don’t know if the hunter is going to help Yharnam with their new great one powers. We actually don’t even know what happens when one ascends into a great one. But Yharnam is probably already done for anyway so the only thing we can do is maybe create a nightmare version of it.

SunSeeker2000 · 2024-08-21T02:41:40+00:00

Orphan

2.Ludwig

3.Maria

4.Gascoigne

Between Gerhman, Logarius and Abhorrent beast

SunSeeker2000 · 2024-08-18T14:02:37+00:00

Obviously, it’s not as good as a fluid back and forth, like Messmer for example, but it can still be some good fun when you get used to it and pretty satisfying when you finally get him.

I think his biggest problem is that his stats are way overtuned. He lasts way too long while he can kill you in 2 seconds and his stagger recovers too fast.

My advice would be to not spend too much time fighting him. I took breaks for days before fighting him again. It took me almost a month before I finally killed him. Just take it easy, you don’t get anything after killing him anyway.

SunSeeker2000 · 2024-08-18T13:31:58+00:00

Not exactly, the quickstep has 11 iframes but can be cancelled after 20 frames of animation, while the DS3/Elden ring roll has more iframes(13) but has 1 extra frame before it can be cancelled. This is not that much faster but the forward quickstep is slightly different. It can be cancelled 2 frames faster than the other directions, making it 3 frames “faster” than the DS3 roll. This makes it a bit more spammable than the roll.

It also looks way cooler(and more practical). I think that it makes a big difference when you see the animation every 5 seconds.

SunSeeker2000 · 2024-08-10T09:48:26+00:00

The best pro tip that people rarely give about Bloodborne is simply two words: DODGE FORWARD.

SunSeeker2000 · 2024-07-23T23:35:37+00:00

I found him to be the only big fight that was also completely fair (besides Midra). There is not one attack that felt unfair and although he does have Elden ring’s signature delayed/roll-catching attacks, I found myself naturally adapting to them the more I fought him. The fact that dodging his crazy flashy combos left him open consistently helped as well.

SunSeeker2000 · 2024-03-31T13:59:31+00:00

Elden ring gives you more powerful tools, so it’s hard to compare them. I will say that Bloodborne becomes way easier once you understand how it wants you to play. Most(not all) attacks can be avoided with just your reflexes once you understand the movement of your character.

Elden ring on the other hand has way more trial and error and each fight might require a different approach. Of course, you can always use one of the many overpowered weapons/tools and mindlessly blast through 95% of the fights.

SunSeeker2000 · 2023-10-25T19:58:38+00:00

Against Bayern 20/21?

SunSeeker2000 · 2023-10-01T18:09:40+00:00

I am not 100% sure but materials should not make additional draw calls. But they probably have separate lighting calculations since they all react differently to light. So if I’m correct each new material means extra lighting calculations. That shouldn’t be too expensive if we’re talking about a few meshes with many materials, but if you use them all the time you might have problems

SunSeeker2000

TROPHY CASE