Topic: Discussion on Models

[[UFP]Exeter]

The thread got a little off topic so made the discussion on modding it own thread.

[intermech]

High quality? Well that dices me out. But I'm curious anyway, what era?

[Starfox1701]

so the dominion got axed?

[Javora]

Playable races are Federation, Romulan, Klingon, Cardassian, pirates and a new race.

Andorian??!?   

[[UFP]Exeter]

Forgot the Dominion.  But if we get the models we can add the race.  The era will depend on the models, if we get the models we can allow selection of era.

Sorry about the high quality, but we want this cutting edge.  A model that is at the limits of MilkShape is probably the minimum.  But you can get a free viewer and see how it looks.

[Starfox1701]

We had this discussion already and I thought that TNG era had been decided both because they Cardassians and Dominion and because that gave the Federation, Klingons, and Romulans the most designs to work with?

Also on the note of Quality we need to develop and deploy a system for both the rigging and LODing of these models and need to decide on a texture format for these models. As far as poly count on ships I think 20k to 30k range for the close mesh. The guys over at BCC are turning out kick butt models in that range. 2048X2048 or 4096X4096 DDS files will probably be good for the textures. I think trying to keep the limit to 3 meshes per LOD should be good too.

[[UFP]Exeter]

I agree TNG is the era of choice.  But if we get the models we can allow a choice of the era.   I would also like to create a POST Dominion war ere, to allow creativity of futuristic models.

But, models are not my area of expertise, and would like someone to hed and coordinate this.   I can provide limitations on what we can do, but the lead on this would make most of the decisions.

Starfox1701, are you interested?

[Starfox1701]

I can build models but I'm not vary good at making textures from scratch. The big problem is that as the programer you need to integrate the stuff for LODs(Levels of Detail) and rigging(all the hardpoints, and damage sprites and/or meshes, break nodes for destroyable components, Name plates, incidental lighting like blinkers, ect...) and inform us how this stuff works so we can construct the models accordingly. We can't build the models and construct the game around them because there are ingame functional aspects defined by the coding. Without them the models are incomplete and not functional. The programing component is completely beyond my skill. I can't make an estimate of the time required to complete the 6 planed races inpart because I do not yet know how much work each ship and station will take because these functions are not yet in place.

On the note of available eras we need to narrow it down to 1 for the time being. Other eras can be integrated as addons or expansion campaigns. If we try to do to much in the beginning it will take to long and will likely lead to loss of team members through exhaustion and loss of interests in a project that has become never ending. It is this kind of thing that has killed many a major mod and other such projects. We need to be sure that our goals are both realistic and attainable. New goals can be added if there is time or can be in expansions if there is interest. After all this will be unpaid work totally dependent one the donation of time by the participants.

But, models are not my area of expertise, and would like someone to head and coordinate this.   I can provide limitations on what we can do, but the lead on this would make most of the decisions. Starfox1701, are you interested?

I could take a stab at it if everyone is OK with that, but there are others in the community that might be better suited if they want they job. I'd at least like the rest of the communities input on this.

[[UFP]Exeter]

I would hope others than can make the models would volunteer.  But as the lead you could coordinate all the effort to make sure we get what we need.

Hot points need to be derminded for each class, how many etc.

For location the information will be stored in the ship date file and  not hard coded into the game or the model.  This will be ot point locations etc. The game will load it all in ahad of time, there will not be database access during combat.

I like the idea of add ons for other era's, so we will focus ont TNG for now.

[Starfox1701]

So what rigging will the models require? How do you plan to handle ship sprites or define the locations of systems or weapons?

[Javora]

Is pneumonic81 still around, I remember him doing some great models...

[Starfox1701]

As far as I know he went pro. Did models for both A2 and Legacy. Have seen anything for years.

[[UFP]Exeter]

Maybe I am missing something, but I see no reason for sprites, other than for ship configuration and that is jsut 2D images.  For torpedoes I would like to also use models, better lighing effects.  I actually have one a friend made for me.

As for defining locations, once the model is built and we ave a size then we determine the locations relative to the center.  We will use the scal of meters, and we have to figure out a scale to pixels on the base screen size.

[Starfox1701]

Certain damage effects and animations like blinking nav lights and plasma leaks would likely still use sprites.

As for defining locations, once the model is built and we ave a size then we determine the locations relative to the center.  We will use the scal of meters, and we have to figure out a scale to pixels on the base screen size.

You know there is an easier way to do that. You place helpers in the mesh and give them name tags. The ship date file references these for things like weapons fire or incoming damage. It is called hardpointing the ship. Can somebody post some pics of what I'm talking about; I'm having problems with my laptop not doing screen shots. This is the kind of stuff I'm talking about when I say rigging a model.

[[UFP]Exeter]

I may be way off here, as I have never done a mode.  But flashing lights, is that not part of the model itself?   And the hardpoints, I know in some games is is part of the model, but if we just have relative positions to the models center will that not work?   plasma leaks and these types of effects I think can be effects, similar to explosions etc.  A particle effect.

My thoughts and I can be way off:  A ship, with a specified hot point, fires a torpedo.  Based on the hot point location the torpedo leaves from that location and heads toward the target.  Once te torpedo hits, there is an explosion, this explosion uses a particle effect.  And the torpedo is a 3D model, not a sprite.

The problem with a sprite is you have to create the bitmaps for the sprite to loop through and they all look the same.  With a particle effect there can be randomness, not all the same.

[Starfox1701]

I may be way off here, as I have never done a mode.  But flashing lights, is that not part of the model itself?   And the hardpoints, I know in some games is is part of the model, but if we just have relative positions to the models center will that not work?   plasma leaks and these types of effects I think can be effects, similar to explosions etc.  A particle effect.

My thoughts and I can be way off:  A ship, with a specified hot point, fires a torpedo.  Based on the hot point location the torpedo leaves from that location and heads toward the target.  Once te torpedo hits, there is an explosion, this explosion uses a particle effect.  And the torpedo is a 3D model, not a sprite.

The problem with a sprite is you have to create the bitmaps for the sprite to loop through and they all look the same.  With a particle effect there can be randomness, not all the same.

Isn't a particle effect just a complex sprite with the animation projected onto tons of particles instead of a 2D billboard? Useing mesh based weapons effects can does provide a more "realistic" effect most of the time. Somethings like TWOK phasers are very hard to replicate mainly because ILM used 2 different effects, 1 for the close shots and a different one for longer shots. However their is a drawback in large battles in that they can quickly use up rending power in the game engine. Is there some way you can prevent that?

On the rest let me get back to you.

[Starfox1701]

Ok let me try this question from a different direction; do you have a graphics engine in mind or are thinking about building on from the ground up?

[[UFP]Exeter]

Irrlicht for graphics
Bullet for physics

[[UFP]Exeter]

I have a question.   I have a 3D model.  Now to get things to work I need bounding body/shape for collision.  How do I determine the size of a model so I can adjust the size if he shape?

[Starfox1701]

I personally don't have any experience with either of these so I have no idea. I.m going to dig around and see what I can learn. Did you consider trying to get permission to use the Evolved engine being developed for ST Excalibur? I am not sure where the are overall but based on the posted progress It is worth looking into.

Look at this stuff and tell me what you think.

Excalibur | Dead in Space

HP Editor - Adding Decals

HP Editor - Update

Texture Coordinate Shifting Nebula

HP Editor Update #3

Launching the Enterprise

[[UFP]Exeter]

For my question I also posted on Irrlicht and Bullet forums and got an answer with sample code.

I do not know about evolve but Bullet is working on employing the GPU for collision, which will really be fast.  I really want this tech.

There is a team working on DX11 drivers for Irrlicht.  I really want this also.

This will move the minimum specs but really boost performance.

[Starfox1701]

We will have to have them as right now the Irrlicht doesn't support .dds files and I'm concerned that even after the 1.9 update it won't handle the correctly. The whole point behind the file format is to run them in the VRAM compressed and it doesn't sound like 1.9 will do that. .TGA and .PNG files eat up tones more VRAM and so are far from idea considering the performance we are aiming for.

Bullet is the same physics package the Excalibur team is using so it should be up to the job here. What ever graphics engine we end up with we will need a model property editor for the modeling team like the one shown in some of the videos I posted. The ability to alter the HPs and light them and test in engine like that will be a huge asset to developing a superior product. It would also make an awesome moding to to go in the final release. might even be able to combine or at the very least derive a map editor and mission builder from it.

[[UFP]Exeter]

Valid points.  Irrlicht does have a scene editor.

Are there better tools on Ogre 3D that would halp?   My biggest concern is everything needs to be in the Ogre proprietary model format and I like the versatility irrlicht has in formats.

DDS is a directx format, why do we need it.  To use it is  pain, I tried it with XNA.

[Starfox1701]

For 1 thing it is the direct X runs them without uncompressed them like it will have to for .PNGs which are an image archive format, not a model texture. .TGAs aren't compressed at all. This means that a 1024X1024 in .DDS will provide the best overall performance and use the least amount of VRAM, roughly a quarter the VRAM of the others, when the game is running. Combine that with the Direct X model format and we should get the best look and speed under load.

I am making inquiries concerning the Evolved Engine and Nano FX GR but haven't heard anything definite one way or the other. Besides Ogre 3D and Irrlicht what other options do we have?

[[UFP]Exeter]

Directx 11.   This gives direct access ans is faster. And if we do DirectX, then we will go straight to 11.   If we did this route, we can look at other code (irrlicht for example) to extract some of the model imports etc.

