alice_i_cecile

alice_i_cecile, 3 days ago

1. https://github.com/bevyengine/bevy/pull/12659

A simple set of bug fixes with regression tests for our triangle math. Merge conflicts are still not resolved after a week, and they're too tricky for me to do quickly in the Github UI.

This gets the S-Adopt-Me label: picking up work like this is a really nice approachable way to help out and make sure that work doesn't get dropped.

alice_i_cecile, 3 days ago

2. https://github.com/bevyengine/bevy/pull/12929

A performance improvement for our ECS internals: we're storing redundant information and with a bit of careful design and a sprinkling of unsafe code we can get rid of that to save memory hopefully a few compute cycles.

James rightly points out that this is relatively risky due to the tricky unsafe and suggests waiting until the start of the 0.15 cycle. I agree: adding the S-Blocked label to it so this won't show up in this search for now.

alice_i_cecile, 3 days ago

3. https://github.com/bevyengine/bevy/pull/13123

Ooh, the system builder API is ready. Whee shiny ECS features: 0.14 will be exciting. This is a really nice improvement for more flexible ECS code, especially when integrating with scripting languages.

The general pattern of "dynamic core with strongly-typed API on top" is a recurring theme as we develop bevy_ecs, and I'm curious to see if we can move more in that direction here.

Now, for the actual work...

alice_i_cecile, 3 days ago

This is labelled X-Contentious, and with good reason. There are implications to consider, but no one thinks this is a bad direction and it's well isolated.

I really like how the API has evolved; this is much nicer. Reviews are high quality! Okay, code quality is good, and I like the strategy they used for implementation. Docs are inadequate though, and there are a couple of serious rough edges (no Res<T>?) that I want to polish before release. Requesting changes and adding to 0.15 milestone.

alice_i_cecile, 3 days ago (edited 3 days ago)

4. https://github.com/bevyengine/bevy/pull/13218

Oh wow. This is the "use Sebastien Aaltonen's ofset-allocator design to make rendering faster" PR. Those are some impressive performance gains. Multiple milliseconds reduced overhead on Bistro, a high-end but not unreasonable test scene.

This is beyond my rendering skill level, although the code quality and descriptions are great (thank pcwalton). The author added this to the 0.15 milestone: I'm going to ask rendering opinions on what to do here.

alice_i_cecile, 3 days ago

5. https://github.com/bevyengine/bevy/pull/13277

A straightforward enough change to how we're tracking information about the order in which we render entities. Rather than adding components to the entities in the render world, keep a map of them in various resources.

There's a modest performance gain, but the real impetus is in simplifying and reducing the render world's use of the ECS. The current extraction strategy used for pipelined rendering is complex, fragile and costly. Painful for new ECS features!

alice_i_cecile, 3 days ago

The PR itself looks solid: simple, well-made, widely approved by folks with relevant expertise. Let's merge it :)

alice_i_cecile, 3 days ago

6. https://github.com/bevyengine/bevy/pull/13380

A math bug! I'm so so glad that we've fostered a little herd of mathematicians in Bevy now: very handy to have them on hand when we need to nerdsnipe them somehow.

In this case, we weren't recomputing normals correctly when rescaling meshes, leading to weird artifacts. Some good discussion in the comments about correctness but this is resolved now.

Looks good and there's a regression test. Merging.

alice_i_cecile, 3 days ago

7. https://github.com/bevyengine/bevy/pull/13415

bevy_assets usability improvements! Very pleased to see work here pick up in 0.14: there was a long period where we were "waiting for the rewrite" and it took folks a while to get their feet wet with the new code base.

This PR integrates the "load asset with these settings" API into our "please don't get fancy with async" API. Great, this should exist.

There's a nice follow-up issue for making the API more cohesive with the builder pattern but that can wait. Merge!

alice_i_cecile, 3 days ago

8. https://github.com/bevyengine/bevy/pull/13417

Speaking of PRs that are useful but could benefit from future work: a genuinely nice API for sorting queries.

Go look at the examples in the PR! They're way nicer than I thought possible. Great application of the esoteric query transmutes here.

