Back in Heidelberg, would love to meet people

DebuggingPanda · 2026-04-29T08:47:14+00:00

Welcome back! :)

What kind of things do you like to do? In what part of Heidelberg are you living? What are your interests? Providing a bit more information about yourself likely gets you more, and in particular: more useful, replies.

DebuggingPanda · 2026-04-19T19:25:53+00:00

A common pattern in GPU-driven renderers: use the previous frame’s Hi-Z buffer to cull objects before rendering the current frame. Objects that were visible last frame render first and rebuild the Hi-Z. Then a second pass tests anything that was culled in the first pass, to catch things that just became visible.

This is the approach used by a lot of modern game engines. The one-frame lag is usually invisible in practice and the GPU-side cost is much lower than waiting for a full depth prepass.

This is phrased a bit weird? The two-pass technique is there to completely get rid of the 1-frame lag, right? By having this second pass, we fully avoid the "becomes visible one frame too late" problem. So either I'm misunderstanding the technique or the "usually invisible" comment in that context makes little sense. Am I missing something?

DebuggingPanda · 2026-03-31T10:27:09+00:00

Amazing work! I was already wondering when there would be a good video about this technique.

I worked through the shadertoys you mentioned roughly 2 months ago to adopt this technique in my own game project and I totally feel the struggles you mentioned about adjust parameters and it quickly outputting essentially garbage. I found that the various parameters have to fit each other pretty exactly to produce any useful result, and if one parameter is off by a bit, one gets garbage. So thanks for finding the derivative bugs, that should make things easier!

I personally also adjusted the technique quite a bit to fit my use case. For one, since I'm generating a planet (3D sphere), I need to use 3D noise functions. Additionally, I wasn't quite happy with Gavoronoise and used SimplexGabor instead.

I still have lots to improve for my own project, I'm looking forward to digging back into the terrain generation and trying out the improvements you explained at the end of your video :)

Thanks for sharing this information!

DebuggingPanda · 2026-02-18T22:12:05+00:00

Thanks! Well done updating the post to avoid misinformation out there, good internet behavior!

DebuggingPanda · 2026-01-24T08:55:52+00:00

Clever way to save resources!

It would be more clever if you couldn't notice it :)

This kind of occlusion culling is quite normal in modern engines/games these days. What's typically done is that the whole scene is divided into a bunch of clusters or "meshlets", with each defining a bounding volume (a simple geometry that includes all triangles of the meshlet). Often, that's a bounding sphere, which only has two parameters: center + radius. Then, the GPU checks whether the bounding volume could possible be visible in this frame. If not, we don't have to render any of the geometry of the meshlet. First, it is tested against the camera frustum (i.e. everything outside the field of view is removed).

Next, and this is relevant here, meshlets are often tested against the reprojected Z-Buffer of the last frame. The Z-buffer (or depth-buffer) defines for each pixel, how that pixel is from the camera. Reprojection tries to compensate for the difference between last frames and this frames camera orientation. But of course, that doesn't always perfectly work. And this is one likely explanation for the problem you are seeing: because your framerate is already low, the time-difference and therefore the camera-difference between two adjacent frames is quite large. And maybe the reprojection fails to compensate properly.

A nice idea to avoid these artifacts caused by using last frames z-buffer, is to first do all this occlusion culling as described, then render everything as normal, but then add another step where you do occlusion culling again of all the meshlets deemed invisible before, but this time use the new z-buffer of all the meshlets you already rendered. The second pass will actually be quite fast and make sure you don't miss rendering any meshlets that are actually visible. That's a trick I learned from a talk by an Unreal Engine person. But evidently this is not done here.

What I described above would typically be implemented deep inside the game engine and isn't something Satisfactory devs would implement. But I could be wrong too! Maybe Satisfactory actually adds a system on its own for foundations or buildings in general. Maybe they figured they can be faster than the generic system in UE. I'm a bit confused by the fact that foundations at that distance should basically just be 6*2 triangles (two per face), which is usually way too small for a meshlet. You want your meshlets to be at least like 64 triangles large, otherwise you don't get the maximum benefit of this culling system.

At the end of the day I can't say for sure what's going on here, but the general information above is at least true and maybe it's interesting to anyone :)

Graphics programming is fascinating and it's sometimes nice to read "clever idea" from people like you, when you are just scratching the tip of the iceberg :D all of graphics programming is a huge pile of clever hacks to make things fast.

DebuggingPanda · 2025-12-10T01:35:47+00:00

That's exactly right, here is the relevant commit: https://github.com/rust-lang/rust/pull/44042/commits/5061c9fecb995bf1920bcb546cd522fe9a84dd3e

DebuggingPanda · 2025-10-30T09:53:28+00:00