I will not argue this would be the best way.  Unless we have somebody that already knows DX11, I can take it on as I already started to learn it.  At one point I was considering it.

DX 11 is far superior to DX9.

Disadvantages:  Will take longer to develop.  We are talking about months.

Advantages:  Performs faster than other engines
                   utilizes the expanded features of DX11
                   Graphics are much better

I am not adverse to it, I did not do it before simply because I was working alone.

Ogre and Irrlicht are both working on DX11, but the same person is at the core, and all they are doing is creating drivers, an that is difficult as DX11 s vastly different than DX9.

I use to program DX9, in fact looked at converting CE to DX9.

I would relish doing our own graphics (DX11) and would be able to tightly integrate with Bullet and then we have our own engine.

[Starfox1701]

Considering the performance and lifespan of the product we want Direct X 11 is the best way to go. Time in and of it's self is not an issue. It is better to do it right the first time then to rush and get peoples hopes up and deliver a bad product.

[[UFP]Exeter]

When the decision was made to do irrlicht, I was working along and I had to figure in time to learn to build models etc.  Also at the time I had a constraint, which I no longer do.

So I am fine with going the DX route.  Also, I can integrate the math from Bullet and other useful tidbits.

Take a look at irrlicht and tell me what model formats we should support?  I can take the importers and use them to create our own importers.

Of course if Irrlicht gets DX 11 completed we may go back to it, depending on far we have gotten.

[[UFP]Exeter]

Unity uses a scripting language, like c# or javascript.

While I know c#, it is different.

Also, we would be using the script to make the game engine do what we want.

And will we be able to do what we want on the free version?  We will be limited to what they give us and given the quality we desire I suspect we will need the tools of the Pro Version  ($1500)

Although I know C# I am a C++ programmer.  So if somebody else took over we could use Unity 3D.

I forgot to mention, the scene.  Most engines use a 2D background that may or may not scroll.  Envision our scene to be inside a sphere.  So when you move the camera the background changes.  Move it 360 degrees and you are back to the same location.  Very realistic.  This is implemented and working.  I think I tried this in Unity, Ogres, XNA etc and did not work easily.  I was able to get it to work easily in Irrlicht.  As Irrlicht is Dx bases, it can be done in DX.

[Starfox1701]

When the decision was made to do irrlicht, I was working along and I had to figure in time to learn to build models etc.  Also at the time I had a constraint, which I no longer do.

So I am fine with going the DX route.  Also, I can integrate the math from Bullet and other useful tidbits.

Take a look at irrlicht and tell me what model formats we should support?  I can take the importers and use them to create our own importers.

Of course if Irrlicht gets DX 11 completed we may go back to it, depending on far we have gotten.

Right now I'm leaning toward .X format since it will run so well with Direct X. We will probably need importers and exporters for the version of .X we use for 3DS Max, Milkshape, Blender, and Maya as these are the most commonly used modeling programs around here.

[[UFP]Exeter]

Irrlicht is Direct x and will run on OpenGL, so any models need to be converted into .x format or it write to the hardware directly, which I doubt.

But if we can get all the models we need looking good and in .x format I am fine with it.

And unity supports .FBX, .OBJ, .MAX and blender.

Personally, if we can support .X, >FBX, and 3DS it would be great, and maybe milkshape.

[Starfox1701]

The other file that's got me interested is COLLADA .dea files. These are the ones Excalibur is using but I  don't know that much about them except that they seam to be gaining in popularity in the gaming industry and are open source. What do you know about them?

[[UFP]Exeter]

I still do not understand why games use Collada.  For development, the advantage is it is a format that works between tools.  But it is a xml schema.  My suspicion is the loading is slower than a binary.  The only way to tell is create a model in another format and collada and compare.  I did that using the Irrlicht mesh viewer demo and found out how slow OBJ format is.

We can use most any format, my preference is it is a format that irrlicht supports, as i have a c/c++ importer to examine.

I have some prebuild non trek model I bought that can be for other races.  And two very large models to use for the larger ships of the new villain.    They are huge and OBJ format.  Slow to load but I plan on models being all reloaded before tactical starts.


On another note:  Part of the issue trying to update EAW (CE) was so many thrid party libraries were no source and we could not update or change.  In order to make a game that we can maintain and upgrade as we choose, requires us to have full source.   I do not see this as negotiable.  Unity does not include source without lots of cash.  So it is out.

[[UFP]Exeter]

I can take a stab at DX11.  I will only put in what we need.  But I will put it in as a library so we can expand it later.  And Strat may remember I had wanted to replace the code in CE to use DX 11.

But my concern is we are expanding the scope and dramatically increasing the work required to do this.  In progress, and I have seen the code, is dx11 drivers for Irrlicht.  It works but there are some issues with scenes that needs to be resolved.  I would hope it to finish this year.

I do not mind but currently we do not have any other coders.  I like coding in C++, so I will take the time, but the question:  Do we want to pissibly delay by 6 months?  But if we can create better interfaces for realistic models and gaming, then it is worth it.

[Starfox1701]

What will happen in 6 months?

[[UFP]Exeter]

I will have to learn DX11 as it is vastly different than DX9.  On my to do list but not there.

Then build our 3D graphics in DX11.

Maybe Irrlicht will have the DX11 driver finished.  However, they started this 3 years ago so who knows.  In the forums it is estimated it is 90% done.

I was working on integrating the physics, but I just realized if I focus on DX 11  when it is done, Bullet she be to version 3, and debugged, with the GPU support.

Question:  While I am working on DX, can we proceed with the models we need?  Also we can design in things needed for them.

[Starfox1701]

Well We still don't have a modeling staff yet so I don't think concentrating on DX11 will hold up the process any. Go for it.

[[UFP]Exeter]

I will archive what I have them go from there.  What I am thinking is an api similar to irrlicht and then I implement what we need. 

Irrlicht has a mesh viewer, I will use that with our new graphics as a way to test and load models.

[Starfox1701]

Do you think the model viewer can be turned into property editor or will that need to be done from the ground up?

[[UFP]Exeter]

Not sure, as it will load and display models using the irrlicht engine, there is no provision for saving anything.  Most property editors I am aware of are unique to their model type.

To do one will take a knowledge of Models and C++ and DX11 (or other).

It would be awhile but we could use the model viewer as a basis as I mention but build it into a property editor.  And only support the model types decided on.

[Starfox1701]

So that's going to have to wait till the engine is further along and more stuff is implamented

[[UFP]Exeter]

Yes, it will have to wait.  Depending on work I will acquaint myself with most things then start on it.  The issue will be shaders, that was a dramatic change.  The shader pipeline is giving some of the developers of Irrlicht issue.  But that are trying to take existing code to DX11 and have it operate the same.  But we will not have that constraint.

If you can document what you want I can keep it in mind.  A nice smaller program to test our engine.

[Starfox1701]

Ok that will take some time. I'll get something together.

[[UFP]Exeter]

No rush, have alot to do to get there.

[[UFP]Exeter]

I am impressed.  In DX11 the removed the D3DX library for math and replaced it with he XNA developed math library that includes support for special hardware registers.  SSE2, 128 bit wide SIMD.

This is impressive, Vector math calculations can be 4 times faster this way.  This will really speed up model changes such as scale, rotation and translation.

[Starfox1701]

That's good news. Are you familiar with the Nano FX model viewer?

[[UFP]Exeter]

Never looked at it.  The NanoFX  (and Nano FX GRE?) merged into Excalibur about 3 years ago.  Then it was DX 9.  Not sure if the upgraded to DX11 or not.  The viewer is for Excalibur models and I have no idea of their model format.

I tried find out more about it but ran into dead ends.  Other than they use the NewtonDynamis Physics Engine, not Bullet.

[Starfox1701]

Yes it represents a very early form of the Evolved engine. The important point is that it represents a good example of at least the basic functionality that a model property editor integrated into the game engine would need. What do you think of using it as a model to pattern our Model property editor on when the time comes feature and function wise using our engine, physics, an UI?

[[UFP]Exeter]

I have no problems with that.  Do you have a copy of it?

[Starfox1701]

yea you can still download it here

http://www.moddb.com/games/star-trek-excalibur/downloads/model-viewer-v17

[[UFP]Exeter]

Thanks, but to do it I need to understand the hotpoints and models.  Does not make sense to me.  For realism a phaser beam should come from the "hotpoint" on the model and go in the designated direction using ray cast to see if it hits a target.  That means the program needs to know the location of the hotpoint relative to the model center.

[Starfox1701]

That's why I suggested using the viewer as a guide. On of its features is it lets you hardpoint the model. This version uses .X file format models like we are planing to. all the files are presented in a format that can be edited from note pad or Wordpad or directly by the viewer. The Hardpoint is recored in the HP fiie. In the case of the stock vewer theres a Galaxy class mode, the SNS Galaxy. The Hardpoint files is here Release 1.7a\Gfx\Models\Federation\Ships\Galaxy\Scripts and is named Galaxy and Galaxy_HP. There is a model conversion tutorial in 6 parts here with more info

http://www.youtube.com/user/24thCenturyBuff/videos

Did that answer you question?

[[UFP]Exeter]

close enough.  The hardpoints are identified somewhere, that is what I need.  I just looked at the file, and I take it that is not part of the dx standard but their graphics engine.  The .x models I worked with before did not have a script file.  That tells me the hardpoint data can be in anu text file and related to an model format.

I mentioned I do not want to support just X format.  Maybe prejudice but I am NOT a abit fan of microsoft.

[[UFP]Exeter]

Been doing some research.  Here is a thread about Irrlicht and DDS for textures:   http://irrlicht.sourceforge.net/forum/viewtopic.php?p=149805