All sorts of fancy caching can and probably should be done in the future, but for now, let's get this to users. Very useful as is. Merging.

alice_i_cecile, 3 days ago

9. https://github.com/bevyengine/bevy/pull/13430

Today, our pet mathematicians bring us such gems as "Now, convert a point from the fundamental tetrahedron into barycentric coordinates by taking the four successive differences of coordinates; note that these telescope to sum to 1, and this transformation is linear, hence preserves the probability density, since the latter comes from the Lebesgue measure."

Truly, arcane incantations (thankfully my training has prepared me) but remarkably clear to the experts.

alice_i_cecile, 3 days ago

Sampling the faces and interior of triangular prisms is useful enough as an operation, and this is well done. Very nice documentation and code quality: I would be happy to see this used as a reference implementation of the algorithm.

Merging!

alice_i_cecile, 3 days ago

10. https://github.com/bevyengine/bevy/pull/13438

One of the constant chores of large projects is maintaining consistency across it. In this case, we would use "segments" to describe the number of sections used to draw things like circles in a gizmos context, and "resolution" in a rendering context. As the original issue says, we should use the rendering convention to confuse people less.

Good refactor: it's nice to see associated methods and constants cleaned up too. Merging. Thank goodness forbreaking changes.

alice_i_cecile, 3 days ago

11. https://github.com/bevyengine/bevy/pull/13449

Lava burning bright with the fire of a thousand suns! Nah, actually that's just a bug. Whoops! We fixed a bug in our rendering code last week, but one of the examples needs to be retuned to stop working around it.

I checked this PR out locally using the gh CLI tool earlier today to validate the change. Looks broken on main, and much more reasonable on this branch. Weird diff though, thanks Github. Merging.

alice_i_cecile, 3 days ago

Alright, that's all the PRs for this week! I love seeing the mix of shiny features, bug fixes and little improvements that roll in for @bevy :) It's one of my favorite things about well-run open source: unsexy bugs and papercuts don't get neglected forever. Eventually, someone will be motivated to fix it themselves! And when they do, it'll be an easy review and merge <3

Thanks to all our contributors (including users who complain!): the effort and polish really does add up.

alice_i_cecile, 3 days ago

@MaeDay Fixed, thanks!

alice_i_cecile, 4 days ago

Just throwing ChatGPT at a problem is never going to lead to good results. Like the authors say, it'll be inconsistent, unmaintainable garbage.

So, you add guard rails and structure, plumb together different tools, and get a so-so end result with shiny tech demos.

For the true believers, this is just "the first step" towards a path to greatness: a future where 10 years from now the profession of "game developer" no longer exists because AGI generates them on the fly for each player.

alice_i_cecile, 4 days ago

But that's not what is going to happen here. Those guide rails can't be removed: there's too much complexity for the models and users to grasp and work with otherwise.

Instead, these companies are going to promise the moon but end up with templates and bespoke customized tools tailored to very specific domains with AI to fill in the gaps for content. RPGMaker and RenPy, but this time Made With AI!

alice_i_cecile, 4 days ago

But instead of thoughtful user interfaces, helpful tutorials/docs and clear lines for what can and can't be done, you get a natural language interface, over-promises and arbitrary stochastic inconsistencies.

And rather than heavy machine-generated code, you'll get true spaghetti: arbitrary code snippets jammed in at random, with no sensible version control history, tests or architecture.

alice_i_cecile, 4 days ago

These "make your game with AI!" tools are orbiting the low-code local optimum. With:

• a clear, narrow scope
• an excellent human-friendly API and UI
• progressive disclosure of complexity
• great learning material

You can make a tool that lets people create basically fine things in a creative domain without ever mastering the underlying material. And that's good! That's how abstractions work, and how great tools are made.

alice_i_cecile, 4 days ago

But just like low-code, don't buy the hype around all-in-one AI solutions.

These tools will fail in surprising, frustrating ways at the edge of their domains.

For long-lived projects, they'll be more expensive and frustrating than doing it right in the first place.

They won't ever produce results that are as good as the general purpose tools that offer more control.

And they won't save you from the hardest parts of mastering a craft: troubleshooting problems and developing taste.