I am way too poor to afford any of the standard 3D modeling packages (even with Maya's new reduced price of only $2000), so I wrote my own from scratch.
Starshatter (at least, this year's version) is probably not the ideal platform for what you want to do. The game engine manages to push about 60,000 polys per second (not per frame) on a P2 400 w/ TNT2 card. It should scale more or less linearly with CPU speed. The game engine does not use hardware T&L. That is an enhancement for another time.
My ship designs typically range from 500 to 2000 polys at the highest LOD. I use only square textures in PCX files, usually about 256x256 for ship textures. Each model can have up to 32 different textures.
Ship models can have any number of components, each of which can have a separate rotation about the model origin.
Skinning and decal-based damage modeling are on my list of things to do next month when I will be concentrating on multiplayer support.
Biggles<font color=#AAFFAA>The Man Without a Face</font>
[quote]Originally posted by milod:
[b]Ship models can have any number of components, each of which can have a separate rotation about the model origin.
[/b][/quote]
So does that mean that each model is divided into submodels (or submeshes)? My current object design (which I actually designed last year, programmed in, then promptly ignored for the past 4 months) uses a heirarchy with the base object at the top, which is things like position, angle, etc. This contains a list of meshes, which can be rotated any way you like about the object origin. Each mesh has a list of polygon sets (the mesh contains all the vertices needed, the polygon sets use indexing). Each polygon set cannot be moved separately, they are just polygons with different textures.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[quote]Originally posted by Biggles:
[b] So does that mean that each model is divided into submodels (or submeshes)?[/b][/quote]
Sorry, no that's not what I meant (I can see where my last post was unclear). When I said that each sub-model could have its own rotation I meant [b]rate of rotation[/b]. I added this feature primarily so that one of the modders could finish an Omega destroyer kit. I ended up using it myself to create a little homage to Babylon 5 in the guise of Harmony Station (http://www.starshatter.com/shots/s3.htm).
We did use the technique you describe on Starfleet Academy. If I remember correctly, it was key to how the "Ginsu" process worked -- allowing the player to blow the warp nacelles off enemy ships just like in ST2:TWOK. And yes, it really was named after the cheap steak knives from those silly 1970's TV commercials...
Biggles<font color=#AAFFAA>The Man Without a Face</font>
So how does your object heirarchy work then?
I've actually been reconsidering mine recently. It occured to me that the same thing could be done more neatly by having meshes as a separate entity from objects. Currently an object is one data file, with meshes being subsets of data within that file. You could instead create an object with different parts moving at different rates by having game objects defined in script files (thus making them easy to change) and within that script file load several meshes for different parts of the object. I'm not sure if this would be better for efficiency, but I suspect it would as it would be easier for artists to understand and once it's in memory it's pretty much the same as the old method, just more flexible.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[quote]Originally posted by Biggles:
[b]It occured to me that the same thing could be done more neatly by having meshes as a separate entity from objects.[/b][/quote]
Yes, I store the artwork (meshes) separately from the game data. Game data for ships, weapons, systems, campaigns, GUI screens, etc. etc. are stored in text files using a simple easy-to-parse declarative language. 3D models for ships, buildings, weapons, are stored in binary files using the format of my modeling tool "Magic". Images for the GUI and textures are stored in PCX files. Sounds are in WAV format. All of this stuff is then compressed into one or more archive files stored in the game directory.
There is a DataLoader class that retrieves data files from the archives. This class is designed to check the file system for the assets first, before searching the archive files. This way, I can keep a small set of data files that are under development sitting in the appropriate place on my hard disk, and they will get used in preference of the ones stored in the .dat file.
You can read more about the details of ship design files on my web board, but here it is in brief:
[code]
SHIP
And so on and so forth. The ship definition contains sub-structures for every ship system and weapon on board. Plus information about ship performance, graphic representation, and death spiral effects.
This example also shows how the multi LOD system works. The Spectre class destroyer uses three levels of detail, each stored in a separate mesh file. If the ship had animated rotating parts (like a B5 Omega) then each LOD would have multiple meshes - one for the main hull and one for each rotating component.
Biggles<font color=#AAFFAA>The Man Without a Face</font>
So the detail_# tag is your LOD level stuff, what are the free feature_# tags?
That's pretty much the idea I had come up with to replace my current system: Specify each ship/vehicle in a scripty-like file. As for the data loader thing: I'm going to make mine so that it will always look in the default directoy, but depending on a preference variable it might check other directories first. This is essentially what the Quake engines do.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[quote]Originally posted by Biggles:
[b]So the detail_# tag is your LOD level stuff, what are the free feature_# tags?
[/b][/quote]
The feature_X tag tells the engine how much detail is in each detail level. This attribute defines the "characteristic feature size" (in meters) for that level of detail model.
Let's say that feature_2 is equal to 4 meters (about the size of a gun turret on a starship). When the engine determines that the ship is so far away that a 4 meter object would be rendered as less than about one pixel, it switches to the next lower level of detail. This means that the precise distance at which an LOD switch occurs will be different based on model, screen resolution, and field of view. But the effect will be equally visible/invisible no matter what resolution the player is using.
Biggles<font color=#AAFFAA>The Man Without a Face</font>
Ah, I see. So that way you have dynamic LOD distances, rather than hard coded ones like Homeworld uses. Cunning. [img]http://216.15.145.59/mainforums/smile.gif[/img]
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
Biggles<font color=#AAFFAA>The Man Without a Face</font>
OK, I need to ask this since I've been stuck on this problem for ages now: How does your input system work?
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
Biggles<font color=#AAFFAA>The Man Without a Face</font>
You have two separate ones?
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
Comments
I am way too poor to afford any of the standard 3D modeling packages (even with Maya's new reduced price of only $2000), so I wrote my own from scratch.
Starshatter (at least, this year's version) is probably not the ideal platform for what you want to do. The game engine manages to push about 60,000 polys per second (not per frame) on a P2 400 w/ TNT2 card. It should scale more or less linearly with CPU speed. The game engine does not use hardware T&L. That is an enhancement for another time.
My ship designs typically range from 500 to 2000 polys at the highest LOD. I use only square textures in PCX files, usually about 256x256 for ship textures. Each model can have up to 32 different textures.
Ship models can have any number of components, each of which can have a separate rotation about the model origin.
Skinning and decal-based damage modeling are on my list of things to do next month when I will be concentrating on multiplayer support.
I hope.
------------------
--milo
[url="http://www.starshatter.com"]http://www.starshatter.com[/url]
[b]Ship models can have any number of components, each of which can have a separate rotation about the model origin.
[/b][/quote]
So does that mean that each model is divided into submodels (or submeshes)? My current object design (which I actually designed last year, programmed in, then promptly ignored for the past 4 months) uses a heirarchy with the base object at the top, which is things like position, angle, etc. This contains a list of meshes, which can be rotated any way you like about the object origin. Each mesh has a list of polygon sets (the mesh contains all the vertices needed, the polygon sets use indexing). Each polygon set cannot be moved separately, they are just polygons with different textures.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[b] So does that mean that each model is divided into submodels (or submeshes)?[/b][/quote]
Sorry, no that's not what I meant (I can see where my last post was unclear). When I said that each sub-model could have its own rotation I meant [b]rate of rotation[/b]. I added this feature primarily so that one of the modders could finish an Omega destroyer kit. I ended up using it myself to create a little homage to Babylon 5 in the guise of Harmony Station (http://www.starshatter.com/shots/s3.htm).
We did use the technique you describe on Starfleet Academy. If I remember correctly, it was key to how the "Ginsu" process worked -- allowing the player to blow the warp nacelles off enemy ships just like in ST2:TWOK. And yes, it really was named after the cheap steak knives from those silly 1970's TV commercials...
------------------
--milo
[url="http://www.starshatter.com"]http://www.starshatter.com[/url]
I've actually been reconsidering mine recently. It occured to me that the same thing could be done more neatly by having meshes as a separate entity from objects. Currently an object is one data file, with meshes being subsets of data within that file. You could instead create an object with different parts moving at different rates by having game objects defined in script files (thus making them easy to change) and within that script file load several meshes for different parts of the object. I'm not sure if this would be better for efficiency, but I suspect it would as it would be easier for artists to understand and once it's in memory it's pretty much the same as the old method, just more flexible.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[b]It occured to me that the same thing could be done more neatly by having meshes as a separate entity from objects.[/b][/quote]
Yes, I store the artwork (meshes) separately from the game data. Game data for ships, weapons, systems, campaigns, GUI screens, etc. etc. are stored in text files using a simple easy-to-parse declarative language. 3D models for ships, buildings, weapons, are stored in binary files using the format of my modeling tool "Magic". Images for the GUI and textures are stored in PCX files. Sounds are in WAV format. All of this stuff is then compressed into one or more archive files stored in the game directory.
There is a DataLoader class that retrieves data files from the archives. This class is designed to check the file system for the assets first, before searching the archive files. This way, I can keep a small set of data files that are under development sitting in the appropriate place on my hard disk, and they will get used in preference of the ones stored in the .dat file.
You can read more about the details of ship design files on my web board, but here it is in brief:
[code]
SHIP
name: Spectre
display_name: Spectre
class: Destroyer
detail_0: "tiny.mag"
feature_0: 1000
detail_1: "mid.mag"
feature_1: 16
detail_2: "Ship2e.mag"
feature_2: 4
mass: 9e3
agility: 3.2
vlimit: 240
roll_rate: 7
integrity: 25e3
scale: 1.8
power: {
type: Fusion,
design: "Fusion Reactor",
max_output: 7500,
loc: (0, -48, -180),
size: 48,
hull_factor: 0.3,
explosion: 7
}
[/code]
And so on and so forth. The ship definition contains sub-structures for every ship system and weapon on board. Plus information about ship performance, graphic representation, and death spiral effects.
This example also shows how the multi LOD system works. The Spectre class destroyer uses three levels of detail, each stored in a separate mesh file. If the ship had animated rotating parts (like a B5 Omega) then each LOD would have multiple meshes - one for the main hull and one for each rotating component.
------------------
--milo
[url="http://www.starshatter.com"]http://www.starshatter.com[/url]
That's pretty much the idea I had come up with to replace my current system: Specify each ship/vehicle in a scripty-like file. As for the data loader thing: I'm going to make mine so that it will always look in the default directoy, but depending on a preference variable it might check other directories first. This is essentially what the Quake engines do.
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
[b]So the detail_# tag is your LOD level stuff, what are the free feature_# tags?
[/b][/quote]
The feature_X tag tells the engine how much detail is in each detail level. This attribute defines the "characteristic feature size" (in meters) for that level of detail model.
Let's say that feature_2 is equal to 4 meters (about the size of a gun turret on a starship). When the engine determines that the ship is so far away that a 4 meter object would be rendered as less than about one pixel, it switches to the next lower level of detail. This means that the precise distance at which an LOD switch occurs will be different based on model, screen resolution, and field of view. But the effect will be equally visible/invisible no matter what resolution the player is using.
Anyway, it seems to work OK.
------------------
--milo
[url="http://www.starshatter.com"]http://www.starshatter.com[/url]
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras
------------------
--milo
[url="http://www.starshatter.com"]http://www.starshatter.com[/url]
------------------
[b][url="http://www.minbari.co.uk/log12.2263/"]Required reading[/url][/b]
Never eat anything bigger than your own head.
The Balance provides. The Balance protects.
"Nonono...Is not [i]Great[/i] Machine. Is...[i]Not[/i]-so-Great Machine. It make good snow cone though." - Zathras