I did find source to read a DDS file, also Google Chrome is open source and has a dds loader.

It looks like Irrlicht 1.9 is progressing nicely, I pulled the code from SVN, and as far as what i am using right now everything works great.   The DX11 drivers are not finished, for the shader pipeline but I do not need that quite yet.  Everyting else works and I test my working code against DX11 and it works.

I think we should proceed with Irrlicht and if we need a DDS loader, I will add it.

It is Beta but stable enough for now. 

[Starfox1701]

Definitely understandable. Will it complicate things to support other file types? In game, at least for our project, we need to pick a single file type that combines the best speed and graphics and use that one but I have no problem with the engine being able to use other types. So the question is are .X files the best for the job or is one of the other DCC formats better suited? Also would it be all that hard to create a file format for our engine specific to it?

We will need a .DDS loader as they are the best texture option. .DDS files basically come with built in LODs and save processing power as you pull away from the object.

[[UFP]Exeter]

We can disable any file type we do not with to support.  And we can add our own filetype, a custom one.  But, for modding, why not just support some good standard ones that makes it easier to mod?

I do work on multiple items at once so now I can work on the physics and start planning the AI.

As for irrlicht it allows me to support either dx 11 or 9, or Open GL 2, so changing the configuration to allow user selection.  This was already coded for DX9 and OpenGL, added DX11 and it works so no deed to rebuild the code to change drivers.  And users on older systems can drop to DX9 with notepad to change the driver in config.xml

[Starfox1701]

If you can make it work go for it. I suspect though that these other files will lag in performance in the engine. As far as the moding goes though if we have importers and exporters for the most common DCC programs it shouldn't complicate things as all the Hardpointing would be done in the Model property editor regardless of file type.

[[UFP]Exeter]

When I started this long ago, I had a backup for every library.  The backup was to do it myself, but I had hoped the libraries all performed well.  So if there are performance issues we step back and fis that area.

Our code will be optimized for DX11, but this allows those who need DX9 to play the game, but at reduced performance.

We can use the model property editor as you say, but I am concerned out those that cheat.  So I think the maximum hotpoints per class/race should be coded in the database.   Then they can do what they want, but they cannot arm a frigate like a battleship.   A Sabre with the firepower of  Sov would be something to see though.

[Captain Adam]

.

[[UFP]Exeter]

No, modding is one of the core features.  However, there may be some limitations, as the game play and the core specs of ships are gear will not be.

But anything can be changed.

[Starfox1701]

I don't think that will be necessary. The need for multiplayer sink will keep players from using godships PvP unless both sides agree to it. On anything like a dynaverse server only the approved version would be allowed to log on by the server package. If some one wants to cheat in the single player mode that's on them. We don't need to police the single player mode so long as these other safe guards are in place. I would imagine simpler to code in the long run too.

[[UFP]Exeter]

For our game the modding capability is between two extremes.  One end is doing th game in something like lua, or most of the game.   The other is no customization.  What I think we should do is somewhere in between.


Starfox, my thought was to have the limits in the secure database that also has the game controlling parameters.  That allows for updates without changing the code.  During testing it will not be secure, so we can balance data for playability.  The when ready for release it is encrypted.

The information I would store for example would be Federation Battleship (Galaxy Class)  max number torpedo and mas number of beam hotpoints.  Lets say the limit is 6 beams and 3 torpedoes.  When the player builds his own model or changes one, he can put all the hotpoints in the stern if he wants to.  The game will only ensure the max number is not exceeded.  However as gear is upgradeable during gme play, and has both mass and energy requirements, this may prevent putting the best of everything on a ship.

[Starfox1701]

My point is you do not need to do that. As long as the multiplayer and server kits force the players to have identical versions of the game you purposed security measure is not needed and is needlessly restrictive. What you don't seam to realism is that doing what you want means losing the ability to have things like accurate stardestroyers, Battlestars or other large ships from other scifi universes moded in later. What are you so afraid people will do with this game that you what to remove that level of customization, which by the way would be the biggest selling point and draw, from the game?

[[UFP]Exeter]

Actually, the customization lets them replace the database with their own so they can pretty much customize anything.  Some of the constraints are the internal game mechanics.  I will need to know what weapons are where, to determine the characteristics, like firing arc etc.

It makes sense to specify the hotpoint locations via an editor for each model.  But as what is located at the hotpoint can change during gameplay, that needs to be stored in the game.  Therefore I need to know the limits.

The game is broken into states, the tactical or game combat, anything that can possibly change must be stored in the game.

I am not trying to limit customization but I don want to deal with a lot of "bad" customization.  So the idea is to store information in databases, mostly unencrypted and they can change that all the want.  The encrypted they cannot changes, but they can created their own, we publish the data.  In the end, the game is nearly 90% customizable.  And the encrypted database will be open for read only so modders can copy and read the data,  just not change it.

[Starfox1701]

Actually, the customization lets them replace the database with their own so they can pretty much customize anything.  Some of the constraints are the internal game mechanics.  I will need to know what weapons are where, to determine the characteristics, like firing arc etc.

First of correct me if I'm wrong but these databases are part of the engine, not part of the scripts and models right? If that is the case 99.99% of moders will have neither the knowledge or inclination to mess with that. The hardpoints will tell you what is located where on the model. Different types of hardpoints will denote different functions or ships systems or lights or damage effects or id maps. We should hard code the different types of hardpoints but not the number of hardpoints. To borrow from your early example the Galaxy class can easily require 400+ hardpoints of several different kinds. There would what 11 id map Hps, 18 Nav lights, 6 differed lights, around 100 to 150 phaser Hps slaved to 11 or to 14 arrays depending on whether its a Mk 1 hull or Mk 2 hull and whether or not it is saucer separable, 36 warp drive Hps, 18 impulse drive Hps, and the list goes on. Each system or effect is defined by its own type of Hardpoint which is hard coded and not modable but the total cumulative number left open ended. The engine should also be aware of weapons hardpoint locations in relation to the outer surface of the model so different weapons won't fire through the mesh but I think you already knew that.

It makes sense to specify the hardpoint locations via an editor for each model.  But as what is located at the hardpoint can change during gameplay, that needs to be stored in the game.  Therefore I need to know the limits.

The game is broken into states, the tactical or game combat, anything that can possibly change must be stored in the game.

I don't think it makes since for what is located at a Hardpoint to change during actually gameplay. Out side of break nodes Hardpoints should be fairly static. Whether we even need break nodes will depend on how complex we want to make the damage system in the game. While having destroyable sections of a ship is most definitely awesome I see where it could become problematic in a campaign setting. How do you deal with a player vessel that has had it warp drive or a major ship section destroyed in battle? While graphically I don't think is a problem to do; it could definitely be a major headache from a gamplay point of view.

I am not trying to limit customization but I don want to deal with a lot of "bad" customization.  So the idea is to store information in databases, mostly unencrypted and they can change that all the want.  The encrypted they cannot changes, but they can created their own, we publish the data.  In the end, the game is nearly 90% customizable.  And the encrypted database will be open for read only so modders can copy and read the data,  just not change it.

Hear again I'm not sure I understand what you mean. Could you explain this more please?

[[UFP]Exeter]

I think it would be best to talk about, can you be on teamspeak at some point?

[Starfox1701]

2 Dumb questions, whats teamspeak and why do we need to go off thread?

[[UFP]Exeter]

Dynaverse has a teamspeak server and the client is free.  It would allow a voice conversation, but we can keep typing this.  I just thought a 15 minute conversation would clear things up.  And we could post the results here.

[[UFP]Exeter]

This thread has taken many turns, so In split the topic:

Modding:   http://www.dynaverse.net/forum/index.php/topic,163393371.0.html

[[UFP]Exeter]

What I see for the model (at the moment as I am being educated)

A new 3D model is created.

Using the editor hot points are added.  Including weapons. 

The modder will change the non encrypted database to load this model instead of the standard Federation Galaxy class and read the script

The game core knows how many weapon types and reads the main hotpoints and stores them for use in the game.  Only the hot points necessary for the combat mechanics are stored.

A phaser is fired, the graphics will utilize the hot points in the script and display appropriate imagery.  The game mechanics will use the saved hotpoints for collisions, damage etc.

Does this make sense?

The term hotpoints is being used for graphics and physics and they are not necessarily the same.  In the graphics a phaser array could have 10 hot points for the proper visual affect.  for the physics, it is 1 point used for range determination, targeting angles etc.

[[UFP]Exeter]

I was reading old posts on the ST Excalibur forums, and apparently they are not going to use the .x format for models.  Makes sense as in my reading it seems to be fading away slowly with the slow passing of DX 9. 

[Starfox1701]

What I see for the model (at the moment as I am being educated)

A new 3D model is created.

Using the editor hot points are added.  Including weapons. 

The modder will change the non encrypted database to load this model instead of the standard Federation Galaxy class and read the script

The game core knows how many weapon types and reads the main hotpoints and stores them for use in the game.  Only the hot points necessary for the combat mechanics are stored.

A phaser is fired, the graphics will utilize the hot points in the script and display appropriate imagery.  The game mechanics will use the saved hotpoints for collisions, damage etc.

Does this make sense?

The term hotpoints is being used for graphics and physics and they are not necessarily the same.  In the graphics a phaser array could have 10 hot points for the proper visual affect.  for the physics, it is 1 point used for range determination, targeting angles etc.

Yes that looks like a good description though as I mention in the moding thread there is a variant method that could be employed.

