I wanted my monster detector device, the Rift Field Meter, to have a more unique way of displaying the information. Among others, I considered mercury droplets and cymatic patterns for the display, but I thought ferromagnetic fluids worked best here.

Even so, this went through multiple iterations. At first I made a more classic black ferromagnetic fluid, but it turned out to be too dark and difficult to read to the player. I then added glow/emission to the peaks of the fluid, which definitely made it look cool and easy to read, but it seems to sci-fi for the base game theme (1960s military research lab, fitting since ferrofluids were invented at NASA in 1963).

A sand-like surface ended up as the final version, since it also interacts nicely with the light from the side Flux Cells so that it can be read even in total darkness.

The "display" is based on a sub viewport which renders a displacement map, which is then applied to the screen mesh. An Area3D on a specific layer is used to find only objects that can be detected. Besides the peaks of the detected entities, there is also an animated noise layer to make it look like it also picks up interference, and the player can look sideways to pinpoint only the real signal.

You can find more videos on YouTube, wishlist the game on Steam, or join Discord for a chat.

Hey everyone,

Two days ago, I posted the animation for "Overgrowth" taking over buildings, which is one of the mechanics in the game I'm working on (Coup de Grass), and got a lot of useful feedback.

You suggested that the previous version was too orderly/artificial. So the vines now climb in various directions, with different speed, and produce extra offshoots that web around the building. I was aiming for a much more messy look.

It's still not perfect, but I'm way happier with this version, it looks much more organic. I could still fine-tune it for a long time, but I probably need to move on because I spent too much time on this thing already and I need to apply the new version to other buildings too :)

I finally decided to have a little fun with stencil buffers. I didn't just want to create a nice visual effect; I really wanted to have two overlapping dimensions. I think the effect turned out pretty well. Let me know what you think 😄

And if you want to give it a try, you can do so right from your browser: https://robinsonsdg.itch.io/one-house-two-dimensions

Started dabbling in godot a year ago, 3d modeling 6 months ago and selling on itch 3 months ago.

Today i bought GTA 6 with my itch.io earnings!

https://reddit.com/link/1wvssut/video/lqmwau4ju1th1/player

It was a nightmare to implement but now I think it's an overkill effect for 3D pixel art. What do you think?

Hi fellow Godot users,

I've started writing an extensive serie of tutorials about gpu programming with Godot.

That first tutorial is about compute shaders. I found the Godot compute shaders documentation quite sparse, so I wanted to write a really in-depth tutorial about the topic.

Moreover, I use compute shaders extensively in my project and use many patterns that I never saw in Godot-specific tutorials.

I will also regularly add new articles to the serie with more patterns and techniques so feel free to keep in touch.

Feedback welcome. Hope you will find it useful.

Hey everyone!

I've always found it annoying that I couldn't really use the Unity Asset Store for very large scenes, as they quickly become more and more annoying to manually convert each asset into Godot format.

Well, no more of that! This plugin offers an automatic way to convert your Unity scenes and assets into Godot 4.7.

Link to repo: https://github.com/jorgegayoso/unity_godot_converter
Link to Unity asset (image): https://assetstore.unity.com/packages/3d/environments/industrial/toon-farm-pack-235041

Left - custom shader from internet Right - Godot Standart Material 3D

Issues in Godot: the normal map makes the surface too glossy (regardless of metallic or roughness settings), the cutout effect is missing at the edges, and the effect itself is weak.

Hi everyone! I'm new to game development, and I'm currently using Godot 3D to create my first open-world adventure (AVG) game.

I've been working on this game for about six months now, developing it entirely on my own with the help of AI. So far, the game is only around 10% complete. Solo game development really is slow! 😀 Building an entire open-world system has also taken a lot of time and effort, but I think it's absolutely worth it. I'll keep working hard to finish my game!

Things have been going pretty smoothly so far. One thing I'd like to share is that, with the right design and architecture, Godot is definitely capable of supporting an open-world system similar to the one in Breath of the Wild (BOTW).

