Post

The reason for wanting to build this pipeline, and iterate it further, is… UX friction! The regular workflow was too frustrating, so this pipeline was built to make it feel much easier. Though, there is still friction remaining.

This Godot <-> Blender pipeline will be released soon under MIT, with example CC0 assets with a demo. Along with documentation of workflows.

Next a talk by Bart Wilmink about LODs. I didn’t have the capacity to live post this one, it had so many illustrative gifs of assets changing. Catch the recording! All I can say is: Why are LOD workflows so frustrating?! Shouldn’t this be a solved problem by now?

Next up, we’re getting the premiere of Blender’s new short: Singularity. I am seeing it the way it needs to be seen: Maximum front row

I saw a demo of this many months ago, half finished. Seeing this now, fully formed, on such a huge screen with great audio is awesome.

Definitely the most comfortable conference seating I have ever sat in

Really great discussions and demos today at GodotCon. I haven’t seen a talk yet, there are so many interesting folks to meet!

Just draw an incredible PVKK demo on an absolutely enormous cinema screen.!

Next @reduz.bsky.social is talking about how to think like a Godot developer.

How is Godot developed? There is a community, and a foundation. Contributions from the community go through the foundation.

The ideal workflow is image 1. A smooth way to work on submissions. But the reality is image 2. Many things get ignored.

Why do submissions get ignored? Volume of submissions is just too high. Answering properly takes a lot of time. Some contributors can’t take a no, no matter how polite. It’s a stressful situation for everyone.

This organically leads to shiny proposals with barely any use, drama discussions, and endlessly open PRs that will never get merged no matter how much they are worked on.

How can you help? Understand this rationale. Think about whether it’s useful now, rather than in the future. Think like a Godot developer.

Introducing an idea: Feature Scoring, to rate a feature to measure if it should be merged or not. Measuring would be on a CRIS score. Complexity, Reach, Impediment, Stakeholder.

Examples of scoring for each point in CRIS.

Example issue:, just for example: VIM in Godot: Complex, few need it.

Example issue: Interfaces. Important, but technically complex.

An example from a feature request by @reduz.bsky.social himself: Action Area. Not important, undemanded.

Example of symbol refactor: Complexity went from 0.1 to 0.9 by a suggestion to make it easier to implement. This would make it score much higher.

Why do this? What would it fix? Have an objective method for reviewing. Help submitters understand why they get accepted or ignored. Give definitively answers to requests. Project staff from harassment from those who can’t take feedback.

I asked: What about feature requests for things that would create new users of Godot that do not yet exist? The reach may be users who aren’t there yet, the impediment is those users are not there yet at all, and the stakeholder cannot exist as those users are not there yet.

Answer: Yes, but we ran into this with visual scripting. People kept asking for a ‘Blueprint like’ node system, it was built, and then nobody used it, so it was removed again in 4.0 So their experience has been to not just build things that “would add new users”, but instead service existing users.