I was reading old posts on the ST Excalibur forums, and apparently they are not going to use the .x format for models.  Makes sense as in my reading it seems to be fading away slowly with the slow passing of DX 9. 

They have moved on to COLLADA .dea files for models but for the life of my I cant figure out why. The COLLADA format hasn't been updated since 2005 so none of the accumulated bug fixes of other users has been added to the system. This I way I purposed coding our own format.

[[UFP]Exeter]

Yes that looks like a good description though as I mention in the moding thread there is a variant method that could be employed.

I wanted to clarify what I was thinking into one post and we have a reference to our alternatives.

They have moved on to COLLADA .dea files for models but for the life of my I cant figure out why. The COLLADA format hasn't been updated since 2005 so none of the accumulated bug fixes of other users has been added to the system. This I way I purposed coding our own format.

The problem I see with our own format is we will need an exporter for model programs, and an importer for the game.  I like the idea of a nanoFX style utility.  If we could use something like that on a format besides .x it would work.  Just a wild thought, a .X format model, with .PNG texture and ceate a scrict like nanofx?

[Starfox1701]

As a moder I think a proprietary model format could be very beneficial to the game however since I lack the needed programing background I don't know if that benefit outweighs the difficulty in creating one, importers and exporters included. I personally think it is worth exploring but being 100% honest I lack any facts on which to justify the opinion. Besides the tools what are some of the other problems in crafting our own format? Also would it be possible to base that format on an existing format like .X or .3ds? If we did that would it allow for their importers and exporters to be easily modified as well?

On the note of textures .PNG files are not the best option. While they are usable, the format is optimized for Data storage; not the high speed, multicall render environment of a game. .PNGs are best used for movie and TV CGI where render time is a far less important consideration. There will be performance penalties if we use them. .DDS files are the best option currently available. They run the fastest; being optimized for a game engine environment; while providing quality the equal of .PNGs more then 85% of the time when formatted correctly.

Based on what I know right now .X models with .DDS textures looks like the best combo but finding real performance date on how the different available model formats work has been very hard. Most info on the net is either PR crap and so slanted toward a specific product or preference based and so of questionable completeness and possibly biased.

[[UFP]Exeter]

I think once the model and textures are loaded it is Irrlichts internal format so the only real performance issues is the load time.  So once a PNG is loaded into memory the format no longer matters.  I am just concerned DDS is on the way out.

Also there is an advantage to our own format.  I did purchase some models, the license requires protection like converting to our own proprietary format.  And most of what I have is either OBJ or 3ds, blender for example could be used. 

If we looked a Blender for building models, then easy to export compared to others and develop an exporter.  And we could use any format as a basis and make minor changes.   What model building tool do you use?

[[UFP]Exeter]

I did some code review and Irrlicht does support DDS, but their are caveats. 

It does not work on 64Bit and I am considering a 64 bit version of the game.

For DDS, the S3TC compression algorithm is under patent by S3 and they do collect license fees.

[Starfox1701]

1. Once the DX11 drivers are done will it work on 64 bit systems?

2. What is the S3TC compression algorithm and why do need that specific algorithm?

3. What would need to be done to get the engine running .DDS on 64 bit systems?

[[UFP]Exeter]

1. Once the DX11 drivers are done will it work on 64 bit systems?

No idea but I expect just spending the time to debug and fix it.  I suspect it is related to alignment of data as that is usually the issue with 64 bit.

2. What is the S3TC compression algorithm and why do need that specific algorithm?

This is the standard DDS compression algorithm,  Have not found others,  But if we do not compress it may not be needed.  But this is the algorithm Irrlicht supports.  But as long as we do not read compressed DDS then it is not an issue.

3. What would need to be done to get the engine running .DDS on 64 bit systems?

I suspect just debugging and fixing the DDS code in Irrlicht.  It works in 32 bit.  the ability is commented out so I suspect it will not be fixed.  But I have verified others have used it and have disabled DDS compression.

[Starfox1701]

I might have a way around the S3TC compression algorithm problem. Check here

http://code.google.com/p/libsquish/

[[UFP]Exeter]

This could work for our own work.  We would need an app to compress the dds files.  and then have to uncompress then before irrlicht uses them.

What about modders?  Will we provide a tool to compress the DDS files the make?

[Starfox1701]

My understanding with DDS files is that they are already compressed when you make them in a program like gimp or photoshop. It is part of the process. Not sure how Gimp does it but Photoshop uses a plugin from Nvidia to write and compress them. The plugin has all the compression options. I figured that we would use the code to uncompress them if that's what we need to do. Aren't they designed to be run in a compressed state?

[[UFP]Exeter]

I think they are compressed.  Irrlicht has its compression built in for the S3 decompression algorithm.  So I think it decompresses as it reads the file.  If Gimo and Adobe compress as they save we are good.

I guess I need to get the add for gimp to convert an image to DDS and try it out.  Right now all my code is 32 bit so for now 64 can wait.

I will also check the cost of the S3 license.  Maybe it is a percetage like 3%

[[UFP]Exeter]

Interesting WIKI calls is lossy texture compression.

http://en.wikipedia.org/wiki/S3_Texture_Compression

[[UFP]Exeter]

I have an idea.  We use DDS, but to avoid messing with compression we put the files in a zip file.  I can read from the zip file (already in Irrlicht) so we get compression and the DDS format. 

And since we only do this a the loan non during combat, it should not matter fo any extra load time.

[TheStressPuppy]

So you want 20k "Minimum" for a mesh? How many ships maximum do you plan to have on the map at once? I understand you want high model detail, but sometimes you can substitute mesh details with normal, and specular mapping. You will have normal (bump), specular, illumination, reflection, bloom, and shadow support correct? Sometimes less is more as far as performance is concerned. What I am basically asking is what the planned total combined poly budget for the game is.

10k is that largest mesh i've ever modeled. I try to make the best looking meshes with a few polys as possible. I wouldn't know what to do with another 10k+ triangles.

if you have a 5 view of a concept ship i can give it a go, and see what i can pull off. You guys already know my credentials.

[Starfox1701]

I have an idea.  We use DDS, but to avoid messing with compression we put the files in a zip file.  I can read from the zip file (already in Irrlicht) so we get compression and the DDS format. 

And since we only do this a the load not during combat, it should not matter for any extra load time.

.DDS files have to be compressed, it is part of the format as far as I can tell some of them will get truly massive if they aren't, 64 meg for a single texture file.

So you want 20k "Minimum" for a mesh? How many ships maximum do you plan to have on the map at once? I understand you want high model detail, but sometimes you can substitute mesh details with normal, and specular mapping. You will have normal (bump), specular, illumination, reflection, bloom, and shadow support correct? Sometimes less is more as far as performance is concerned. What I am basically asking is what the planned total combined poly budget for the game is.

10k is that largest mesh i've ever modeled. I try to make the best looking meshes with a few polys as possible. I wouldn't know what to do with another 10k+ triangles.

if you have a 5 view of a concept ship i can give it a go, and see what i can pull off. You guys already know my credentials.

I think 20K is around the max not the minimum. As for what you would do with the extra polies probable something like this

http://trekmodeler.deviantart.com/art/Space-2271-368275554

granted shes a bit over 20K, 27K actually, but the point stands. With modern cards, good coding and modern texture compression I think we can see that level and still run 20 or 30 or maybe even 40 big models at a time. After all the beasty runs in Bridge Commander and Armada 2 and they are 10 years old.

[[UFP]Exeter]

1.  As for .DDS, I will get a sample and try it. IF it works we can use it the way it is for development.  And deal with compression conversion and 64 bit later.  If it does not, then the format is a no go.  But I still do not understand why, as textures are loaded BEFORE any combat occurs, so the extra couple seconds for the tactical/combat loading screen is not an issue.

2.  As for model size vs count, I figured around 60 models.  Each ship AND each torpedo is a model.  I already had a torpedo model given to me.  For performance, we will wind up utilizing the power of modern processors and GPU's.  The physics engine will utilize the GPU for collision.  The game itself will utilize multi-core processors.  And that includes SIMD support in the DirectX drivers.

[Starfox1701]

The why on compressed .DDS is simple. Not counting Id maps the average mesh will have at least 2 different textures and each one of these textures, if we are utilizing graphics to the fullest will have a specular map, a bump/normal map, an effect map, and a illumination map. Point is if we don't find a compression method we are looking at using 400 to 800% more memory and video memory to do the rendering ingame.

Possiible solution might be found here

http://en.wikipedia.org/wiki/Adaptive_Scalable_Texture_Compression

http://malideveloper.arm.com/develop-for-mali/tools/astc-evaluation-codec/#astc-evaluation-codec

https://www.khronos.org/news/press/khronos-releases-atsc-next-generation-texture-compression-specification

Its OpenGL and aimed at DX11 hardware.

The whole S3TC thing is a real pain in the arse. I can't find out what the actual terms of the license is and therefore can't figurout at what point our game would no longer be covered under the licenses held by Microsoft and the hardware manufactures; much less get a price on buying one.

[[UFP]Exeter]

Once the textures are loaded and uncompressed they take about the same size.  Part of the reading is to uncompress and place in the appropriate format for the GPU.  The advantage to DDS is it is already in this format so loading is faster. 

We also need formats that support the Alpha Channel, so PNG and DDS both do.

Open GL is not a real good option, right now support to version 2 and no idea when it will get better.

I have 2 large models in OBJ format that I would like to use as alien "God Ships"  one a massive battleship and the other a massive carrier.  If we can convert them to .x format, I would be fine using it.  The largest has 750,000 polygons.

