new headquarters and modeling - all here now.

[rush2049]

I don't think you will like this, but blender does not save in plain text...

BUT, the format I suggested earlier is a form of text, probably have to decifer it, but it can be done...

I am attaching my HQ before I started texturing it...  not only does the AC3D format have the coordinate data, but it also has the material data also defined in the beggining of the file with:

Code: Select all

MATERIAL "DefaultWhite" rgb 1 1 1  amb 1 1 1  emis 0 0 0   spec 0.5 0.5 0.5  shi 64  trans 0

the object also has other designations before the coordinates are given:

Code: Select all

OBJECT world
kids 1
OBJECT poly
name "Cube.003"
data 8
Cube.001
texture "Untitled"
texrep 0 0
crease 30
numvert 756

these are somewhat self explanatory, I probably should have names the object something better, but ohwell.... (the texture too)

after that it shows all the verticies in the whole object, such as this is one verticie (one verticie per line)

Code: Select all

0.257597 3.736232 0.214302

then after all 756 verticies it says this:

Code: Select all

numsurf 772

then it goes into each surface, some of the numbers I don't know what they signify, so it would have to be figured out but it is mostly self explanatory. a typical surface looks like this:

Code: Select all

SURF 0x00
mat 0
refs 4
6 0.701504290104 0.0425224453211
7 0.701255261898 0.0251039043069
10 0.676501095295 0.0262377336621
9 0.678712546825 0.042609706521

and then at the very end of the file it says this

Code: Select all

kids 0

which signifies children objects, I geuss...



ok coders, I know how to programm a bit and this isn't hard... make the pie format support numbers to this many digets: 0.042609706521    and then we will worry about getting the textures on the faces....

[kage]

are you suggesting any other changes to the pie format aside from adding/modifying the format to support high-precision floats? if there are any other changes to the format, we might as well completely ditch pie, and code in support for some other format, while creating a converter script, or possibly just add full pie-conformance to that blender import script so we can convert existing pies to the new format. and, the only benefit to keeping the model format as plaintext was that the models were simple enough that you often could do hand-tweaking without going insane, but with increasingly complex models, the advantage is lost and binary formats would be better in every way.

[rush2049]

I want to make it easy on the coders, so....  whatever suits what you guy wanna do. The format I outlined is easy to convert to whatever....as that is what we are uploading our models in, so they don't accidentally become lost....

The pie format needs to have increased precision. That is plain to see, but if you want to ditch that and write new code for a lot of parts of the game, I am fine because I don't have to do it. But what I think you should do is increase the precision and in the future implement a method to map a texture to a model, (by assigning individual faces texture coordinates)...  that is sort of what pie files already do with texture pages, but I want a single texture for each model....

again to rephrase, just increase the precision we will worry about texturing later.

[kage]

increased precision, by allowing arbitrary length (but truncated by the engine if too long) floating point numbers in place of ints doesn't hurt the pie format, and it would be fully backwards compatible. doing anything more beyond that, and we should be looking at a new format.

[Giel]

increased precision, by allowing arbitrary length (but truncated by the engine if too long) floating point numbers in place of ints doesn't hurt the pie format, and it would be fully backwards compatible. doing anything more beyond that, and we should be looking at a new format.

