I'm relatively new to both Blender and Unity, and for the past couple days I've been trying to figure out when to use each one. So I was curious to see what the communities thoughts were. During 3D game development, when should you be using Blender and when should you be using Unity? And just to be clear, I'm asking this with the assumption that often times, both are used throughout game development, but on what tasks in particular do you find one more advantageous over the other?
You make it seem as though that's a hard set rule, but I feel like there are many exceptions to that rule.
There are tools that enables modelling in Unity, but feature wise they pale in comparison to Blender. For prototyping stuff, it's usually done directly in Unity.
Typically, I use only Unity in the early stages of development, using primitive shapes and prototyping tools. Once the gameplay and overall form of the game becomes clearer, then I start using Blender to model.
You use blender to create assets and animations, and unity to place them in the level. Well, I think some people make levels in blender, but this one is going to be more difficult. UNity has rudimentary tools for modeling and animation (animation thing is built-in, modeling is available through probuilder, sabrecsg and so on). Some people used them to create game levels. However, that does not mean it is a good idea. Blender is more efficient for that. It is worth mentioning that SabreCSG can still be useful for intiial blocking out of the level.
Tools in the toolbelt. Don't focus on tools and theorize about how and when to use them. Focus on problems, and imagine the tools you need to solve these problems. Then all you got to do is pick the best tool. Way easier to stay productive this way. Then there is no question of, "should I use probuilder or blender?" The question is, "I need a model that does precisely this. Now which tool can make that happen best?" You see? More precision.
Good answer I like it. In that case, in your opinion, I need something to specifically create specific predefined (already have the mapped data) landscapes and planets. What program is best suited for this. I see a lot of stuff showing Unity being used for landscapes and planets, but I can't help but think I might be missing something and that maybe that is the incorrect route. Thoughts?
Yeah I see your point. I think the levels aspect of the design is where I get the most confused though. Like I can understand making a character or small static component in Blender, but when it comes to terrains or entire planets, which one should someone be using. I feel like I'm seeing a lot of content showing how to make terrains and planets in Unity, but is this really the best option?
You can use both. Unreal engine documentation had a nice example of creating a level, which goes through iteration. I've not seen an equivalent tutorial in unity, although it may exist: You start with blocked out level, run around it and see if everything is right, from the point of movement, size, and so on. https://docs.unrealengine.com/en-US/Resources/ContentExamples/LevelDesign/1/index.htmlThen you make meshes for the level pieces: https://docs.unrealengine.com/en-US/Resources/ContentExamples/LevelDesign/2/index.html Then you configure the lighting correctly: https://docs.unrealengine.com/en-US/Resources/ContentExamples/LevelDesign/3/index.html And then polish whatever is still not quite right: https://docs.unrealengine.com/en-US/Resources/ContentExamples/LevelDesign/4/index.html It would be the same in pretty much any game engine. In case of unity, you can do the same thing - block out in editor, and then create pieces in blender. It is also possible to create the whole level in blender, though, because fbx exporter understands linked objects (Alt+D), and creates references which will use the same mesh in the final result. You'll still need to setup colliders and the like though. Additionally, you can automate some tasks using scripts based on asset post processor: https://docs.unity3d.com/ScriptReference/AssetPostprocessor.html