What I can tell, other that faster load time as the conversion to proper format for the GPU,  DDS is faster but PNG works well also.
Model format, the same reason, loading.

We should test this, I have 2 ships I am using for my testing.  A Romulan Warbird in milkshape with textures.  And an Akira, in 3ds.  Can we convert those to .x and dds to test?  I will rebuild irrlicht to support dds.  But, do we want to disable the ability to load other formats?

[Starfox1701]

Once the textures are loaded and uncompressed they take about the same size.  Part of the reading is to uncompress and place in the appropriate format for the GPU.  The advantage to DDS is it is already in this format so loading is faster. 

We also need formats that support the Alpha Channel, so PNG and DDS both do.

If it is coded so that DX or the hardware does all the uncompressing those actions appear to be covered under existing licenses held by those companies in the same way creating a .DDS file is covered under Navidia's license when done in Photoshop.

Open GL is not a real good option, right now support to version 2 and no idea when it will get better.

OpenGL is up to version 4.2 or 4.3 now. Version 4 is specifically aimed at being used by DX11 compliant hardware

I have 2 large models in OBJ format that I would like to use as alien "God Ships"  one a massive battleship and the other a massive carrier.  If we can convert them to .x format, I would be fine using it.  The largest has 750,000 polygons.

750K is too big. That is a low end movie or TV level mesh. ILM's 2009 Enterprise mesh is not much bigger then that.

What I can tell, other that faster load time as the conversion to proper format for the GPU,  DDS is faster but PNG works well also.
Model format, the same reason, loading.

We should test this, I have 2 ships I am using for my testing.  A Romulan Warbird in milkshape with textures.  And an Akira, in 3ds.  Can we convert those to .x and dds to test?  I will rebuild irrlicht to support dds.  But, do we want to disable the ability to load other formats?

Right now I would recommend Blender for the model conversion unless you have 3DS Max and can use it. Gimp or Photoshop for the texture work. I don't think we need to disable the ability to use other texture formats; I just know that with the available tech that .DDS is the best format available to use. It is a question of efficiency in our work flow. By focusing our effort to a single model and single texture format we make it easier to build up or collection of assets because the creation process becomes standardized and it is simpler to train new staff when the come on board.

[TheStressPuppy]

Like i said it is best to make the best looking mesh possible with as few triangles as possible. Not saying budget to the point of crappy looking meshes. There are workarounds to using 1000's of unnecessary triangles. Those of us who worked on old games like Homeworld, and SFC know this more than anyone else. 10-15k in triangles to be honest is a very reasonable count for a TMP era Constitution in modern hardware standards. i believe Kalibans connie is around 10K if i am not mistaken, and CG's Sovereign, and Galaxy is in the 15-20k range. 10 years ago that kind of count would be out of the question.

I would be more concerned with Texture Resolutions, and using very large memory hogging textures like TGA, PNG etc. etc.. DDS is the best choice to go with since DDS is designed specifically for modern gaming graphics. Since you say you are coding this in 64 bit. Then you wont have to worry about a 2 gig memory limit that most 32 bit games have. Still i would lean on the side of conservatism with textures. 2048 being the standard resolution, and 4096 for supersized units like, Stations, and planets. "IF" 4096 resolution can be run without going over limits, and causing extreme lag on modern systems then i say go for it. People are not gonna want to buy gods own computer to play the game if we overkill on the graphics.

I noticed a discussion about "sprites" before.. WTF are you guys talking about?? In modern games we use Particles now lol. Particle effects for weapons. Particle effects for hit, and damage effects. You can probably make "scar" texture overlays like what Homeworld 2 does. You can probably take it a step further, and ginsu ships like in Klingon Academy (AFAIK the ONLY game ever that used ginsu effects). If this is in 64 bit the possibilities are only limited to skill.

[[UFP]Exeter]

ok, I will enable DDS in Irrlicht.

OpenGL would require writing the graphics to use it, unless Irrlicht updates OpenGL.  That can be for the future.

The 750K poly model is an OBJ I obtained from a site of 3D modes.  Very detailed the other is about 356K poly

Ok can use Blender and even have a book to learn it

So now I need something is .x with DDS texture to use for testing.

[[UFP]Exeter]

I have done testing and 2048 seems good quality and loads fast.

DDS for modern graphics cards?   This is as old as DX 8, and has been updated twice to be able to work with modern graphics cards.  This format is OLD.

I have two giant models I want to use as alien GOD ships.  Not just poly count be they are massive in size which is what I want.

[TheStressPuppy]

BMP, TGA, and PNG are even older formats than DDS (look it up). Unless there is a new image format out there that i am not aware of. Mass Effect 3, The BF, and COD series uses DDS format as well as damn near every other modern game in existence. DDS as far as i know may be old, but its the newest format out there. Plus it has many advantages like the mip mapping (lodding) feature that all of the other formats do not have. The only disadvantage to DDS is it image quality compared to TGA, and PNG. However for game performance that disadvantage can easily be overlooked.

The "God Ships" could be considered "Supersized Units" if they are really large in scale, and you probably would want to go 4096 resolution with them.

[[UFP]Exeter]

The "God Ships" I purchased for this, so they can be adjusted.  I do not have the skill in doing that. 

I am fine with DDS, our only issue may be the decompression, depends on the one supported with GIMP and or Photoshop.  That I will look into as the code needs to support it and we we can avoid use of S3T we are better off

[TheStressPuppy]

So you are the primary "Code Monkey" for this project. Don't be insulted. I call all programmers Code Monkeys   So it is safe to assume that you have no 3d modeling, or 2d art for texturing experience correct? Though i see you are willing to learn blender, and are exploring what you can do with modeling.

Last i checked the Dynaverse community had an army of 3d modelers, an 2d artists. However its been a while since i've been here. I saw the SFC4 thing and it caught my interest. If anything could get me out of modeling retirement it could be this. However i don't want to model saucer's with "bolt on nacelle's", and call it a new class of ship. Nor model absurd ship designs that obviously do not belong in Trek.

SFC is what got me started in modeling, and you can thank Moonraker for that. I know Damn near all versions of 3dsMax up to 2011. I worked with several versions of Lightwave. I messed with Maya then threw it out the window. I know a little Softimage XSI. I started modeling with Milkshape, but now i only use it for duplicating, and mirroring stuff. I am pretty handy in Photoshop too.

On the other hand. I know absolutely NOTHING about programming. Except that it is a pain in the ass. So though i call you a "code monkey" you got respect. I got as far as "hello world" in C+. Then I smashed my old CRT monitor (gave me an excuse to buy a flat screen monitor). I have zero patience for coding.

[[UFP]Exeter]

So you are the primary "Code Monkey" for this project. Don't be insulted. I call all programmers Code Monkeys   So it is safe to assume that you have no 3d modeling, or 2d art for texturing experience correct? Though i see you are willing to learn blender, and are exploring what you can do with modeling.

I have done photoshop and played around with Blender, Milkshape and other.  I like the 'artistic' flair, as I have the technical mindset of a code monkey  (Like that term).  Basically correct in your assumption, but i can take a 3d model and textures, put them on the screen rotate, scale, move a camera etc.

We are planning for the races:  Federation, Klingon, Romulan, Cardassian, Dominion and pirates.  We also are planning on at least 6 classes ov vessels including some that there are no cannon models to use.  And a race that is "unknown" and of course aliens galore.

My attitude and opinion, is a medeller should take on one "race" and design the ships.  That way he can design in the aspects that make them look like they are of the same race.  And give them cretive leeway, except it should look trekkish for the appropriate race.

[[UFP]Exeter]

I did find this, relating to Civilization but provides details on creating DDS using GIMP.

http://forums.2kgames.com/showthread.php?119335-Adding-Images-%28DDS-Textures%29

[[UFP]Exeter]

I used Blender to convert my MS3D warbird to X and gim to conver the two bmp textures to dds, using DXT3.

I enabled the DDS in Irrlicht.  Rebuilt the code

Other thatn the model rotations beind different, I was able to read the model properly.  Even looks like the textures look a little crisper.

all 32 bit version bur it works.

[Starfox1701]

TheStressPuppy any opinion on model formats to use in game? Right now we are looking at .X files and some of the DCC files like .3ds.

Overall I see ships running from 10K to the 20 or 25K range.  Shuttles and fighters should really be no more then what 1500 or 2K. Stations should be 10K to 40K range. We spend polies smart. We can do the rest with textures. On the texture size hears what I think we go with 2048s as the standard. We use  4096s for meshes that have must have 4 or more 2048s so we can unify the mesh as much as possible to improve performance. Shuttles and fighters can start at 1024s. One thing I'd like to do different from other SFC games is instead 6 or 8 hull types that are recycled for all the different variants; lets try and actually do as many different class for all the different variants. With the TNG time frame we can draw designs going all the way back to KA. New updated models would look great and have real history.

I did find this, relating to Civilization but provides details on creating DDS using GIMP.

http://forums.2kgames.com/showthread.php?119335-Adding-Images-%28DDS-Textures%29

Good find, it will help out the gimp users

I used Blender to convert my MS3D warbird to X and gim to conver the two bmp textures to dds, using DXT3.

I enabled the DDS in Irrlicht.  Rebuilt the code

Other thatn the model rotations beind different, I was able to read the model properly.  Even looks like the textures look a little crisper.

all 32 bit version bur it works.

Cool try the DXT5 next

[TheStressPuppy]

