Sven

Same scene but with 220 instead of 20 FPS.

With an improvised workaround we're back to a decent frame rate!

Memory leak in `EntitySpecializationTicks` and `SpecializedMaterialPipelineCache` when multiple materials are present · Issue #21526 · bevyengine/bevy Bevy version and features 0.17.2 What you did This came out of a longer debugging session I "documented" in a bluesky thread. //! Example to reproduce memory leak issue. //! use bevy::{ pbr::{Exten...

Hyperbole aside, I was able to reproduce it in just a few lines of code: github.com/bevyengine/b...

back at it now and boy do things look broken beyond belief

With that fixed, EntitySpecializationTicks is another map that just keeps filling up. The reason might be related. Time for a break for now though.

Ah I had this backwards. Them being removed means that the `contains_key` check can return false and the cleanup later can actually happen!

Through trial and error I found that running the early sweep before the specialization function actually fixes the issue.

But that doesn't make sense. The early sweep only removes cache entries and doesn't add any. So something else must be going on there.

Why are those material instances not present?

There are three systems that modify them. The extract and the two sweep functions. The extract function is the only one that can add the instances. The sweep functions only remove them.

The ordering appears correct.

Now there *is* code to remove the cache entries when a mesh is despawned. In my case however, the loop early-exits most of the time at the first `contains_key` check and so doesn't get to remove the entry in the next step.

800000 entries and growing...

Printing out the number of cache entries shows that they grow indefinitely with each spawned terrain chunk. Despawning chunks however does not seem to remove their cache entry.

Luckily bevy is open source, so we can just take a look. Those functions have one thing in common: They all access the `SpecializedMaterialPipelineCache`.

Inspecting a frame in the profiler we find those three function calls taking about 50ms. How do they spend all that time?

18 fps with a tiny window and not much going on.

I realized that the frame rate of my game was going down the more I played.

Let's debug!

For orbital motion I have a separate physics engine that models trajectories with patched conics. So it boils down to a bunch of two-body problems that can be solved with the Kepler equation :)

The egui "before" image. Looks fine.

The Bevy UI "after" image. Looks similar but overall a bit more polished.

The egui -> Bevy UI rewrite is complete!

Quite happy that it was possible to reproduce the look and feel from before and even improve on it a bit :)

#bevy #gamedev

It's definitely easier to use. Functionality wise I haven't had issues with either so far.
Not sure about height maps, I use plain trimeshes for the terrain chunks.

A demo of the UI without the rest of the game.

Currently porting the GUI from egui to #bevy UI and quite happy with it so far! The only thing I'm missing is the ability to render arbitrary meshes as part of the UI.

Image nodes are super useful. I'm using one to show the navball which is a 3D scene rendered to a texture.

#gamedev

You're absolutely right! The landing pad is about 75m wide. I should add a banana for scale or something.

I switched to the Avian physics engine! Its excellent documentation made this a pretty simple process.

The physics now run at a fixed rate, independent of the frame rate. This helps a lot with determinism and things keep their velocity, even if the rendering isn't fast enough.

#bevy #gamedev

I added a hover mode to the spacecraft controller! It tries to keep the craft level at a fixed altitude so that the player can precisely maneuver across the ground.

Oh and also it's now possible to load in any 3D scene with colliders, like this makeshift landing pad.

#gamedev #bevy

A planet seen from a couple hundred kilometers above the surface. There is an ocean now and its color changes based on the height (or depth) of the surface below it.

The same planet from further away.

Finally got around to adding oceans to the planets!

It's just an additional opaque mesh on top of each terrain chunk. But changing the water's surface color depending on its depth is so simple yet so effective at faking actual translucency.

#bevy #gamedev

Actually I was on holiday in Stockholm, great city, might have eaten too many Kanelbullar

Back at work now cooking up some cool features, stay tuned

Apologies for the lack of updates, I was chilling at the top of the highest mountain in the solar system

#gamedev #bevy

Instead of being completely filled with color, the terrain chunks are black with a little colored square in the center.

One reason I enjoy shader programming is that at least bugs are entertaining

Currently writing a controller to enable some cool takeoff and landing modes. The idea is that the controller should make such maneuvers relatively easy and intuitive as long as the ship's construction makes them physically possible.

#gamedev

Before and after view of a moon's terrain. The "after" image contains some green rocks spread across the surface.

Experimenting with some close-up terrain detail textures. I like how putting some green rocks on the closest moon to the gas giant ties the scene together :)

#bevy #gamedev

A spacecraft shaped like a lava lamp turned on its side with some fins on the back.

Working on a new aesthetic for the spacecraft model. The technology in the game should be more of the "far future" kind. This will do for now.

#gamedev

Before and after comparison of the moon from far away. The "after" image has much higher detail in the color and normals. The polygon count is still low but that is not visible from this distance.

The solution: Just fall back to the color and normal from the texture I generate for the map view. More detail without having to increase the polygon count!

#bevy #gamedev

The new terrain system had one drawback: The generated lower detail chunks did not have enough texture detail. A quick fix would have been to just subdivide them more, but that quickly blows up the memory and we do not actually need the additional geometry.

I should stop taking screenshots on a bright screen in a dark room.

But hey at least the brightness is somewhat appropriate for the distance from the sun.

No overhang support unfortunately. I had to pick my battles and decided against them in favor of a much simpler and more performant solution.