Hell yeeeah. Love to see godot get the love it deserves.

For example, because Line2D runs on the CPU, while a shader runs on the GPU (much faster). But of course, many effects can be achieved in different ways. I just happen to prefer shaders.

Good plan! 😎

Why make it a shader? Couldn't you get a similar effect by simply playing around with a Line2D node's color with a gradient?

I'm saving all these as bookmarks but I swear I'm gonna go through them at some point

Hi, thanks! Yes, this is my solo indie game going. Your planets look good, I like it. One sprite with one shader is good for performance. I use 2 shaders (terrain and clouds) with multiple textures mix currently.

Is this your work? I really like your visual results, congratulations!

I would like to piggyback your post to share my attempt at the same problem, if you don't mind. I used one sprite with one shader for each celestial body, no viewports, but also no shadows.

https://git.fabioiotti.com/bruce965/space-capture

For those too lazy to click the link:

Beyond the UI refinements / workflow improvements, some things that stuck out to me were:

Core: Make it impossible to have more than one main thread, and don’t release unnecessarily (GH-121161).

Core: Speed up removing many child nodes (GH-120942).

Seems important, and good. Probably not a good idea to somehow have two main threads racing each other.

Also we all know killing your children as efficiently is possible is what makes games fast, lol.

Editor: Show doc tooltips in quick settings (GH-121278).

Input: Ignore joypads on unfocused window by default for new projects (GH-120399).

Both of these will definitely reduce headaches for me.

Rendering: Use non-volumetric fog in WorldEnvironment sky reflections (GH-107958).

Another very good optimization.

Thirdparty: Update to Jolt Physics 5.6.0 (GH-121260).

Possibly a big deal if you run a physics intensive game.

I am guessing implementing the new hair physics would not be on the table until 4.9, but, Jolt 5.6 overhauled its friction calculations to be more efficient, so... that could be a blessing and a curse, might make your physics setup need to be re-tweaked a bit, but should also be significantly more performant.

More on Jolt 5.6.0 here, not sure exactly... how much of this would be fully supported/utilized in Godot 4.8. 'Upgraded' is kind of sparse, so my guess would be... just whatever Godot is currently basing off of Jolt will be migrated, and the new features, new cpu/shader stuff... ???

https://gamefromscratch.com/jolt-physics-5-6-released/

To my knowledge, this is the first time anyone has done this in Godot

There is Zylann's godot_sdf_blender. Not sure how it compares, though.

octree based

It would be cool to have Cube 2: Sauerbraten map support (I especially like things like arches and other mesh details). Though a lot of the look can be done with meshes+vertex colors (more materials for things like glow, metal) the missing piece for me is the map editing workflow* particularly something more intended for modularity (Godot's gridmap is clunky when it comes to multiple cell sizes).

* I haven't been able to try the new vertex snapping, nor Trenchbroom/Cyclops

I wonder what that and this could do together.

Excavation game? Both in terms of globbing dirt to walls, and dynamically dividing walls down that convert to SDF objects when small enough for digged surface. Actually this seems to exist as well, JorisAR's GDVoxelTerrain:

This project adds a smooth voxel terrain system to godot. More precisely, it uses an octree to store an SDF, which is then meshed using a custom version of surface nets. Level of detail systems are in place for large viewing distances.

To my knowledge, this is the first time anyone has done this in Godot, and that in itself is very impressive.

I was fucking around with my own attempt at giving Godot a kind of octree based ... spatial framework, if that makes any sense... I wonder what that and this could do together.

32 is a deliberate ceiling for this edition, not a limit of the technique. The design goal was set no compute no buffers one file shapes travel as uniform arrays, and every primitive adds a distance eval to every march step on every pixel, so a fully analytic field doesn't want hundreds anyway. The scaling tricks are exactly the ones you list bake everything static into a precomputed SDF texture and sample it as a single primitive. That's the natural direction for the node based edition if it grows to v2

Hadn't seen the liquids part of that SIGGRAPH talk thanks for the pointer, watching it.

up to 32 primitives

This seems very low unless it's nuanced or multiple tricks can be used. Joined operations/volumes/surfaces, scheduled calculations etc. So I'd like to see what can be implemented in more examples.

The SIGGRAPH talk for PixelJunk Shooter 2 covers things like this albeit 2D, distance fields are used for the walls (2, static+dynamic, merged into 1), different shader techniques for liquids.

well would be anonymous from godot, just not google :(

the so survey had to have lots of it optional, it was half about ai lol

I don't know either but '2022 or earlier' is a clear answer for me, so I don't find it too bad. How would be a harder question, I think I became aware of Godot somewhere in the 2.X days (I remember the wide jaw icon) though I became more interested/involved after 3.0 and even now I still haven't done much (I did finish a simple project, but can't share it at the moment).

I find the question on page 3 'how are you satisfied with <8 categories>' a worse requirement (it does have 'I don't know', though that's unsatisfying yet I also don't feel like evaluating those so I'll stop there).

EDIT: The main thing I miss representing by not submitting here is Nim (GDExtension).
I also wish for the XR question there was something like "interesting idea but I can't afford the hardware / I know someone with a VR headset but it's gathering dust and they're too afraid to ask Zuckerberg for developer mode"

When did you first hear of Godot? *

I love required questions with very specific answers I don't know how to answer. I guess I'm out.

Earlier I did the StackOverflow survey and everything was optional. I liked that.

The poll is anonymous

Link to a google form

...

Surely Godot has enough money to host their own polling system right?

Love seeing that!

We’re even included! 🥳

Didn't know this was even a thing!

yessss looking forward to touch input for these control nodes

It might be interesting to make the node its own scene if only to use it as a "plug in" to change the generation. Then you could make different generators that you pop in and out during play. But tbh you could probably achieve that without a separate scene by exposing the generation params in the inspector.

Decide on a resolution and then connect those verts (points on the wave) and give everything below it a material. Maybe user a mask for that.

For node structure it doesn't really matter, if it's gonna persist then give it its own scene. Everything will live under the game node anyway. Structure matters only when you have nodes talking to eachother, and creating and deleting. For the sake of maintaining references.

This game shouldn't have many nodes anyway so don't stress it.

I've already shared this, but can't help but praise it again for C# users: Cat-Lips/GodotSharp.SourceGenerators

Among other things, this library auto-generates boilerplate to access most Godot things with names (like your scene tree nodes). That means changes to the scene tree in the Godot Editor immediately show up as errors in the IDE, so refactoring becomes a lot easier :)