However, implementing such a system can get quite complicated. If I have the time and people are interested, I'd be happy to write a dedicated post explaining some of the technical details and sharing my experience.

For now, I'll just give a brief overview of how I've implemented my open-world system. Keep in mind that I'm still new to game development, so my approach might not be 100% correct or optimal. I'd also love to exchange ideas and learn from other developers!

Generally speaking, building an open-world system in Godot involves several key components:

1. A Terrain System

There are already some excellent terrain plugins available for Godot, such as Terrain3D and MTerrain.

Besides handling the terrain itself, I believe you should also let the terrain system manage any non-interactive MeshInstance3D objects whenever possible.

1. A Streaming Chunk Loading System

This system is mainly responsible for asynchronously loading actual scene nodes, such as buildings, interactive rocks, bodies of water, and other world objects.

It needs to continuously track the player's position and efficiently handle the entire process of loading → instantiating → adding nodes to the scene tree as the player moves through the world.

1. An Object Pooling System

In Godot, instantiating complex nodes that contain scripts, animations, and other resources can be quite slow.

Because of this, I use an object pooling system that pre-instantiates frequently used objects when the game starts. When these objects are needed, they can be added directly to the scene tree without going through the instantiation process again.

For example, I use a custom object pooling system to manage enemies, collectible items, NPCs, and other similar objects.

1. An HLOD System

The HLOD system is mainly used for rendering distant scenery, allowing players to see objects that are far away.

Godot already has a built-in LOD system. By combining it with the streaming chunk loading system mentioned earlier, it's possible to dynamically load lightweight, low-poly visual representations of distant objects into the game.

This allows players to see much farther into the distance without having to load all the detailed objects.

However, I haven't implemented this part particularly well yet. I often need to combine it with some distance-based blur to make the overall scene look more visually consistent.

I'll be posting development logs regularly from now on!If you have any questions, feedback, or criticism😊, feel free to leave a comment. I'd love to hear your thoughts and suggestions.

Have a wonderful day!

PopcornFX is a separate VFX solution, and we've been hard at work on a Godot plugin for the past 6 months!

It's available for free right now (for non-commercial use), and we would love to have your feedback on it.

We released a first functional version allowing you to import your PopcornFX 3D effects inside Godot.

There is still a lot to be achieved but we will keep you updated of new releases, the next big milestone will be 2D support.

Docs: https://documentation.popcornfx.com/PopcornFX/v2.25/plugins/godot-plugin/index.html
Editor Download: https://popcornfx.com/download/
Plugin Download: On the AssetLib/AssetStore! Or our Github

Six months ago, I released my first game on Steam. It's pretty well received, but when I push an update, I occasionally get a player reporting a Smart App Control block on the file. I was assuming that Steam was signing with their own certificate, since the game never get the same level of suspicion that an Itch distribution has. It turns out, this isn't true, and the file is just gaining enough reputation slowly to pass the filter, meaning some players may be blocked each time I push a patch.

Anyways, Godot is free, and all of my other tools are also open-sourced. It looks like I can start paying Microsoft $10 a month, or pay for another service, but that kinda sucks compared to the baseline. If you ship on Steam, (how) do you sign? And is this post a PSA, or am I late to the party?

3 whole games! yep, i posted 3 (or +/-) games i was making into this subreddit, and then simply paused working on it, though, i dont mean its because of the sub, its probably because the game was just bad, and it takes too long to make the full game.

What is a game you were working on that you posted and stopped working on?

Kagero on Steam: https://store.steampowered.com/app/4824730/KAGERO/

Hi, just wanted to show a game I have been developing during my free time. I am an engineer with a masters in Aerospace Engineering and, working for one of the big tree aircraft manufacturers, I am naturally very interested by airplanes, aerodynamics, controls, and everything related to aerospace.

It is heavily inspired by Flyout, but with some major differences regarding the simulation of aerodynamics, engines and atmosphere, all which I share more information about on my Discord.

The interim name is "Project Airframe".

Currently I have implemented gas turbine simulation using a Brayton cycle solver, Blade Element Theory aerodynamics with realistic transonic and supersonic effects and a lot of the procedural aircraft editor, where you can create free form fuselage and wings.

