Jump to content

  • Log In with Google      Sign In   
  • Create Account


Foundations of 3D Game development tutorial(s) ?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 murdock   Members   -  Reputation: 133

Like
0Likes
Like

Posted 20 May 2014 - 01:42 PM

I've been working primarily in 2D games for the last few years off and on, and have decided I'd like to take a crack at doing 3D development.  My problem is that I have several questions and I'm not sure where to start looking for answers.

 

For example, I am pretty sure that in 3D development you have a scene that uses a scene graph to store all the objects in the "world."  This is where all your models would be stored.  

 

Now when I go to build/import models into that world and store them, what do I need to have in my model?  I am under the impression that this is a model that is built in blender or some similar application.  Do I need to have the modeler add animations, rigging, etc?  In other words, what do I need to know in order to speak intelligently with a 3D modeler to request game assets?  Also if my scene is a town, do I need to make the town one big model or can I break it up into smaller models?

 

These are a few of the questions that I have and would like to find a good resource where I can do some self study.



Sponsor:

#2 ApochPiQ   Moderators   -  Reputation: 14291

Like
5Likes
Like

Posted 20 May 2014 - 02:49 PM

This rabbit hole can go pretty deep, so really it's up to you as to how far you want to go, and how fast.

 

There are many different ways of storing, manipulating, and ultimately drawing 3D assets, and the technical details vary widely between projects. Scenegraphs are one approach that is fairly common, but there are other methods as well, which may or may not be suitable depending on your needs. Animation systems are as diverse as snowflakes. You can easily specialize in nothing but animation programming and have a solid workload for the duration of a project.

 

It also depends a lot on what environment you expect to be working in. If you're talking about solo projects, or small team collaborations, you can pretty much expect to have to understand a lot of artist lingo to get things done. In larger teams, it's easier to hide and let other people deal with the tidbits you aren't interested in :-)

 

Ultimately, a lot of best practices vary by engine and team, and you will almost always be learning in some way or another.

 

 

With all that disclaimer boilerplate out of the way, I'll address some of your specific questions.

 

Models and animations can be stored separately. Generally a model is just a mesh, skin details, and texture/material details. You then combine this with an animation rig (totally separate beast) and dynamically re-skin the mesh as the animation changes the pose of the model. There's a lot of moving parts in these systems (no pun intended) and a lot to study up on.

 

Modelers and animators are often separate people, because they are very different skill sets. On large teams models are typically handed off to animators, or handed back and forth and refined over time until a final asset is ready. Smaller teams may see these roles taken on by a single individual, but it's rare to find someone who is really good at both.

 

Requesting assets is going to depend almost entirely on your tool pipeline and engine. At a minimum you should be able to provide an artist with an exporter or converter that can take data directly from a popular tool (or file format) and prepare it for use in your engine. Most engines come with this stuff, so until you're deep in roll-your-own territory, this isn't much of a big deal. The specifics of all this are going to change heavily based on how your engine of choice is designed, so be prepared to learn several approaches and hate most of them ;-)

 

As for the town scene: it is generally advisable to compose large things out of small things. If you have a building, store it as a building model. If you have chairs and tables, each should be a separate model. This is good for a number of reasons (reuse of assets, runtime resource instancing, and so on) that will become clearer with a little experience. Sticking everything into a giant monolithic model is often referred to as "baking" and is generally a bad idea, with some very specialized exceptions. (You'll know it when you run into one.)

 

 

 

If you're interested in the art/code interface, there are two things I'd suggest. First, lurk on forums dedicated to modeling or animation. You'll find lots of terms that you'll need to look up, and lots of general ideas for how things are done. Second, get ahold of an engine like Unity, Unreal, or even an older one like Source, and look at how their tools and asset pipelines work.

 

Most teams won't really talk much about their asset pipelines, but that's typically because pipelines are hard to do well and people routinely make bad ones. However, if you can, pick the brains of some tools developers from major studios. You'll learn a ton about how things work and what to do (and not to do).



#3 murdock   Members   -  Reputation: 133

Like
0Likes
Like

Posted 20 May 2014 - 02:54 PM

I'm actually going to be building a game using Unity.  The goal is to ultimately have a 3D game; however, I'll be taking it slowly and using the game as my classroom so to speak. 

 

Now is there a difference between rigging and animating?

 

Thank you for answering my questions. 


Edited by murdock, 20 May 2014 - 02:58 PM.


#4 ApochPiQ   Moderators   -  Reputation: 14291

Like
4Likes
Like

Posted 20 May 2014 - 03:01 PM

"Rigging" generally refers to setting up the skeleton of bones, and connecting them in relevant ways to the mesh. "Animating" is a broader term that includes a lot of animation-related activities in some cases, but is also used to refer specifically to making the sequences of motion that will eventually be displayed.

 

Going with Unity is a good advantage since there are ample artists out there who know how to build assets for that engine. This gives you time to get the other fundamentals down without having to dive too deep into esoterica like file formats, exporter plugins, data conversion systems, and so on. Of course should you find any of that stuff interesting there is always a chance to dig into it as far as you'd like.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS