Topic: Why isn't there a common porting format for Star Trek 3D games models yet??!!

[Panzergranate]

I am an Electronics Design Engineer by profession and it amzes me how far behind the games industry is compared to industrial software.

In electronics we have a iindustrial standard common porting file type called GERBER and this allows any engineer with any ECAD package to export or import a complex electonics diagram from any package created in the last 20 years or from a future yet be written ECAD package.

Now electronics diagrams are a hell of a lot more complex when compared to the 3D models used in SFC, OP, BC, Legacy, etc. in that they contain data for virtual circuit simulators, industrial pCB drilling machines, the actual circuit design track layer by layer, compnent models and attributes, etc.

Evety ECAD one can by has a built in translator part that translates or encrypts the file into the correct format for that package to utilise.

Now here's my point...... why the hell hasn't the games industry come up with a similar common porting format yet??

Instead of us soles having to create a seperate version of a model for every concieveable Star Trek game model format, we could just upload a common encrypted version and it would be translated inot the appropriate file format for the game.

This would mean that even after the current Star Trek games have been superceeded, there would be a ready archive on Battle Clinic, for instance, of material that could be used. At present it would soon become obstellette.

OK I've been comparing the diffences between SFC 1, SFC 2, OP and several other model formats and the only difference between them all is how they encrypt hardpoints into a model. This also the major hastle of creating a model in a 3D package in that the hardpoints, rdpoints (tractors), SPP points (shield and shield bubble),
etc. are attached onto the model.

It is the hardpoint data that is the porting barrier between games.

Perhaps we the modellers could devise a common porting format that models could be stored under for uploading and with a suitable piece of 3rd party shareware,
decode it and use it in whatever Star Trek game (or non-Star Trek game) we choose. This would also ensure that when the next shiny new game comes along, our models can be uploaded and used on it.

Afterall we automatically accept that we can convert a TIF to a BMP or a JPG or a PCX, etc. without a second thought. Why can't we do this yet with our models, eh??!!

Does anyone understands the step forwards the gaming industry needs to make??!!

There needs to be a common agreed method of porting hardpoint data in models!!

Someone else must have figured on this out there as well, surely??!!

[FoaS_XC]

Simply put? Demand.
Games don't NEED to be portable, it isn't crucial to the industry, just to its fans. in the industrial engineering, versatility and compatibility is paramount to all but accuracy, i would imagine. With games you just need to get the engine to understand it, and to a lesser degree, keep it proprietary so other people can't just rip your work (thats why wou will never see the original MAX files for game models unless you are lucky).

[Mackie]

Not enough people use the lightwave to have a common format, they tend use some other  odd programs so have to convert each time :/

[Centurus]

Let's not forget, when was the last time a game developer actually listened to the people that would be playing their games?  Like Fury said, it's all about demand and propriety, which translates into money.  No money in it for the game industry to make models standardized.

[FoaS_XC]

Further consider: certain formats can't do certain things that other formats can. ie: a Wavefront OBJ can handle polygons with more than three sides, 3DS can't. NIF files can store skeleton data, MOD files can't. I suppose the Gaming indsutry as a whole COULD adopt a file format to do everything, but then that file format has to be able to do everything: why create a starship in a format that supports biped animation? - it would increase your filesize.

[Lepton]

I could be nuts but I think there are NIF files in Bridge Commander models.

[ModelsPlease]

I could be nuts but I think there are NIF files in Bridge Commander models.

There are
NIF = BC
MOD = SFC
SOD = Armada
KA = LWO

[Centurus]

I could be nuts but I think there are NIF files in Bridge Commander models.

NIF is also a format that's used in other games as well.  I used to know of one other game that used the NIF format for the models it uses, but can't think about it right now.  Bridge Commander uses the NIF, but slightly tweaked, for its purposes. 

[FoaS_XC]

I wasn't being literal, guys, I was just spouting off formats to show the conceptive thought i trying to get across.

[Adonis]

Well, basically, FOAS is correct. The issue are the vast differences between what those formats support. There's a distinct difference between the SFC1/2/3 *.mod formats for instance. And there's the huge difference between the BC *.nif, Morrowind one, Oblivion one, and so forth.

[manitoba1073]

 Ya the differences are far far greater than you can imagine. I think the most proggies ive used to do just 1 port is 6.