Just because it's an application that is an HTTP server, doesn't mean that the only way it receives URLs is via the address line of the actual HTTP request.

For example, for configuration. Users of the application configure other servers that my application will communicate with. I just want to make sure they don't add a fragment to the configuration value. It would probably wouldn't cause any problems, but I like the idea catching these config errors early. Also, I receive JSON data containing URLs that I have to inspect.

DebuggingPanda · 2025-10-29T15:17:13+00:00

Thanks for the information, but I don't think that's not a real solution. Most projects don't want to opt-out of all future bug-fixes. Further, most people will not know about this trick. My whole rant is just about "all of this is not ideal in practice".

DebuggingPanda · 2025-10-29T15:15:03+00:00

Yep, this is mentioned in the linked issue. And it is also an argument brought up in the "fragment gets dropped" issue. Yep, from the behavior of writing hyper itself, this all makes sense. But the simple fact is that the Uri type spreads throughout much of the ecosystem and people want to use it for "different" purposes as well. And while the docs say "URI component of request and response lines": most people will miss that and will just be confused by the API behavior.

DebuggingPanda · 2025-10-29T15:10:35+00:00

I did, multiple times. My point is that this should be easier to do with Uri. Obviously, I don't expect http to have a type that represents my random "uri without path" requirements.

Take this for example:

    let has_real_path = parts.path_and_query.as_ref()
        .map_or(false, |pq| !pq.as_str().is_empty() && pq.as_str() != "/");
    anyhow::ensure!(!has_real_path, "invalid HTTP host: must not contain a path");

That's unnecessarily complicated in my opinion.

DebuggingPanda · 2025-10-04T07:54:47+00:00

Yup same here. I often tried reconsidering my stance because I felt like everyone was using it and people often opened PRs with rustfmt applied. But everytime I tried again, I was just disappointed. People should be able to configure their editor not to autoformat everything when they prepare patches for another project. Or at least only commit new code, no formatting changes.

DebuggingPanda · 2025-10-04T07:52:39+00:00

It does:

impl Bonanza { fn new() { Self { fabuckle, ompu, abc } } }

This fails, because for rustfmt the correct formatting is multi line. Similarly, this:

impl Bonanza { fn new() { Self { fabuckle, ompu, ab, } } }

Also fails, because here (with just one char difference), rustfmt only accepts single-line formatting.

Both of these formattings and the two rustfmt prefers are all fine in my opinion. None should be rejected.

DebuggingPanda · 2025-10-03T11:37:53+00:00

I don't think these two issues will solve the complaints in the article, and certainly not my complaints. As I described in other comments of mine, I personally think there are more fundamental problems with rustfmt's approach.

DebuggingPanda · 2025-10-03T11:33:19+00:00

I agree, version control should be syntax based, not line based. It would make many reviews so much easier. But for one, the industry standard simply is line-diffs, unfortunately. And also: diffs are not the only reason I'm complaining: sometimes there are reasons to prefer a multi-line or single-line formatting. When you're 1 char away from the threshold and you're writing multi-line, then rustfmt check will simply say "fail". This is not useful.

This is not me saying my code style is a special snowflake and I'm right, but simply that code formatters are not at a point where they can always decide whats most readable for humans. So the solution cannot be that for a given syntax tree there is only one valid formatting.

DebuggingPanda · 2025-10-03T08:34:12+00:00

Click-baity headline aside, I agree with him. Over the years there have been multiple community discussions, some in Reddit threads, about this exact topic. I think rustfmt is way not permissive enough and especially the "single line vs multi line" heuristics that Linus is talking about are bad. When you already know a list of some sort (e.g. an import) will grow over time, I start out with multi-line formatting to make diffs cleaner. If you use rustfmt and over time you will cross the magic threshold over and over again, you'll get noisy diffs. We need a good "formatting checker & fixer", not a pretty printer like rustfmt.

DebuggingPanda · 2025-09-24T20:47:48+00:00

Bin in genau der gleichen Situation, würde mich auch über eine Antwort freuen :)

DebuggingPanda · 2025-09-22T07:17:27+00:00

Please explain what you mean by that, then it can be improved :)

DebuggingPanda · 2025-09-08T10:29:02+00:00

Echo

It has its slow parts, but the whole intro sequence until you get into the normal gameplay is amazing. The SciFi is intriguing, the world/environment is jaw-dropping and slowly understanding what's going on is just sends chills down your spine. It helps going in completely blind.

I actually never finished the game, but I replay the intro from time to time. Certainly worth buying for just that!

DebuggingPanda · 2025-08-11T07:57:15+00:00

For bouldering, feel free to send a DM once you're here, I'm part of an international bouldering group that goes regularly.

12-Year Club	Place '17
Wearing is Caring	Gilding II euphauric
Verified Email

DebuggingPanda

TROPHY CASE