If I were to recreate the story of seasons friends of mineral town game farm as a scene, should I make the entire level in blender and import it with all static meshes (house, chicken coop, barn, etc.) as a single mesh? Or would it be better to create each mesh separate and import as separate nodes?
I’m struggling to understand the benefits either way. Would doing it either way significantly hinder or benefit me down the line? Is there an ‘industry standard’ in this regard?
I thought it would be helpful to recreate a game I love to get familiar with aspects of godot, blender, etc. before creating my own games. I’m finding there are lots of different ways to implement different ideas but am struggling to understand if one way is better than another.
I had originally thought to create 3d tilesets to build the levels out from, but chat gpt said that typically for 3d games you typically wouldn’t use tilesets and would instead use 3d models for everything including ground terrain. Would anyone like to elaborate on why this is? It seems like it would be less work when creating relatively flat levels such as in the story of season game and probably wouldn’t hinder performance since each scene is a predefined area and you aren’t having to load tons of tiles all at once. While asking AI is nice for immediate feedback and finding resources on certain topics quickly, it’s not as good as someone who really understands what they’re doing.
Maybe there is a built-in terrain painting system in Godot that I just don’t know about that would do this better than any above mentioned idea.
If you create your entire map as a single mesh, then your entire map is always drawn if any of the map is visible. If you compose your map of individual meshes, then Godot can cull the meshes that are not visible. You also have easier access to alter parts of your map on the fly.
I’m not a professional, but I have experimented with both approaches and found that composing maps from individual objects is far superior for my games than the all-eggs-in-one basket approach.
Thank you for the input. That makes sense. I’m messing around with the idea of mixing 2D textures with a collision node for most of the ground (since most of the ground tiles will be flat) in addition to adding 3d objects such as slopes/ramps/stairs etc for other terrain areas such as mountains for the areas that the elevation would change. Then importing and manually placing the 3D assets such as trees, boulders, houses, etc on top of the tiles. I assume this is possible and would cut down on poly counts for performance.
Does this seem like a good idea to you or like it would be overly-complicated? I’m having a rough time understanding the 3d level making workflow in godot but I think I’m starting to get a picture of how it works.
Keeping in mind your above post, having the game floor setup in tiles and meshes setup individually for things like houses and trees would allow me to cull the ones (I assume using some kind of buffer zone) outside of the viewport so that it’s not being drawn which could save resources. (I know I’m parroting but I’m hoping to confirm that I have a working understanding of the concept).
Yes, that it a good approach. Don’t overly worry about polygon count for your ground, especially if you’re able to slice it up into separate meshes. I have terrain with 500,000 triangles separated into sixteen sections with each section wrapped in a static collision mesh, and the game is fluid on hardware as low as the Quest 2 and 3. Typically, about eight sections are seen by the camera at any given point in time, meaning that half the terrain is culled most of the time.
My game isn’t polygon-heavy at this point, with my characters and other objects in my map probably only adding about another 50,000 quads so far, but the gameplay is smooth on both the Quests and the desktops I’m testing it on.