You should look at Sins of a Solar Empire. How it uses its textures IMO is the most effecient. You have the ship UV mapped to a single 2048 sheet. However each mesh uses 3 separate texture sheets. One for the color, or diffuse map. With an alpha channel for team color. The second texture fills the roles of Specular map, Illumination map, Reflection, and the alpha is used for Bloom effects. Each RGB color channel has a separate role. For example the Green channel is used for illumination, The blue channel reflection, and red channel is the specular map. This saves having to use of 4 separate textures to do all of this. Then another separate texture is used for the normal maps. This is all done with DXT5 DDS textures.

Photoshop does have a plugin for DDS format if they didn't finally incorporate it natively in versions beyond CS3. Gimp can work with DDS format, but i am not sure how well.

I would use ether the direct X model format, or .3ds. Most modeling programs can save, or import/export in those formats. Including Blender IIRC. If your model viewer is going to be anything like the NanoFX Evolved viewer. Direct X would be the way to go. Unless something better came out that i am not yet aware of.

I am all for design consistency. As long as it makes sense. In Trek everything on a ship served a purpose. In SFB basically they added a 3rd nacelle, or moved the arrangement around slightly, and called the ship a new class. That is what i would like to avoid. We all know the Federation used similar components on different ships. For example the TMP Constitution, and the Miranda, or the Galaxy, and Nebula Classes. I can live with stuff like that, but the Galaxy X just made me do a facepalm. Don't even get me started on the Alien designs for SFB. Especially the Romulans. What SFC did to the SFB ship designs made a lot more sense. I must insist that any new ship designs must make sense, and serve a purpose, and NOT be put in just because they "look cool". That is the heart of Trek.

[Starfox1701]

Should the ship list define the ships, the ships define the list or something in between?

[TheStressPuppy]

The ships should be "unique" for each class, and even more unique for each sub class, but obviously have similar racial characteristics. Nothing says that all Romulan ships should look like a bird. That is automatically assumed when you think of a Romulan ship. I don't believe they all should be the same design scaled up, or down, or even be "bird like". On the other hand we don't want them to be flying tin cans with a bird emblem like the SFB designs. FASA had an interesting take on the Romulans. Each class should be "unique", but they should have characteristics that make them distinctly Romulan. Even if they did use Klingon Technology. Atolm has some very interesting Romulan designs.

We have a good idea on how the Feds should be since there is a lot of canon material to go by. Even the Klingons have a lot of canon stuff. It is the rest of the factions that we have to find ways to flesh out.

[[UFP]Exeter]

DXT5 also works well.  I used GIMP 2.8.2 with the above mentioned add.

I also used Blender 2.6.7a


FYI  Irrlicht has a limit of 9 texture files per model.

I agree ships should be unique, but still be able to notice similarities (in general). We do have evidence of Romulans obtaining Klingon battlecruisers.  But enough changes to tell the difference.  I had planned on 6 classes per race but that is easily changed, the limitation is models.  If we get enough models.  We can also have empty "slots" for players to add their own models.  I have a list of 15 classes of combat type vessels to use in game.  With 6 playable races, that is 90 different ships and each can be configured. 

[Starfox1701]

The limit on textures might be problematic; can that be changed? And does that include all of the various supplemental effects textures like normal maps and such?

[TheStressPuppy]

9 textures IMO would be overkill, and a waste. Especially if you UV map a ship to a single 2048, or 4096 sheet. If you UV map the ship to multiple sheets like old SFC. That could become problematic as well. The best thing to do is UV map the entire mesh to a single texture, and use the additional textures for effects.  It would be assumed that some of these textures are for the ships effects (Illumination, Normal, Bloom, Specular, etc.). Speaking of which. Will animated textures, and mesh animations be supported?

[Captain Adam]

.

[TheStressPuppy]

I hope you are not taking what i am posting the wrong way. I am not trying to tell you what to do with your project. I am only offering advise, and suggestions. How you ultimately decide to do this is totally up to you.

[[UFP]Exeter]

Animations can be done.

As for opinions, I am not a modeller.  My preference is whatever is suggested is something that can be done in irrlicht without changing it.

But remember, we can also do our own shaders.

May I suggest taking a look at irrlicht.  Modelers do not need to know how to do things in code, that is my job.  But would help to know what it can do.

[TheStressPuppy]

Already checked it out. Seems that its only 32 bit, and only supports windows XP. That kind of worry's me. However you are a code monkey, and are talking 64 bit. So i will let you do that thing you do. You make it work. We will worry about meshes.

All i need to know is what the poly budgets are. What the Optimal texture resolutions are. What kind of shaders the engine supports, and how they are implemented. How hardpoints are done (ether by scripting, or actual points on the mesh file). Perhaps a guide on how the particle effects are done (would help for TNG style phaser charge up effects). Plus any Animated texture effects (Bussard collectors, and various other ambient effects you see on Trek ships). Plus little odds, and ends like Nav Lights (would be done using the hard points obviously).

Is there a plan on restricting firing arcs? So a ships weapons don't fire through their own hulls. That annoyed the hell out of me in SFC. Plus if you intend on 3d combat firing arcs will be very important.

[Starfox1701]

Well right now I think a max budget of 25K polies for a starship is not outlandish. 2048X2048 DXT5 .DDS files is the standard for textures. Not sure how the I know we want normal maps, an FX map, and an illumination map and spec map but I'm not sure what the particulars for things like naming are yet. Plan for hardpointing is to use an as yet un built model property editor functionally simmallar to the NanoFX viewer.

 

Perhaps a guide on how the particle effects are done (would help for TNG style phaser charge up effects). Plus any Animated texture effects (Bussard collectors, and various other ambient effects you see on Trek ships). Plus little odds, and ends like Nav Lights (would be done using the hard points obviously).

Most of this is still being hashed out so if you have ideas or suggestions feel free to offer them up.

Is there a plan on restricting firing arcs? So a ships weapons don't fire through their own hulls. That annoyed the hell out of me in SFC. Plus if you intend on 3d combat firing arcs will be very important.

I think the best method is to set the weapons Hps so the won't ever fire through the mesh. Then it is just a mater of placing them properly. The best thing about this is that you will get true arcs as the weapons will only shoot what they can see.

[[UFP]Exeter]

Already checked it out. Seems that its only 32 bit, and only supports windows XP. That kind of worry's me

Currently it is DX9C, but DX11 drivers under development.  I have downloaded the latest that is under development and currently the only issue is with the shader pipeline.  And irrlicht provides 32 bit libraries, I have already made 64 bit, and they work.  Issues is with DDS, but will deal with that when we get to it.  I have a base structure loading models and textures, and I am on Windows 7 64 bit, so irrlicht works fine.   The backup plan, is to rip Irrlicht out and do the DirectX 11 ourselves.

Firing arcs will be determined in code.  To clarify each weapon type will have a firing arc.  The game physics will then determine if the weapon can fire or not.  With the vector to the target, and the base direction vector of the weapon, a quick dot product gives us the angle between. 

There is actually a particle effects tool that works with irrlicht.  CopperCube 3D.  But, we can also just use raytrace and generate a "beam" and used different shaders.

Which is something to look at.  Seems to be we are putting alot in model code and or textures that can be handled by shaders.   We will have the ability to use Shader 4, so thee is alot we can do that older games never could.  Shaders are developed in code, and using parameters we can alter the characteristic.  For example one shader can handle beam weapons and by altering parameters we alter how the beam looks.

[Starfox1701]

Firing arcs will be determined in code.  To clarify each weapon type will have a firing arc.  The game physics will then determine if the weapon can fire or not.  With the vector to the target, and the base direction vector of the weapon, a quick dot product gives us the angle between. 

Will that be memory intensive in large battles?

There is actually a particle effects tool that works with irrlicht.  CopperCube 3D.  But, we can also just use raytrace and generate a "beam" and used different shaders.

Which is something to look at.  Seems to be we are putting alot in model code and or textures that can be handled by shaders.   We will have the ability to use Shader 4, so thee is alot we can do that older games never could.  Shaders are developed in code, and using parameters we can alter the characteristic.  For example one shader can handle beam weapons and by altering parameters we alter how the beam looks.

My concern is over use of shaders. I remember them as being very memory intensive; at least they where in Legacy. Is that still the case?

[[UFP]Exeter]

Firing arcs in code will not be memory intensive, as the data is stored in the heap with pointers.  The is compiled inline so it will be fast.

Shaders are much better now, in fact they were completely redone in DX11, which is why anything is DX9 needs a rewrite to work in 11.

[Starfox1701]

So would we have to script specific arcs in the ship files or would the weapons Hp calculate true arc not firing through the ship ever? Also how exactly would shader driven weapons effects work?

[[UFP]Exeter]

I think the best solution is a combination.  The game will know the maximum arc for the weapon, but the code will be unaware of any constraints imposed by the model.

So I think the weapon standards are part of the game, and scripts can override.  Such as reduce not increase.


For weapon effects, in the creation of the object in the engine, a shader effect an be provided.  Shaders can take parameters so it is possible to use the same shader but alter how it looks.  For example I have a torpedo model, by using a shader it could be a photon torpedo or a quantum torpedo. 

[Captain Adam]

.

[[UFP]Exeter]

Seems to me, based on the actual movies and series, photons and quants are slower than beams and faster that plasma.

[Starfox1701]

Photons and quantums are actually very vast and can function at both warp and sublight speeds. On the note of phasers from the fluff they are supposed to move at light speed but I found that in modding Armada 2 a beam speed of between 1500 and 2000 m per sec produced effects that very closely match what we actually see on screen. The beams themselves where also quite often a looped animation ant runs down the length of the beam. This provided a further since of movement. Plasma torps are only ever seen for sure in TOS and where suppose to move at very high warp speed. I can't ever recall a romulan torpedo fired in TNG or DS9 though the Cardassian weapons platforms where also suppose to have plasma torpedoes and as I recall the where just yellow photon type animations.

