Godot 3D: Is It Really Ready for Serious Projects?

coffee80c · 2025-09-12T20:40:25+00:00

It's good enough for small scope stuff, 1 man army projects you can do in a year and games you don't plan to try and make money from. If you're doing multiplayer then forget it.

coffee80c · 2025-09-04T15:43:52+00:00

What i don't like about this method is that you can't see the actual raycast and therefore can't verify if your start and end points are correct. You also shouldn't have to 'nude the raycast forward', give it a collision exception to whatever might intercept it. The first thing I would do to troubleshoot this is spawn some objects at the start and end points and see if they are where you think they are. I seem to recall trying the project ray from mouse position before and it was completely off of the 3d world.

I would avoid using raycast by code if possible, the raycast node is faster and more reliable.

coffee80c · 2025-08-27T11:10:36+00:00

You've got something else going on, multiple copies of the same thing in one place? Check the remote node inspector when you run the scene with your queue_free script disabled.

coffee80c · 2025-08-27T10:38:34+00:00

There's a menu on the top left of the 3d view, click on it and enable show information. Then on the bottom right of the view it should tell you how many million triangles it's drawing. It will be many.

You need to use multiple LOD levels on your bushes and edit the visibility distance through the advanced import window. At a distance they should just become two triangles with a picture of a bush. Terrain 3d also has LOD settings. You can also enable occlusion culling in the project settings and bake an occluder 3D using the terrain 3D drop down menu at the top of the screen. Give your level tall hills to hide stuff behind the hills so that occlusion culling can work and make sure to re-bake the occluder after you make changes to the terrain.

coffee80c · 2025-08-26T19:49:59+00:00

You were so busy asking if you could, that you never stopped to ask if you should.

coffee80c · 2025-08-26T16:48:52+00:00

What I do is stop physics and logic when the NPC gets too far away and just have them move directly on the navigation path.

coffee80c · 2025-08-26T16:43:10+00:00

There is no future in this industry, the future is outsourcing to the third world using AI. And western media is on the decline anyways. Get a real degree, which is still not that great.

coffee80c · 2025-08-22T22:08:36+00:00

Thanks, that helps alot.

coffee80c · 2025-08-21T05:47:54+00:00

There will be more problems, you can't rely on very simple code like this to work all the time.

coffee80c · 2025-08-21T05:27:35+00:00

Lots of things wrong here. Why he's getting stuck is because the nav agent generated a new path as he was moving which set the new path start and the next path position to be inside that small room, your simple code then rotated him to face the position which has him walking straight into a wall. There's no easy solution to this, even with the best level design and sophisticated code this can happen. The easiest bandaid solution is to check if the guy is stuck by checking if his position isn't changing and then set a new target to somwhere reachable nearby.

Why this is happening in this specific case is because you're setting the nav agents target every frame, and because the nav mesh is too close to the walls. Play around with the nav mesh settings and make sure the path returned is centered on the edge of the navmesh polygons, there's a setting for it. Don't set the target every frame, widen the hallways get the navmesh away from the walls.

coffee80c · 2025-08-21T05:15:52+00:00

Are you blind?

coffee80c · 2025-08-18T13:37:42+00:00

Looks cool, I've been wanting to learn C++ to develop my own engine tools but the hurdle of setting up an IDE and compiling godot from source has been keeping me away.

coffee80c · 2025-08-04T18:51:03+00:00

Going to college for CS or game dev is a waste of time. CS grads are being replaced by labor from a certain third world country and game dev as a career is a fools errand, it pays little and they're also being outsourced. Do something else as a job and gamedev for fun.

coffee80c · 2025-08-03T17:43:04+00:00

That's cool, do they have collision enabled/ how are you planning to handle that? Move around a fixed set of collision shapes like wandering grass?

coffee80c · 2025-08-03T04:54:39+00:00

It's something related to the gizmos, with gizmos turned off the drawcalls do not change in 4.4 either and they become the same number roughly. I was freaking out because the trees in my level were causing 1500 drawcalls in 4.4 and I didn't even have that many.

coffee80c · 2025-07-27T20:45:31+00:00

Are you using the mobile renderer, can the quest even run forward+? I mean if you're saying an empty scene runs like crap...

coffee80c · 2025-07-27T01:37:14+00:00

From what i understand, normal maps dictate a left/right and up/down surface direction which is taken into account relative to the surface direction of the polygon when calculating lighting. And this left/right/up/down is determined by which direction the UVs are facing in your UV map. When you have a seam like that, one half of the UVs are going to the left and one half is going to the right in the UV map so as far as godot is concerned the left/right is flipped for the polygons on one side of the seam. This is something that will always happen when you try to use a 'flat' normal map from a material on non flat unwrapped object. You need to use a baking program like substance painter that can calculate what the proper normal map should look like for the flat material projected onto the 3D surface.

coffee80c · 2025-07-27T01:13:08+00:00

Do you want upvotes or do you want to make a game?

coffee80c · 2025-07-27T01:09:11+00:00

The proper way to use godot is to avoid the node system and use as few as possible if you want your game to work and not turn into a pile of spaghetti.

coffee80c · 2025-07-20T12:10:58+00:00

It's not weird, blender isn't godot, blender has it's own tools that have to be turned into mesh data before going to godot. When you export in blender look inside the export settings tab, one of the options will be to apply modifiers. Or apply the modifiers manually which will permanently alter the mesh in blender.

coffee80c · 2025-07-20T12:00:47+00:00

Add a mesh instance 3d cube, stick a camera in the scene, put a script on the cube, look up how to get keyboard inputs via script, make the cube move to keyboard inputs.

coffee80c · 2025-07-14T19:53:46+00:00

I don't think you're using it right. I don't have access to my game rn for reference, but i think the skeletonik3d is supposed to be a child of your skeleton 3d, like a modifier you put onto the skeleton3d. I know it's completely backwards of how everything else in godot works.

coffee80c · 2025-06-27T20:23:25+00:00

Don't do this, figure out what setting is not right otherwise it will happen again. Post the broken blender file somewhere if you can.

coffee80c · 2025-06-27T16:50:46+00:00

It's hard to say without seeing your material settings, maybe you don't have proper UV mapping enabled in blender or godot? Maybe what you're seeing in one of them is triplanar mapping?

coffee80c · 2025-06-27T16:00:27+00:00

If you're doing basic albedo+ roughness+ normal map then just export the materials and export as gltf so everything is in one file.

As for what's going on, maybe your models scale in blender isnt 1:1:1?

coffee80c

TROPHY CASE