Hello I'm not sure that this is the absolutely best part of the forum to post this, but a good approximation nontheless I've found some tutors regarding how to create (low-poly) game models, and some on how to load and animate them in code, but no describing the road between (animating in the modeling application, converting them to a suitable format and so on). Many posts describes "programmer art" as ugly or as I've seen here on GameDev "a Bad Thing™". Nothing can be more wrong. As I'm a hobbyist game programmer (or trying to be), I can't afford having a professional artist working for me. Moreover I wouldn't in any way want to. I want to do everything myself as I see it as "my project" where I want to author everything. Some see the talents of an artist and those of a programmer "mutually exlusive". I know that I'm not the greatest artist in the world, and I'm very skilled in drawing by hand, but thats a training question. I have an (if I might say so) artiscally trained eye, phantasy and visions, and using the computer as a tool of interface to the art I am only limited of what I can think (and sometimes the tools, that are not perfect). One other thing proving that "programmers cannot be artists" is wrong, is that there has already been people good in both mathematics and art. Two names that immediately comes to my mind are Leonardo da Vinci and Piet Hein (the latter is maybe not known outside Scandinavia where he came from, and where I live). Both of them were highly skilled mathematicians and scientists (and totally consumed with what they were doing). In the same way both of them were philosophers and artist (Piet Hein was also a poet). Leonardo da Vinci created helicopters and painted Mona Lisa. Piet Hein invented complicated board games, studied Theoretical Physics and wrote "grooks" (small poems accompanied by a picture) but was also a furniture designer, and worked with architects. In both areas he made extensive use of the "super-ellipse", a rounded square, a shape he invented. I'm not hereby saying that I AM Leonardo da Vince or Piet Hein, nor that I have their skills, just that I may have inherited the ability to be skillful in both areas, how divided they may be. Thus I want a full-fledged tutorial containing everything, I mean EVERYTHING, I need to know to create a model, animate and texture it properly (within the original 3D animation program), convert it to a suitable file format, load it within my game accompanied by the textures (who should also have the possibility to be multiple and animated), place it at some point X,Y,Z in the game space and there playback a given animation (if desired). For example: Preferred tools are: Blender (2.40) or Maya 7 PLE (I have both) Language: C++ (Visual Studio 2005 Beta 2 if you're interested) Graphics API: OpenGL interfaced via SDL for simplicity's and portability's sake; SDL can import any image you want easily. The tutorial does not necessarily have to written using SDL, I understand how to changed code parts as needed. I won't copy the code straight-off anyway, because then I won't learn anything from it. Regards, Stefanos [Edited by - jagot on November 19, 2005 7:20:05 AM]

I'd like to see something similar myself.

Also, you'll probably want to stick with Blender as I don't think maya PLE will export.

No Maya 7 PLE won't export, it just saves in the
internal .mb format.
But there may be converters on the net.

Wanting a single tutorial to walk you through all that shows a severe lack independance, to my mind. There are tutorials and books that will teach you all of that. Just not all at once. So you'll just have to experiment won't you, just give things a go.

Alright, there are blender tutorials, so that's not a problem. As for how to export, seeing as you want to code as well, learn python. There's plenty of tutorials for that too, and blender exporters are written in it. Heck, I don't know python and I had no trouble with a simple exporter, using an existing one as a base of course. It's quite refreshing after so much c++. Which it looks like you know at least a bit of. So, having exported the file in your own format, you should have a pretty good idea of how to import it in your program. From there, theres plenty of tutorials on either of the main 3d api's. Like NeHe, hosted (and now owned) by GameDev.net. The skeletal animation your bound to want is where it gets difficult. Best to get a book. And if you get stuck, isn't that what these forums are for? Among other things of course.

I, for one, am glad there aren't tutorials that walk you through the whole thing. It's bad for people's mental health. A challenge is a good thing.

EDIT: Btw, your render function is missing the brackets (). Leaves me less sure about the knowing a bit of c++ thing... And yes, I am being a bit harsh. Please don't take it personally.

Well, why do you do all those intermediatary steps if you pretty much are telling us that you want the code to be of the "model->dothis" type format. Why not just take get a prefabricated MD2 or MD3 importer, that will generate a mesh based on a file?

Well, I didn't outright say that I wanted one single tutorial, or at least I didn't mean that way. A series of tutorials might be a better description.
Tutorials of programming or modeling is not what I wanted either.


There's no bad in thinking yourself, and as you've probably noted I'd like to write the code myself, but as I have no idea of how to use an object I've created, modeled, animated (by joints and rigging) and so forth. Therefore I'd like detailed guidelines. Not heaps of source code, butdescriptions of how it all works.
For example:

• How do I know which faces are the front and back so I know which to cull?
  
• How do I animate them in eg. Blender, using Blender's internal animation?
  
• When I've animated the object, how do I playback more than one animation at once? Do I have to copy an animation controling one part of the body to every other animation it is likely to coexist with?
  
• How do I know which format that's best? (What's the pros and cons?)
  
• Will the materials I create in Blender be preserved in the file so that I can extract the information about ambiance, diffuse, specularity, alpha and so on?
  
• What about the UVs (matching the glTexCoords)?
  

You said "The skeletal animation your bound to want is where it gets difficult. Best to get a book.". Well which book? Expressing the importance of a book but not giving any examples is not beeing any helpful. I've found a lot of good tutorials from both ends, like "Learn how to texture map your game character in Maya" (Michael McKinley at www.mtmckinley.net is wonderful at those points) and "How to load a [insert format here] model into your program", a bit about displaying it, and even animating it, but no thorough description about how it works. Often it has been like "use this library", and that's not the way I want it. As of now I see modeling and programming as two lighted areas, with the path between them, not fogged, but more of darkened by the night. You could also say two hilltops parted by a huge canyon, with no bridge in sight. What I need is tutorials (or books) as a torch lighting up the path, building a bridge between the hilltops.


And writing Python scripts for Blender myself, Yuck! I don't like scripts at all, and will avoid tamper with that kind of things as long as possible. Not to mention I have to learn how Blender works internally, which wasn't my wish.
Regarding the class arcitechture of the model handler (in-code), I'm not sure that's the best way, that was just an example. I just like to separate different things in classes.


And lastly about the parenthesis, I've changed them now; and I didn't take it personally RAZORUNREAL, because I know you're most likely to have done that mistake yourself, several times. It would have shown up at compile time anyway (and I'm not sure if I would design the Render function as a void taking no parameters).


Your nice comments really makes me love you all guys! :P
Have a nice day


Stefanos

Whoa, I changed my mind a bit.
Developing an own/some own file format(s) could be interesting.
But the scripting is no more appealing, anyway.

Nonetheless, I'd still like to know about proprietary formats.
Regards
Stefanos