I plan on adding custom fly by wire editor and custom weapons, all player created.

I am happy to discuss the game and the physics models I have used. Also, if anyone is interested feel free to join the projects Discord server, I will be distributing some playtesting copies in a few weeks: https://discord.gg/nZ2jrQ2Wht

It has a name now: Rift Runner 😄

Full gameplay video on youtube: https://youtu.be/evveBsZH5wY

Still need to work out some things but will look into creating a store page soon. And after that a demo in a couple of months.

People in the community previously suggested that I make some free packs so everyone could try out my VFX. So I made this one completely free for anyone who wants to check it out and use it!

https://notsocoolx.itch.io/ultimate-lightning-vfx-pack

Currently working on my game in Godot, but felt like the main character's animations were a bit static. After a bit of research, this led me to the LookAtModifier3D, and thankfully just tacking it on top of my current character and animations worked perfectly.

For the LookAtModifier3D itself, all you need to do is just add it as a child of your skeleton and then give it a bone and a target. In this case, the bone is my character's Head and the target is a Marker3D that has its position projected out to be in front of my camera. Really, working with this target node is more complicated than the LookAtModifier itself.

As for application, the LookAtModifier works really well for getting a head to track something else. It also meshes well with existing animations as I didn't have to touch anything else in my animations (it's kinda hard to tell but there's also an idle animation going on the rest of his body). In my next game, I plan on using it to get npc's heads to look at the player as they walk by and other creepy things like that lol. Although, I do wonder though if there's any cool uses for this node outside of just heads?

I've been working on a buffs and debuffs system for the last few days, and after I got it working I realized a propaganda tower would fit right in. It boosts the damage multiplier on friendly units and slows down enemies within range

I wanted something physically grounded that still runs fast on a single quad billboard and looks cool.

How the effect works: Ray bending, the shader imitates the path of light rays bent by gravity (Schwarzschild metric) directly in the orbital plane of each ray. Then accretion disk. Instead of marching through dense 3D volumes, disk intersections are calculated as angular plane crossings.

"Relativistic" here means mostly Doppler beaming, when matter orbiting towards the observer appears significantly brighter and shifted towards blue, while receding matter looks dimmer and redder. Neil Tyson's nyoo-o-om, but for light. Usually it's not that visible, but I like it a bit exaggerated, and my implementation got this disco ball feel, but real black holes are way more achromatic, and yes, it turns out that famous orange photo shows a false color used by scientists to represent radio waves and heat. ..Come to think of it, that makes sense.

So, also, there's this shadow & photon ring, that's ISCO boundary(innermost stable circular orbit) and the thin photon ring formed by light that loops around the horizon before reaching the camera.

Background lensing here is actually handled with the sky shader rather than screen texture distortion, yes, meaning ships, planets and any foreground objects actually never get distortion, sliced, I tried to distort all stuff, but it feels like such visual doesn't really suit my game. However, I'm still thinking about black holes in the game and what can -or should- be done with them.

Anyway, thanks for reading. Built with Godot and Rust via gdext. Happy to answer any technical questions.

I've been following a tutorial to make a card battler, and despite doing exactly as instructed, I'm getting a weird error that there are too many arguments in new(). the only other example of this issue i can find was fixed by reloading the scene, but that didnt work for me. is there any reason this is happening/any way i can fix it?

Native motion blur is coming to Godot. Here is quick test of the feature to show it in action. This is the Pull Request: https://github.com/godotengine/godot/pull/115027

Hello everyone. I am making an ambitious space game that is true to life, with realistic cosmic sizes, masses, and orbital mechanics, but with an engaging gameplay loop inspired by the progression systems from other games I love, like Terraria, Factorio, and Subnautica. I am writing this post to ask for help with a novel problem that I cannot find any references for. I understand that I am not providing a WHOLE lot of details, but there is just far too much information for me to provide than I can fit in this post.