[Rod ONeal]

You could do it though. KA uses .lws just not all of the features. .X was designed to be exactly what you are asking for, a full featured universal game format. Most of the people using .X for games aren't "turning on" all of the features. You have to tailor your models to the capabilities of the game, that's all. Now, with that said. It doesn't mean by any stretch that you'd be able to just pull a model out of one game and drop it into another.

[Panzergranate]

OK I'll give you a "for instance" case.

I used to work a PCB circuit design proof reader a couple of years ago, which is like being the guy who marks engineer's work before production. Basically an Overseer-Engineer.

We manufacturered 3rd party PCBs from clients.

Right, now some of these clients used pretty acient PCB ECAD packages that didn't use embedded data for layers or dirll holes, cut outs, track layouts, etc. BUT I could still import them into a my modern Proteus ECAD package, make corrections, run a design rule check (A spell checker sort of thing but God level for circuits!!) adn then save it as an updated embedded file.

The package they'd used was from the mid 1980's and I was able to port it into a 2001 package, tweak it up to date and save it as the latest GERBER port file system.

On their package they pprobally couldn't run their circuit in viirtual simulation but in mine I could and take scope readings, measure thermal outputs and other cruicial tests to see if it would fly. Luckily it passed fit to spend hundreds of thousands of punds on a production run.

The GERBER common porting system isn't what a package norally saves as but is used when one wants to port out the core data of a design to another package or store in a long term archive.

The games industry needs to acknowledge that it is usually the fact that 3rd parties like us keep feeding in new material into their games to make infinate permutations of game play available, fix some of the bugs, etc.  that increases the profits that they are making. If SFC was on X-Box 360 it would soon become tiresome, like Legacy is, with flying the same ships again and again. There are only a finite number of permutations of ships available play the game with.

It is the 3rd party add ons that keeps the interest in a game going, and thus more profits as more people hear about and want to buy the game.

The GERBER system passes on the core data of the diagram and the software package interprets what other factor are needed to bring it up to speed with where it is ported into.

Even a core 3D data core model that could be imported and converted more easily to import into whatever game is required.

It would take the hours of hastle out of the painstaking conversion from one model format to another. Not needing package X with bolt on application Y would be just so nice.

[Starforce2]

unfortuneatley if you told that to the three competing entities that made sfc, armada 1,2,bc, and legacy, you'd probably be laughed out of the room.

[Panzergranate]

I think that's why engineers are slightly up the heirrachy than programmers, we can do both!! And design and build the computer that we're progarmming sometimes to boot!!

Programmers are still way up the tree from IT technicians though. I once spent half an hour trying to explain why a Duo Core processor is so wonderful and ended up feeling llike I was trying to explain a joke to a German!!

OK perhaps, I didn't quite explain the GERBER system that clearly.

The core data is iimportant is the only thing transfered.

The importing computer can look at the core data of the port, in our case the 3D model and interpret where certain features and attributes used in its own package should go. It fills in the blanks correctly usually.

OK say I build a virtual PC card on computer and package (A) complete with virtual EPROM programme.

I save it as a GERBER onto CD. The Gerber only carries the PC card schematic.

I then port the GERBER into computer and package (B). without the EPROM programme.

Package (B) interprets the GERBER of Package (A)'s diagram and displays its own interpretation of the design.

Now package (B)' depictaions of compnents and colours will be different, just like handwritting between people, but it will still be the same diagram and it will still simulate the same way as it did on package (A) once the virtual EPROM had been programmed again.

OK, if we can't have anything as wonderful as that, perhaps something that at least allows porting of enough model data to take some of the hastle out of converting between games.

From an engineer's point of view,a model in any game is just binary data encrypted in a special way unique to that game. Some of that dat refers to the mesh coordinates, some to textures, some to hardpoints, etc.

Now it is posisble to pick out the mesh and texture map data and port that in a common porting format.

The importing system is able to interpret the porting format and convert the data into the bare mesh and texture model. Then the user has to put in all the hardpoints, etc. before its ready to go.

Trnalating a message from one language to anither and from that into a third seems to work usually.

For instance "Two beers" in English, "Zwei Bier" in German, "Va Piva" in Czech and "Deux Biere" in French all mean the same thing.

If someone is babbling at you in a foreign language that you don't understand your brain will still instictively understand the important part of the message refering to beer, hopefully.

