Yeah but an easier solution would probably be to create software that can aid in the creation of character know matter what they be.

yeah im working on makehuman after many hours of labor the software would be aimed towards game designers well that the ideal anyways theat like way into the future

Why x? The x file format, like AP pointed out, is (only) useful with direct x. Why not use the milkshape or the blender file format? Both are relative free to use(refering to milkshape here) and as a programmer it shouldn't be that hard to write a exporter/converter for your game.
my 5 cents

Quote:

Original post by sirGustav Why x? The x file format, like AP pointed out, is (only) useful with direct x.

There's nothing stopping your from using .x files with OpenGL.

If you're really serious about this, the format that springs to mind would be Collada. (.dae) Atleast you can import that into most graphic tools and then export it any way you want.

Quote:

I can't say I think its a good idea, or even support it. .... artists are not really willing to see their hard work used in another game

When I said that it seems it's the artists who don't want to share, I was making a toung-in-cheek comment to get some momentum behind the topic and prompt some discussion. Perhaps there is, however, some literal truth to this!!

For the record... Yes. I *am* talking about a library of free art which could be used in released games. Just like the programmers do with their code and the sound guys do with their samples and music.

I would be more than happy to see a couple of my models used in other people's games. I would be proud to be supporting the community and helping other amature developers realise thier game design visions. Yes, the content may be subpar but at least it *is* available content. I have honestly lost count of the number of times I've started developing a game, got the design balanced out on paper, coded a basic engine that supports the graphics & sound requirements, network code, user input etc. only to have all the passion and motivation knocked out of me at the 3D character content stage!

A few people have mentioned turbosuqiud which was my primary place to find 3D content, however I started this topic to address the problem of the models not being even remotely standardised.

You raised a good point about poly count. We're obviously looking at low-poly content here and looking to create it using either free or low-cost tools. gameSpace Light is free to download and has no time restrictions. It is restricted to not exporting models with over 650 polygons, and it will only export to the .x format. There are, of course, plenty of other free and low cost tools which have none of these restrictions, but it's as good a guide as any.


So, for those of you who are not offended by the idea...

Here's where we're at so far:

* standard skeleton. (please PM me if yo uhave one to submit, if no-one does I will try to make one when I have some time)
* .x model
* 1 3D unit = 1cm
* poly-count around the 650 mark (or less)
* texture files (.bmp format?)
* text / data file file (contating: bone names, animation names & frame numbers)
* all held in a zip file named by model name and version number
* the following animations should be included as a minimum: stand idle, run, jump, attack, die ... with as many extras as desired. (Jump should be a fixed-position movement leaving the actual 'up & down' motion to the game engine.)

If there are any fundamental flaws or ommisions from the above list, please discuss it!

sorry guys... hadn't seen the two posts about the .x format when I started writing the above!

Thanks for your input, it's all good to know.

I only initially suggested the .x format because it's very common, and if another format is desired plenty of converters support .x

I have attempted to look at the Collada website, but I couldn't get through, I will try again later. What benefits does this format have over .x? Which free / low-cost modeling tools support it?

Wouldn't obj be a better format?

As for code/sound vs. art for the community, like I said, art is a much more personalized, and often more laborous, aspect of development. While a sound designer might make 12 tracks, and use 9 of them for the game, and give away 3 of them to the community, an artist almost never creates a character that isn't actually used in release. It also takes longer to create a character than it does to write a song. As far as programming goes, programmers take other people's codes to do specific things, and adapt them. Its sort of like taking a head off of a model to use it on another one, not using the entire model... the original blueprint is there, but it is unrecognizable enough that most poeple probably wouldn't notice right away. And in addition to that there is the specificity of art as I mentioned before.

I would suggest that instead of putting your eggs in the basket of getting new content, work on standardizing already free, unlicensed content. Little, if anything, you get, is going to be much better than that on turbosquid.

I also suggest that you don't make the library available to use in releases (or make two libraries), you're much more likely to get good, clean, standardized content from artists.

I agree that .obj would be a much better format.

I dont understand the idea that 1 3d unit = 1 CM. If I do something in silo, export it to maya and compare the number of '3d units' it takes up on screen the thing goes off the graph in maya, whereas in silo its maybe 20 '3d units' tall.

Furthermore, object orientation is off between certain programs.