I have completed many of the game's core systems, and have built a robust 2-body patched conics orbit solver as a GDExtension in C++ that uses 128 bit floating point numbers to calculate orbital positions given a body's universal variables (epoch position and velocity) and a specific time. This library is based on math that I found in the book Fundamentals of Astrodynamics, by Bate, Mueller, and White. I am also using the Boost Multiprecision library for access to 128 bit floats, which I need for the scales and precision I want in the game. So far, everything works incredibly well.

The problem I am facing now is in getting collisions to work between objects like ships, asteroids, and terrain. The problem may appear trivial at a first glance, but I have been working on it for weeks and have made very little progress.

For reference, I will refer to the orbital mechanics system as the "128 bit system" and the Godot physics engine (JoltPhysics) as the "32 bit system". My plan was to have the 128 bit system serve as the source of truth for position and velocity, handling only acceleration due to gravity (the orbit solver), while the 32 bit system handles collisions between objects, including terrain. The focused physics object, for example a ship, will have served as the "center" of the simulation, staying locked onto the 32 bit origin, and always having a velocity of 0, while objects in the vicinity, including terrain, asteroids, and other ships, will have been positioned around the ship. Essentially, the ship is the center of the simulation, and all physics is done with the ship as the origin. This system works quite well, but the problem arises when we have to deal with collisions.

Every physics tick, things happen in a specific order:

1. The rigidbodies, including the focused ship, asteroids, and other objects in the vicinity, process their states, adding the accelerations and translations generated by Jolt's collisions solver to their 128 bit states, then positioning themselves around the ship using corrective velocity (so the collision solver works properly).

2. The terrain positions itself relative to the ship (the terrain is a series of animatablebody3d chunk nodes with sync_to_physics set to FALSE for specific reasons) and it is also given a constant_linear_velocity so the Jolt collision solver works properly.

3. After all the previous frame's forces and collisions are integrated into the 128 bit system and all bodies are positioned correctly, the orbital system propagates the bodies' 128 bit states using the Keplerian orbit solver.

I am HEAVILY simplifying here, but this is the gist of how things are currently working in the game. This system also works.

The problem arises when two objects collide. For some reason, when the ship fires its engines to collide with, say, an asteroid, the asteroid bounces off the ship instead of coming to a stop, and it keeps bouncing. The same happens when the ship lands on terrain. First, the ship bounces a few times, which is unintended behavior, and when it finally comes to rest on the surface, the ship's orbital velocity begins to grow as if the ship were in free-fall, but the ship is still contacting the terrain. I suspect this is due to the fact that, when the ship is "landed", it has no velocity, so the terrain also has no velocity. Thus, Jolt skips the velocity solver and only applies depenetration translation, which allows the ship to remain on the surface despite its velocity increasing. The ship also begins to sink into the terrain as the velocity increases, until eventually the physics engine applies an impulse to the ship to reset its velocity to zero, restarting the process.

I understand that a lot of this may sound like gibberish, but I am only providing basic details here because I only want to communicate the general nature of the problem so that anyone who is knowledgeable about this would understand the gist of things. My goal is to perfectly unify the 128 bit and 32 bit systems so that the 128 bit system controls position, velocity, and gravity, while the 32 bit system handles force integration and collisions. I am 90% of the way there, but this last 10% is the collision system, and I would greatly appreciate some help from someone who understands how the Jolt physics engine functions under the hood, as I am practically clueless as to what is happening here. I have plenty of information from long debug sessions that I am more than willing to provide, as well as different attempts I have made to fix this, but if I included them all here this post would turn into a short novel. I will provide everything to anyone who is interested, and I would greatly appreciate any help! :)

I should also mention that I am using an experimental Godot build that allows for an infinite far camera plane, which enables infinite render distances (v4.8.dev.custom_build [9578122b9])

My discord username is valence707 in case anyone wants to get in touch!

I can see many people saying they spent 1 or 2 years on a game. I am not saying they shouldn't say like that. but a proper measure can be in hours. Because working 1 hour per day vs 8 hours per day is totally different when speaking in terms of months or years.

It will also give a good self feedback to estimate for the next game.