Now the importnant part of the model data is the model shape and texture maps, hardpoints and other stuff can be added later. I have to do hardooints to so many models I download anyway where folks can't be arsed to, before I can use them.

I'm not saying that all the 3D modelling packages should all save to a common format but instead that there should be a common porting format to tarnsfer the basic model image between modelling packages and that could be loaded into 3rd party downloadable shareware translators which would convert to the then latest game model format.

At present there is a lot f faffing around to just transfer a model from BC to SFC via some 3D modeling package alng with other hastles, expense and time. And if you want to tranfer the same model for BC to something else you have to go through it all again.

Now if you could just transfer the modle in BC to a common porting format, by some 3rd party software magic and then store this porting file version. When a new game comes out, a 3rd party software converter would appear soon after and then it would be just a case of feedinf the porting file through it into the new model format.

If it can be done with complex ECAD schematics, photographs and a few other things, then why not models??

 

[FoaS_XC]

We follow you, and believe me we all recognize the value of a totally universal file format between all sorts of packages from lightwave to max to maya to truespace to carrera.
Two Points:
1) we weren't dismissing the validity of such a concept, merely the impracticality of waiting around for one or waiting for the gaming community to see the light, as it were.

2) have you ever used 3ds max, maya, lightwave, or any such package? you are obviously well versed in electrical engineering, a field i know next to nothing of, but spend a year in the 3D field, and you'll understand. Its not just the different programs are speaking different languages (though, that doesn't help) they are saying different things.
example: I am currently rigging up a character in 3ds max. If i were to import the character from 3ds max into say poser (a gross comparison, but you'll see what I mean) Poser doesn't even have the means to recognize a quarter of the things my character rig is made up of.
Maya has a painting tool where you can draw volumetric objects. 3ds Max doesn't even have anything close except a hair simulator and thats by a stretch of the imagination. Lightwave has global illumination built right into the renderer, 3ds Max didnt have GI until version 5 or 6, that is without mental ray. Hell, Milkshape doesn't even render anything.
My point is, yes 3D applications overlap 80% of the time. There are plenty of formats within 60% that can transfer between packages, the rest is just a little bit of diligence. the other 20% depends entirely on what package you are using in the first place.

Further, the overall moral is: don't get caught up in the tools you use to make the art, get caught up in the art.

[intermech]

I would be all for a consistent format, but I have no pull with game creators. Are you bringing this up because you are volunteering to create a method for streamlining the process? If so, any way I can help, let me know!

[Panzergranate]

I more used to programming embedded systems in that old ancient programming language of the mystic, assembler and sometimes a bit of C. If things require, a missionnspecific compiler is conjoured up in Forth, the language compilers are created in. Forth is a programmer's nightmare so I avoid using it unless unavoidable. Having to first create the compiler and then write the code is complex.

I just wanted to moot an idea and concept, as planting these into various minds will  hopefully bear some fruit.

However I can figure how the project might run.

The first logical step would be to examine closely the way the data for the various game model formats is encrypted in a file, its order and sequence, etc.

Then a comparison study to recognise any common parts between the file types and what the differences are.

Imaging how codes are cracked by cryptologists. OK you look for common repeated letters, usually E and a few others. Thhis gives a reference frame to work with.

All the game model format files must store the basic mesh's details, which should be recogniseable no matter how it s encrypted, due to its size. This would be the bulk of the model file. I'm wondering if they use compression as well??

I would suggest a simple experiment to just see if mesh details can be moved into a test common format and moved between model systems before figuriing out the texture attachment references, etc.

Of course it would help if the game wrrtters just gave the info of the file systems involved.
 
I worte a simple C programme back in the early 1990's to read PIC image files in DOS at Uni as a class exercise. It was pretty simple. I'll have to dig it up and figure what I was thinking when I wrote it back then.

How many folks here understand Jackson Structures as these are a diagramatic tool for pulling apart programmes into easy modules. I've never needed to use a flow chart in yonks since using these.

I figure that whoever wrote Model Viewer and whoever wrote the Armarda 1 Model Viewer already has knowledge of the model file storage system of these two seperate model formats.

Perhaps trying to create a common format between these two model formats as an experiment might be interesting.

There is a lot of talented folks out there that visit this site.