Topic: Discussion on Models

[[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?