My suggestion; models should be standardised within a single program (should be free), I suggest blender or wings3D. Doing this will make sure that the '3d unit' is actually a standardised unit. Furthermore, both programs export .obj (which is arguably a much more versatile format, in case the author wants to edit or something)

-slowpid

Quote:

Original post by slowpid I dont understand the idea that 1 3d unit = 1 CM. If I do something in silo, export it to maya and compare the number of '3d units' it takes up on screen the thing goes off the graph in maya, whereas in silo its maybe 20 '3d units' tall.

Are you saying that if you make something in silo which is 20 units tall, and then open it in maya, the numbers have changed it becomes 40 (or however many) units tall? I assume that this is not the case and that each program simply has a different default zoom level.

If you make, say, a 'human wizard' character that's 200 units tall and a 'dwarf fighter' that's 100 units tall, once loaded in the game engine the dwarf will be half the height of the human. One program may portray these characters as huge while another program shows them to be tiny, but the dwarf will always be half the height of the human. It's the *ratio* that's consistent. If, on the other hand, you make a human character I make a dwarf, your human might be only 50 units tall while my dwarf is 200 units tall.

Quote:

Original post by Professor420 Little, if anything, you get, is going to be much better than that on turbosquid.

Professor420, I think we are possibly viewing this 'free 3D character collection' thing from two very different angles. I am not expecting anything "much better" than the free content on turbosquid. In fact, I would almost be plesantly surprised if anyone submitted work of equivalent quality to the models on turbosquid.

In my original opening gambit I said that I am an amature game developer working on a few projects in my spare time. This is often solo work, and involves being project manager, writer, designer, coder, 2D artist, 3D artist, musician and sound technician all at once. I do not consider myself to be a 3D artist, but it is one of the many rolls I must attempt to fill. As you say, 3D artwork is often very laborious and given that I have only a little free time to spend developing games, a single character could well take me the best part of a month even if I spent no time coding or working on game designs.

Let's say I needed 15 characters for my game - that equates to over a year doing nothing but modeling! Nothing. Not a single line of code written, not one aspect of the game's player interactions developed. Nothing! I can't work like this - I doubt any of us could.

I'm merely suggesting that of all the amature and hobbyist game developers here at GameDev.Net there must be quite a lot in the same boat as me (this is certainly true of the few members I know). If if just some of us within that group each submitted a model that we'd knoced together over a couple of weekends then we'd soon build a small library of models that are *relatively* standardised and could be dropped into each other's games with minimal adjustments. This, I believe, would help cut that year-long hurdle on the development cycle down to a manageable size.

I'm certainly not suggesting that any professional should lose income by giving their work away from free or that any development company should jepordise the future of one of its games by releasing all the 3D character content into the hobbyist community.

so you know that one of the grid square in maya = 1 grid square in silo AND 1 in wings AND 1 in blender?

You have absolutley no frame of reference to judge this with. The models might go in the same size, but these are arbitrary numbers once inside the program.

Think it over, you'll get it eventually.

Quote:

Original post by slowpid so you know that one of the grid square in maya = 1 grid square in silo AND 1 in wings AND 1 in blender? You have absolutley no frame of reference to judge this with. The models might go in the same size, but these are arbitrary numbers once inside the program. Think it over, you'll get it eventually.

He's coming at this from a programmer's perspective. 3D formats generally store vertex information as a set of unitless floating point numbers. It's these numbers he is talking about, not the (as you point out) arbitrary grids and scales used by modeling packages. He's just suggesting a convention to attach a common unit to the numbers in the file format so that they will be consistent between all the files.

That way if I load two models into my game engine I know they will use the same scale. A single model loaded into multiple modeling apps will have a different scale in each of them depending on what default scale they applied to the unitless numbers in the model file. If you are creating your models based on the grids in the app you will need to determine what scale they are using and do the conversion yourself. Say for example that one app puts a grid line every 100 units, then you know that the grid lines are a meter apart. If another app puts them 1 unit apart then you know that the grid lines are one cm apart. Some apps will allow you to adjust the grid spacing yourself.

To the OP: Sounds like a great idea if you can get it off the ground. I know as a programmer it takes me a very long time to produce even programmer level artwork. It's difficult to show off graphics code without decent artwork. Your project reminds me of Open3Dproject.org, they are trying to do open source 3d artwork, but with high poly models.

Good luck.