[Captain Adam]

.

[Captain Adam]

.

[Starfox1701]

I would say that we script a base hit probability based on how advanced they areand then add additional variables that raise or lower the chances of a hit and let the math do the rest. Speed can also vary based on how advanced they are. TMP torps should be slower then TNG torps but still faster then the ships. They should be at least twice as fast as the ship they are tracking and probably no more then 3X as fast.

[Captain Adam]

.

[Starfox1701]

Well that's the point of scripting instead of coding them.

[[UFP]Exeter]

Yah I now, some of you want everything scripted.  We could do the entire game is LUA, so everything is scripted.  You may need a Cray to run it.

I have done alot of google searches on the weapons, except for damage very little change in range or speed between TOS, TMP, TNG etc.

Most dat such as damage etc are not :hard" coded in the game but will be stored in another media.  This media moders will have access to to create their own. 

[[UFP]Exeter]

Right now I am working on model loading.  As we will focus on .x format, probably coded in Blender, I need to work out the translation vector.  Problem is I do not have a .x model created in Blender.  I do not need textures, just a model that will tell me what coordinate the bow is on. 

Sort of a standard for models.

[[UFP]Exeter]

I am working on loading models and having them properly locate.  But, to do this correct I need a model centered and the axis defined as our statndard.  I look at some sample models I have with blender and the ship is not even centered in blender. 

[TheStressPuppy]

Once i get my models packaged up ill send them. they all should be centered properly. Sorry its taking so long lots of RL stuff going on. I am assuming the Z axis according to 3ds max is up, or is it the X axis? ether way can orient accordingly.

[[UFP]Exeter]

We use Left hand rule, DirectX, so X is right, Y is up and z is inward into the screen.

However I can re orientate if I know how the model is set up.

And which axis the bow is on.

[Starfox1701]

Why is DX set different to standard XYZ stuff?

[[UFP]Exeter]

For graphics display it is generally the Left hand or Right hand system, Directx uses left hand.  That means +X is to the right, +Y is up and +Z is inward into the monitor (away from you).  The coordinate system for programs like blender, Studio Max etc do not use that.  I can rotate it easily enough but I need a base model with the the coordinate system the model programs use as a standard.  For example blender uses Y to the right, Z up and X outward.  I am fine with it we just need all models the same.

[Starfox1701]

I believe that when a program like max or blender exports to .X format they automatically convert the model from 1 setup to the other as part of the export process.

[[UFP]Exeter]

Blender is a right hand coordinate system and directx is a left hand.  Would be simple except the .x exporter from Blender may or may not switch,  plus most packages allow you to change some of the coordinates.   

The isisue is I need a model with a known system, that will be our standard.

[Starfox1701]

Why wouldn't the exporter change it? The different coordinate system is fundamental to the .X format according to the information you provided. If the exporter should change the system from what the DCC program uses to the models format uses because this is part of its basic function. Do you have any reason to suspect the exporters are busted?

[[UFP]Exeter]

Other than I tried once at it did not work, no.

But I took a milkshape model imported into blender the exported to .x and the rotation is all wrong.

I am testing models on line, anything, but need one for blender that is centered and ready to go.  then I can export in .x and work on it. 

[[UFP]Exeter]

Just tested.

Obtained .x model from XNA  orientation is left

milkshape model orientation left

3ds model orientation left

the milkshape model converted to .x,  orientation shifted 90 degrees.

[Starfox1701]

So based on that info I would infer that reorientating the model will be part of the export process. Is there any documentation with these exporters that specifies the need changes or is it going to need to be done by process of elimination?

[[UFP]Exeter]

I have not found anything, so I am going through process of elimination.  Thing is I have tried some 3ds models and they are all over the place.  I do know blender used right hand (OpenGL default)  so I am thinking on that being the standard and build in a rotation for any model.  Not sure this can modable as too many things relating to the camera, physics and collision detection depend on proper coordinate systems.

[Starfox1701]

I don't think that needs to be modable. In fact this is one of those things that I think needs to be standardized so we can tell model makers "if you are using DCC X use process Y for exporting and if you are using DCC A use process B.

[[UFP]Exeter]

Agreed.

I am trying to figure something out as I am at a stand still without this, the models do not match, and this affects the graphic display, setting the cameras up and the physics engine.

[[UFP]Exeter]

Shall we use blender as the standard modeller, expporting to .x?   Anyone may use what they wish but up to them to match blenders format

[Starfox1701]

Recommending Blender as the preferred DCC platform for models is OK but I think it would be good to develop export procedures for 3DS Max too. While that program is not as common because of the price tag many of the various communities best modelers use it. Doing this would encourage them to participate in this project.

[[UFP]Exeter]

As they would have good experience if we specified the requirements then they would be able to adjust 3dmas.  For example the coordinate system, orientation, scale factor etc.  I have access to an older version of 3Dmax, so can check it out later.  Worse case blender can import 3ds and export .x

[[UFP]Exeter]

I am almost at a point where I need at least 2 models to work with.

But, that means in our proscribed format.   Which is .X with dds textures.  The models can be created in blender and exported to .x   If possible I would like one done in blender to work out some details.

Also, we need to determine the details of the models in blender.  for example, does the bow point toward the +x or what?   The standard size of a model?  Naturally the model can be scaled to reflect the relative sizes.

If there is a way to read a model and now this information, I have not figured it out.

[Tus-XC]

front should be +x, it should roll around the x, pitch on the y axis and yaw about the z axis.  as to model size, 1 to 1 is always nice as it removes the need to figure out scale.  Failing that 1/20th scale is how sfc did it.

[[UFP]Exeter]

Interesting, checking some other sources indicate the rule of thumb (maybe) is for the model to point toward the -x axis.   But I am fine with your suggestion, I just need a standard from those experienced in this.

As for scale, my concern is two different models, the NCC1901A an and Klingon D9 Battlecruiser.  And due to the size of the models the battlecruiser display 10 times larger the the Constitution class.  Again what it is does not matter to me, jsut need to know to build it into the code.

[Tus-XC]

its just the way my head works, + x is the direction of travel for me, but if -x is the standard, that's fine.  My main concern is how the axis are used, roll about x, pitch about y, and yaw about z.  Scaling of the model is done by the modeler btw.  a connie and a d7 or a d9 have an actual scale to them.  for instance, a connie is about 189 m in length.  What i'm referring to is how the game engine will take that information.  will I need to change how 1 unit is registered by my software.  for example, 1/20th is my current setup (1 unit is 20 m)

[Tus-XC]

and what format of .dds should I be using?  there are a gazillion of choices in the dropdown when i try to save my file in .dds lol

[[UFP]Exeter]

that is logical given the standard coordinates for aerodynamics.  I will convert as graphics is different.  But as long as we have a standard I am good with it.

I checked out a few models an it appears the axis orientation between studio max and blender is different.  The default for milkshape seems to fit your description.  And I know that the axis can e changed.



The formats are the compression level.  Compression DD5 / AT12 (3Dc)  if using Gimp.

[[UFP]Exeter]

Found the math.

Yaw is counterlockwise around z

Pitch is countercloskwise around Y

Roll is counterclockwise around x.

And we will use +x for the front of the ship.

So pick a scale and define what it means and we will use it.

[Tus-XC]

nope, +z is up (away from earth), x is direction of travel and y is perpendicular to the plane those 2 form intersecting both those lines (at least that's how it is when dealing with satellites, which I'm fairly confident is the same for aero stuff)

edit:  opps, ya edited just as I replied

[Tus-XC]

that is logical given the standard coordinates for aerodynamics.  I will convert as graphics is different.  But as long as we have a standard I am good with it.

I checked out a few models an it appears the axis orientation between studio max and blender is different.  The default for milkshape seems to fit your description.  And I know that the axis can e changed.



The formats are the compression level.  Compression DD5 / AT12 (3Dc)  if using Gimp.

guessing that would be dxt5 in photoshop w/ an interpolated alpha... any particular way you want the textures handled? one sheet, two sheet 3 sheet...   I'm used to making one map for the diffusion and one for illuminations...

[[UFP]Exeter]

However you choose.  The system will handle up to 9 textures.  If you check out irrlicht that is what I am using for the 3D graphics.  Too lazy to learn Dx 11

[[UFP]Exeter]

You realize of course blender uses the right hand system and dx uses left.  But I think I will build the conversion into the program.

[Tus-XC]

Ok, here is a model, it simple (its just a planet) but it uses inverted faces to simulate the atmosphere (1 sided mesh, so you can see through it to the other face) which I imagine is pointless in your engine, but is something I do for sfc.  textures are 4096x2048 - its my working size, so you've been warned.   this is 1/20th scale btw (1 unit = 20 m) and the planet has a radius of 6378 km (that would be earths radius btw...)  so its large... (well not poly wise, just scale)  btw, if you dled already, that one was a radius of 6378 m (realized I used the wrong value after I exported...)

https://www.dropbox.com/s/bl3lfcs72klcbf0/Test%20Planet.7z

[[UFP]Exeter]

Thanks, however to get the model rotations working I need a defined front and top.  Maybe markers?

[Tus-XC]

copy that, i'll add markers to the texture

[Tus-XC]

new file uploaded, textures have axis labeled

[[UFP]Exeter]

thanks, that will help alot!

Did you use Blender for this?

[Tus-XC]

no, 3ds max 8