Well actually, when looking at those AC3D files it seems those are quite similar to the PIE format itself. So we might even want to consider adopting that format (hoping there's some kind of library that implements it already) because it will save people the work of another conversion step, and thus less errors are to me made.

[DevUrandom]

Because we are discussing model-file-formats again: My idea was to use OGRE's .mesh, for which exporters for all major 3d editors (Blender, 3DSMax, Maya, AC3D, Milkshape) and some more exist.

[Giel]

Because we are discussing model-file-formats again: My idea was to use OGRE's .mesh, for which exporters for all major 3d editors (Blender, 3DSMax, Maya, AC3D, Milkshape) and some more exist.

Sounds good to me. I assume you would just want to use the OGRE libs for parsing these files?

Btw, as a test an attempted conversion (by hand, using some vim magic) of Rush's HQ attached.

EDIT: updated HQ2 PIE object, it now should have correct polygon definitions

[kage]

Because we are discussing model-file-formats again: My idea was to use OGRE's .mesh, for which exporters for all major 3d editors (Blender, 3DSMax, Maya, AC3D, Milkshape) and some more exist.

sounds good to me too, especially if you say that we no longer have to cut the code in half to make room for specific and individual ogre components. question is: aside from the mesh loader, how much work would it take to add support to display .mesh files to even half their potential quality (eg. if .mesh files support procedural textures, what about displaying that in game), or, would the ogre rendering engine be especially workable given gameplay -- it seems to me that ogre has generally been used for fps games and other genres with a high level-of-detail but not a lot of entities on screen, or nothing with a wide view angle.

[Watermelon]

sounds good to me too, especially if you say that we no longer have to cut the code in half to make room for specific and individual ogre components. question is: aside from the mesh loader, how much work would it take to add support to display .mesh files to even half their potential quality (eg. if .mesh files support procedural textures, what about displaying that in game), or, would the ogre rendering engine be especially workable given gameplay -- it seems to me that ogre has generally been used for fps games and other genres with a high level-of-detail but not a lot of entities on screen, or nothing with a wide view angle.

yea I agree with kage that ogre is not optimal for rts games with hundreds of concurrent entities on screen(esp warzone2100 with tons of units on screen when zooming out),probably ogre is good for some first person games of any genre with limited field of view and max view distance.

It seems to me that most GPL-compatible graphics engines are optimized for large outdoor scene rendering with detailed textures and smooth scene management,though they are not very good for rts with virtually no Line Of Sight blocking from 'birdview'.

[Giel]

yea I agree with kage that ogre is not optimal for rts games with hundreds of concurrent entities on screen(esp warzone2100 with tons of units on screen when zooming out),probably ogre is good for some first person games of any genre with limited field of view and max view distance.

It seems to me that most GPL-compatible graphics engines are optimized for large outdoor scene rendering with detailed textures and smooth scene management,though they are not very good for rts with virtually no Line Of Sight blocking from 'birdview'.

Which leaves us at the question, wether it is possible to only use the .mesh loading part of the OGRE lib. (Doesn't matter if we need the entire library but only use part of it, that's a sizing problem which with today's harddisks should be a non-problem.)

[DevUrandom]

Only docs I was able to find on the OGRE formats till now:
http://ogre.cvs.sourceforge.net/*checko ... alizer.cpp
http://ogre.cvs.sourceforge.net/*checko ... erImpl.cpp
http://ogre.cvs.sourceforge.net/*checko ... alizer.cpp

NEW:
http://ogre.cvs.sourceforge.net/*checko ... leFormat.h (THE guide to .mesh)
http://www.ogre3d.org/docs/manual/manual_14.html ("specs")
http://www.ogre3d.org/wiki/index.php/Materials (examples)

NEWER:

yea I agree with kage that ogre is not optimal for rts games with hundreds of concurrent entities on screen(esp warzone2100 with tons of units on screen when zooming out),probably ogre is good for some first person games of any genre with limited field of view and max view distance.

It seems to me that most GPL-compatible graphics engines are optimized for large outdoor scene rendering with detailed textures and smooth scene management,though they are not very good for rts with virtually no Line Of Sight blocking from 'birdview'.

Just have been told by sinbad (OGRE project lead) and others that OGRE is very well used for RTS games in the past and present. They gave 2 examples http://www.supremacygame.com/ and http://www.pacific-storm.net/ and told me that various people, who are going to create RTS games, are active in their support-forums.

[Giel]

NEWER:Just have been told by sinbad (OGRE project lead) and others that OGRE is very well used for RTS games in the past and present. They gave 2 examples http://www.supremacygame.com/ and http://www.pacific-storm.net/ and told me that various people, who are going to create RTS games, are active in their support-forums.

Sounds good. I do however think that we should move only parts of our current code to use OGRE (such as the .mesh file format). I'd personally love to move to such a lib entirely, we must however do it as gradually and incrementally as possible to make sure we have a running system all the way.

[rush2049]

ok I took a look at ogre, and it seems that blender is implementing that render engine into the game simulation part of blender soon anyways....

there is in existance a blender import/export scripts, but they are both out of date and do not support everything.

So I have to wait for blenders team to work on it... but thats allright with me, we can keep posting up our models in ac3d for now, as it is a very wide standard.....  also when blenders support comes I can texture the models with procedural textures and then no more texpages for warzone, YAY...  eventually.

Ok so for now still upload new stuff in ac3d, I can imprt and work on them from there, if we end up using ogre.

[Equal]

ok i read the whole tread and little confused about the whole discusion:
so it would be nice to check all the thinks;

Tools we need for Modeling?
-Bleder
-Rhino
(1 of this 2 or could i use others?)

File format needed to be saved as?
-orge
-ac3d
-pie (still dont get the problem)

Thinks we need to know before editing?
Attachnemt points?
Orientation points?
max lvl of detail (polygons)?

^^ and a Example showing if some one did a new model that you can see this in game.

1 0 X =

[DevUrandom]

ok i read the whole tread and little confused about the whole discusion:
so it would be nice to check all the thinks;

Tools we need for Modeling?
-Bleder
-Rhino
(1 of this 2 or could i use others?)

You may use whatever tool you want. Just make sure that the file you create is AC3D or similar well known format which can be loaded out-of-the-box into Blender.

File format needed to be saved as?
-orge
-ac3d
-pie (still dont get the problem)

This is the problem... For now you best save it as AC3D.
We didn't decide yet on OgreMesh, so this is not the No.1 choice for now.
If you can export a PIE file with your modeling-tool, well, you can do more than the most people I've met till now.
The problem with PIE is that there is no modeling-tool (besides PIESlicer, but that can't read anything else) which is able to export PIE files. Neither exists a converter.