[[UFP]Exeter]

I have an older version lying around but never took the time to learn it.  Decided to hone my skills in programming.  And not really an artist. 

Would you mind publishing your specs (orientation, scale etc), it works and I can use that as the basis.

Thanks very much

[Tus-XC]

sure

scale 1/20th (1 unit = 20 m)

axis rotation: Right hand (counter clockwise)

export settings (using pandasofts directx exporter): (only minor changes done, tabs listed)

3ds Max Objects:
object options-
Mesh definition checked
Materials checked
include animations unchecked

object types-
geometric checked
dummy checked

Texture & .fx files:
texture conversion -
none selected
white diffuse override unchecked

.fx effect files-
include .fx unchecked

Photoshop CS3 - Nvidia plugin

used dxt5 from the dropdown

what else do you need (i'll just edit this post with the additional stuff)

[[UFP]Exeter]

Looks good to me.

Do you think that scale will work for ships?  I have no problems with different scales as long as I know what they are.

[Tus-XC]

depends on what you are trying to do.  1/20 is the default for max.  now how you want to scale planets to ships is up to you.  a planet (6378 km radius for earth) compared to a ship (connie 189 m) is a pretty huge difference.  (o I don't think the version you have has the correct texture files, might want to dled one more time to be sure)

let me do a render of a ship to compare so you have an idea just how big a disparity it is.  from there we can determine proper scales for stellar bodies.

[[UFP]Exeter]

That works. 

[Tus-XC]

Please note that dot (find the pixel in picture 3... that's the ship... for scale, its 150 m in length.  the planet is 6378 km in radius.  The last pic uses a camera to show the ship and the textures (which are pixels at this point) for comparison).  The ship is approx. 180 km above the surface (not seen... that's is the atmosphere I made)

[Tus-XC]

btw... the nerd in me who studies this crap would love a 1 to 1 scale for planets (ie as seen)... the gamer in me tells me that this is probably not a good idea lol

[Tus-XC]

i'll do up more shots in a bit at various scales from that... need food first

[Tus-XC]

here are the various scales downward from 1/10th to 1/1000 (6378km*1/10 to 6378m)

[[UFP]Exeter]

I think to start we need to make planets a long distance away and if they get close, the planet gets larger.  Similar to STO.   But getting so close to the planet it washes everything out is something I would prefer to avoid 

[Starfox1701]

Well there are a number of tactics that involve direct interaction with moons and planets. I'm not sure if 1 to 1 is practical but it would be truly awesome to do. How big a map can we practically do? Is it practical to do a fully open setup like X Wing had with the map file containing the whole star system?

[[UFP]Exeter]

I thought about a continuous map, but I could not figure out how to do it and maintain the full 3D effect of the background stars and the variation due to nebula etc.

[Starfox1701]

OK so would a box the size of a star system be practical or would it be better to do something more like how Bridge Commander did things? Klingon Academy had very large star system maps. It would be nice to figure out how they did it.

[[UFP]Exeter]

My thoughts in a nutshell, very small one.   The galactic map will have a hex layout on it.  Clicking on a hex will cause the ship to go to warp and end up in that "sector"  Once in that sector the ship moves in that sector.  I consider them large, large enough players want to use warp.  I was thinking of minutes (maybe 5) to cross a sector.  A secrtor may have more than 1 system, may have none. 

The 3D map is not a box.  It is actually a sphere with the tactical gameplay inside the sphere.  And you do not run into the sphere.

[TheStressPuppy]

I think BC, KA, and in some respects Eve Online use warp, or jumps as a "loading screen", but the actual combat is in a fixed "sandbox". Be it a Cube, Sphere, or Hex. In KA's case a whole star system can be inside that sandbox. I am not sure how they did it ether, but it worked very well. I would try to use KA's map system as a guide if you could.

There are a lot of things that Klingon Academy has done that have never been seen since. Like Ginsu. The huge system maps, and interactive terrain. Fighting inside rings, Asteroid fields, Gas giant atmospheres, etc. Plus the ability to use that terrain to your advantage, or it be used against you. Like what General Chang said. On a Klingon warship "Everything" can be a weapon.

True Scale, or 1:1 IMO would be a little over the top. Like what was said it would be "nerdgasm", but realistically it would put a huge strain even on the best of hardware. You can make some pretty convincing planets that do not have to be 1:1 scale. Epic Scale is good, but too much epic scale could come back to bite you, and take the fun out of it in the long run. We do want to finish a mission in a "reasonable" amount of time.

1:100 looks pretty good as a starting point. You can always tweak it from there.

[Starfox1701]

I know how the ginsu was done from a model point of view but not a rigging or programing point of view. The models are built up from a core component which has all the battle damage already applied and new parts are layered on until you have a complete ship. It is very time consuming to do as on small misalignment can mess up the whole ship. As much as I would like to see it done I think a modernized version of the Bridge Commander system would be both more practical and just as visually appealing.

[[UFP]Exeter]

The size of a sector is based on how big we want it.  The player never reaches the edge or it.   Movement on the Galactic scale map would be similar to SFC2, as there would be a hex overlay,  However it is not a move hex by hex.  Rather you click on the hex and you warp to that position.  If you cross paths with another vessel, if either decides to engage in combat, then you are pulled out of warp into the tactical screen.  Otherwise when you reach your destination you will leave warp and be in the tactical screen.

I would like to get the galactic map with good backgrounds including nebula, black holes systems etc.  And have the tactical maps match the look in the galactic map.

Oh, and if you are travelling at warp and you path takes you to close to a black hole, well you get yanked out or warp and have to get yourself away from the black hole.

And the gravity well of a black hole does effect weapons fire, even beams.  After all beams are an energy plasma.

[Tus-XC]

I think somewhere between 1/10th to 1/100th scale would be fine for rocky worlds.  (note this is within the 1/20 scale)  We will still need to work out gas giants though -ex.  Radius of earth 6378 km, radius of Jupiter is 69,911 km.  They might need to be reduced in size a bit in order to ensure playability - maybe 1/500.  I don't know about interaction, but it would seem to me you could use particles to create a gas cloud, and projection mapping to give it some variety - how did KA do this as I remember being able to fly into gas worlds?

[TheStressPuppy]

In KA you could fly straight through a gas giant. There was no atmospheric pressure so to speak. It did however mess up your sensors and targetting. Much like the Nutara Nebula did in ST:2. This is what i recall. It has been many years since i played KA.

[[UFP]Exeter]

We could scale planets by class.  Like an M class.

I think we could do a particle effect for a gas Giant.  I wonder if a spherical model, with semi transparency and the textures for a gas effect?  Not really sure how this could be done.

[TheStressPuppy]

You probably could do a "layered" model. 2, or 3 spheres each representing different layers of the gas giant atmosphere. Each getting worse as you progress. A 3rd layer could be made to represent the "point of no return" where you would get crushed if you enter it. Gravity could play a role too. If your engines are damaged too much you wont have the thrust to escape, and would fall into the crushing depths.

[Starfox1701]

Considering the disparity in planet and star size it may well be best to keep various classes to different scales. I would recommend 5 scales Large stars, small stars and large gas planets, small gas planets, rocky planets, Dwarf planets and asteroids.

[[UFP]Exeter]

http://en.wikipedia.org/wiki/Class_M_planet

lists planet classes in the various ST series.  There are multiple gas giant sizes/classes. 

We do not need to list them all, but my thought was we used them to indicate the size and classification.  Then we can use the appropriate textures on a standard spherical model and scale the entire model to the class specified.

Easier that a new model for each type of planet.

[[UFP]Exeter]

Some information on the DDS format.  If we use the compression, the decompression algorithm will require royalties, not sure how much.  If we do not use the compression, the DDS format is actually larger than the PNG format. 

Also having random issues, I can read the DDS format for textures but when I try to load a DDS image just for display, this does not work.  For the moment DDS will be ok on models but PNG for 2d images.

[[UFP]Exeter]

I am able to read the old mesh data from SFC2, but I have not figured out how to make the bitmap data work

[JanB]

If it's high quality models you want: I've collected a lot of those for SFC3 (ships and stations), converted quit a few from Bridge Commander mods myself. I've also polished them up (fixed textures that were a bit off, added break models, UI images, proper hardpoints, added illumination textures), because most mods just seem very unpolished and have fugly models/textures I wanted to make mine stand out in that department. Some of the models originally had 2048x2048 textures that I scaled down to 1024x1024 to shorten mission loading times and because you don't see the difference in SFC3, but I can help you find the originals on Bridge Commander Filefront. I have quite a lot of high quality space backgrounds as well. The space backgrounds are all mine so no futher permissions are needed, for the models you might have to contact some of the original modelers, or at least credit them.

You can use my work as long as you credit me in your ReadMe somewhere, it's pretty much all collected in one download, my SFC3 Upgrade Mod:

http://www.moddb.com/games/star-trek-starfleet-command-3/downloads/sfc3-upgrade-mod-30

If you need an excuse to put more minor powers ships in your game, you could use the system I use in my mod: every empire (except the Borg and Ferengi) have allied minor powers (for example the Tzenkethi and Tholians for the Romulans and the Breen for the Dominion) and access to a few of their ships. This also helps you "fill up" those empires standard fleets if you don't want to invent (or worse, kitbash) a lot of ship classes that were never seen or mentioned in canon Trek lore (in my mod the Dominion and Cardassians don't even have 7 stock ships of their own, the Dominion heavy cruiser is the Breen Warship, the Cardassian dreadnought is the big Son'a ship from Insurrection).

[Captain Adam]

.