About Gallery SF.net Project Bug tracker Downloads Forums Manual Wiki DevBlog News

Archive for the ‘Dataset’ Category

Tools of the Trade

Tuesday, January 18th, 2011

Recently I put a call out on sourceforge.net for help building the new toolsets for Vega Strike. I must say I did not expect to find so much interest, especially in such a tiny barely known project that lacked.. well, everything. So far I have at least 4 (yes FOUR) people who are either looking over the vegastrike data or actively working on new tools.

What are we looking at you ask? Well, if you haven’t seen it yet I have a demo of A tool over at the tools project http://sourceforge.net/projects/ppueditor Yes i know… the name of the link does not reflect its current status. I originally started the project as a means to edit the files for Privateer but later decided that the tools would be server the community as a whole.

Go download the demo (windows) and its update. Linux users, the current svn revision is bugged and wont compile. I am trying to correct this by finishing the autoupdate code. Qt is being tricky about its networking calls… Enjoy the tools and make sure to visit the forums and post your comments!

Dreaming of Planets

Friday, August 13th, 2010

I was playing around with gimp, the other day (photoshop for others), wondering about planets.

Browsing the net, I found tons of cool pictures.

Like this one from NASALike this one from nasa, showing the earth as it looks from the moon.

Tons of cool pictures around. It must have happened to everybody, you find one cool picture, and start googling around for more, as if it were the next fix.

So I kept on googling, and found the next:

Such gorgeous pictures made me start dreaming. What if VS looked like that?

Just imageine that. Approaching planet earth on your ship, gazing at views like these

screenshot88.jpg

Maybe fighting grazing the atmosphere

screenshot92.jpg

Perhaps loosing too…

screenshot96.jpg

Sigh…

Some day perhaps…

…on the horizon

screenshot98_r.jpg

Ok, I didn’t use gimp, at least not for anything other than converting those screenshots to jpg.

:D

klauss++

Vessels and Installations

Wednesday, October 29th, 2008

 

Since the last release in April, artists have been working on modeling, texturing and integrating new space crafts and installations into the Vega Strike game.

Bringing an asset such as a vessel up to the point where it is usable is a long and arduous task. It starts with the selection of an appropriate candidate from our recently reorganized 3D Models list. The artist must consider the model type, role, and specifically the faction to come up with an adequate concept proposal contemplating the architecture and texture of the model.


Early model concept

Once the concept is accepted, the modeling can commence. While small models can consist of a single mesh, larger or more complex models can be subdivided into several sub-meshes. In addition to the larger scale architecture, a good model will convey its dimensions by adding smaller features like doors, openings, pipes, ladders, cranes and other small scale features. This process is called greebling. After finishing the model, it needs to be unwrapped to provide the outline of the shapes for subsequent texturing, which is mostly done using a paint program like GIMP. Depending on the intended material in various model areas, the textures for color, specular, and glow are painted. Once the main model is finished, marker objects for docking ports, engine thruster exhausts, turrets, subunits, and blink lights must be positioned around the model. Additional meshes for shields, smaller levels of detail (LOD), and simplified collision meshes might be provided too, though it is not a must. After export of the meshes and markers, the unit is ready for integration into the game data.


Placement of thruster markers on the Archimedes model

The integration of a unit has for long been a very tedious and error prone process mastered only by few. With the advent of modding tools, in particular the Unit Converter, which will be discussed in a separate devblog, the integration promises to become merely a task of pointing the correct textures to corresponding meshes. After conversion of the meshes from Wavefront obj format to Vega Strike internal bfxm format, we need to provide a HUD image and tweak the multitude of unit stats, ranging from the unit scale factor to the item categories that a base offers for purchase.

My intention so far was to give you a short glance on the many tasks involved in getting a new unit into the game. Nevertheless, what you were probably hoping for, namely information on models added after the last release, is what I won’t let you wait longer for.


The Bell, a communication ship


An Andolian destroyer, the Kahan

In the space craft fleets of the major factions we have excellent contributions (the majority of which are from the shipyards of our talented modeler and texturer Fendorin where not mentioned otherwise, but also other artists noted besides the models):
* Archimedes
* Bell
* Ct1000, Ct2000, Ct3000 (by rivalin)
* Derivative (by Deus Siddis)
* Determinant (by Etheral walker and Nózmajner)
* Emu
* Jackal (by Oblivion)
* Kahan
* Knight
* Tridacna
* Xuanzong


Tridacna


Rlaan Xuanzong

We had also updates on already existing models in terms of improving the mesh and/or textures:
* Entourage
* H496
* Mk32
* Regret
* Vigilance


Vigilance wallpaper


Regret - Shmrn figther

Curiously, when starting to work on installations, I have come across one station, the Diplomatic Center (by Strangelet), that has been sitting in the data set probably for years already but never has been spawned. There are also three older contributions by Oblivion (who is now involved in Angels Fall First game development) that have been added:
* Uln Asteroid Refinery
* Uln Refinery
* Uln Commerce Center


Diplomatic Center


Uln Commerce Center

Fendorin was active constructing bases in Rlaan space, but not only. The new stations of this craftsmanship that a space faring traveler may encounter:
* Civilian Asteroid Shipyard
* Rlaan Commerce Center
* Rlaan Fighter Barracks
* Rlaan Medical
* Rlaan Mining Base
* Rlaan Star Fortress
* Shaper Bio-Adaptation Station


Rlaan Commerce Center


Rlaan Fighter Barracks


Civilian Asteroid Shipyard


Rlaan Star Fortress

Including new units into the game is not the only work that was done. We have upgraded most of the vessels HUD images to higher resolution and better quality and were careful to outfit the new additions with engine thruster exhausts, turrets, and blink lights.


Mechanist Built Mk32 Battle Cruiser with H496 shuttle flyby.

We will continue contributing (as we’ve still got some uncommitted models up the sleeves) and hope that you enjoy the work we have been putting into making the Vega Strike universe a richer experience.

Pyramid

Extensions Renaming

Thursday, June 12th, 2008

Recently, there were a lot of questions on why we are renaming extensions for image files and textures. The changes were started after the 0.5.0 release and can be found in SVN only at this point in time. They will be in released versions from 0.5.1 on.

In 0.5.0 we had png, jpg, and bmp and the extensions did not necessarily represent the codec used in the file. Having files with .bmp extensions that in fact were .jpg, or .png, was completely messy. Also, with 0.5.0 we have switched all in-game graphics (images and textures) to use one of the S3TC DDS compression algorithms (DXT1, DXT3, or DXT5. See info on compression in http://en.wikipedia.org/wiki/S3_Texture_Compression). This means that the exiting extensions became misleading and obsolete.

The S3TC (DDS) compression is currently the most widely used and has the best tradeoff between memory/bandwidth consumption and graphics quality for most of the cases as compared to other compression algorithms like Dithering, 3Dc, or FXT1 (see comparison in http://www.digit-life.com/articles/reviews3tcfxt1/) and is being supported by all GPU manufacturers and the two most prominent graphics APIs, DirectX and OpenGL. This still does not mean that it will remain that way in the next 2-5 years (for example see the specialized normal map compression algorithm in http://ieeexplore.ieee.org/iel5/4089190/4089191/04089271.pdf).

The above issues (compression and naming mess) are the two main reasons that have lead us to the conclusion that renaming graphics extensions is of advantage giving us at the same time clarity about the contents of the image or texture and preparing the ground for any future codec changes that might come on the way. With this changes we are bringing our support for texture compression up to state-of-the-art.

The renaming is well underway with only small portions of data still open up for conversion. The new extensions come in 2 flavors:

  • .texture contains, besides the base texture, mipmap levels and is used everywhere where objects are drawn at different distances, i.e. in space. The GPU will automatically switch the mipmap level according to the object’s distance from the viewer. There is no reason to draw 1024×1024 pixels when a ship is 15km away and only visible as one or two pixels on the screen. Textures can come with transparency (e.g. sun flares) or without (ship diffuse textures).
  • .image files are graphics without the mipmaps and are used for all graphics where the distance to camera does not change. Space backgrounds, cockpit gauges and HUD images are the places where we apply the image type in space. Mipmap-less images are also used for splash screens, cargo/weapons/upgrades, base and planet backgrounds, to name some of the used places. They equally can come in transparent or opaque flavors.

There is no association whatsoever with specific directories where the files reside. For example, under the animations folder we will find subdirectories with .image types (for comm animations or splash screens) and other subdirs with .texture types for example for explosions or blinking lights.

The idea was that .image and .texture aren’t misleading, there are no existing file formats with that extension. And, since it’s format-agnostic as well, it will also make things easier to maintain in the future since a change in format (say, make them png) needs no change to the resources referencing them (like sprite files, animation files, meshes, or system definition files). And this is the point that makes the rename really necessary, since especially mods have asked for support of higher-quality textures by replacing the dds textures with lossless png textures, or high-quality jpegs. If we said “let’s rename them to .dds”, then the mod would have to have a dds file that was a png. So the only real choice is the format-agnostic choice. Since, over time, the desired codec used for images has changed and will be changing with the available technology, we decided that a codec agnostic extension was the best course of action to stop the constant confusion that people have been experiencing when the filename’s extension doesn’t match the real codec used.

The renaming might be annoying for those who have to re-download all graphics again. Though we were very careful to use the svn move command for renaming, it appears that svn doesn’t want to behave correctly in all the cases and, instead of moving also the files in your working copy, makes a completely new download. But this one renaming and re-download is to stop any need to change the names ever again whenever we change the underlying data type and to stop user confusion over conflicting info. It should have been done long ago, but has always been put aside until today.

The recent folder structure was also changed on they was and is now as follows:

  • data holds the dds compressed images and textures
  • masters holds the source and project files used to create the art and master images with the correct codec-dependent extensions.
  • hqtextures holds the non-dds compressed high quality png or jpeg files (though with the same extension as in data).

This means that the data folder isn’t intended for artists at all. It’s only VS UTCS game data. You have the masters repository where things have proper extensions and are artist-friendly, but data needs not be so. This means that you shouldn’t be editing data images but always edit/generate master images and then export to data. hqtextures are optional if you want to see in-game high quality graphics. It will not be compressed on loading into the GPU, so beware, the memory consumption will increase. You have been warned.

With the renaming comes the question: how can I view the images and textures without resorting to a complete masters repository download? It is possible, however your viewer will be required to understand the dds format. For GIMP (Win/Posix) and IrfanView (Win) there are plug-ins available that can read dds files (see http://vegastrike.sourceforge.net/wiki/Links:Graphic_Applications#2D_Graphic_Converters for a list). Several viewers come with native dds support (e.g. KDE supports DDS hence also GwenView, KView, and Konqueror). If in trouble, try renaming the graphics to .dds or .png and see if your application can read it.

Actually, all software should rely on file magic mime typing to determine the codec type of the file (where such a distinction can be made) and not extensions. Extensions are for humans. In theory, no application worth using should give any problem about .image or .texture file loading if it has the appropriate decoder installed. Unfortunately, the reality can be different and a bit more annoying. In Windows, there are several ways of associating extensions with specific applications (e.g. Open With../Always use this program…), which should ease the desktop integration of the new extensions. In Linux you can do a similar operation (Open With…, select the application e.g. GwenView or KView, and check “Remember application association…”) and will be able to view the images directly from Konqueror. While there might be other ways under Linux which I haven’t yet explored, Mac remains black magic to me.

Hopefully this clarifies things up a bit.

Enjoy the release

Saturday, April 26th, 2008

Hi Folks! I just wanted to let everyone know how excited I am that we got this release out the door! First of all it should be fun to have a system that should work on all modern platforms with installers for 5 major platforms (Windows, Linux-32, Linux-64, Mac Intel, Mac PPC).  

Since pyramid just made a post about the artwork, I’d like to talk some about the code. This release should finally provide some polish to the new warp system, some interesting and improved gameplay and very scenic systems that are now populated with hundreds or even thousands of ships each.  To do this we needed to completely revamp the physics system with jacks idea of asynchronous physics simulation atoms.  We also needed to optimize the heck out of the game. Thanks to Safemode’s DDS code, we can load compressed textures directly onto the GPUs without decoding them from png first. And our talented artists just keep on contributing, from beautiful models to high resolution planets! What really needs doing now is for the artists to come together and start generating normal maps for our ships so they appear to have higher detail geometry. Take a look at the starting ship, the llama in game and notice the high resolution bump maps!

And most importantly of all, with Safemode’s contributions to the collision library we are legally allowed to distribute this game again after a brief period where it was discovered that the Crystal Space collision system was using GPL-incompatible code!  So we’re 100% free software again: congrats Vega Strike.   

This occasion also marks the 10 year anniversary of Vega Strike.  If you go back to the archives and find the first blog posts, you can see the first public release was in april of 1998.  With any luck, since this is 0.5.0, that means we’ll have 1.0.0 (the space sim to end all other spacesims) out in 2018 ;-)   

Speaking of game changing features, 0.5.0 marks a very nice place since it allows us to become more experimental in the subversion head.  This means more development focus on multiplayer, which we will allow users to test in spurts (right now public access to the MMO version is blocked…but that’s simply because the server has a few bugs that we didn’t want to delay the release for).  But multiplayer is coming–all of the feature-driven code is there and it’s mostly just bugfixing from here on out!  This means in the next few releases we should start to see more heavy multiplayer integration–and in this release you can setup your own deathmatch servers with the provided vegaserver executable! 

So as you can see the state of the Vega is strong. 

Graphics Developments

Wednesday, April 16th, 2008

To slightly sweeten the remaining time while (impatiently) awaiting the 0.5 release, here’s a short update on the recent graphics developments.

Support for mipmapless DDS textures for space backgrounds has been enabled in the recent version (thanks go to safemode), which will reduce the memory footprint used by your graphics card and further speed up system loading. Two missing backgrounds have been also added to the data set.

More planet textures have been improved over the last month. Now all 74 exo-planet textures are of high quality (though I think I will go back to the gas planets and remake them after 0.5). The remaining 46 textures are from solar system planets and bodies. Here, the previously existing 2 different data sets have been joined inheriting the best textures and more than half of the solar system bodies have got additional improved textures. While all solar system planets have high quality textures (2048×1024 resolution ), I wanted to keep the remaining bodies as close to the reality as possible. However, freely licensed high quality maps for moons and other significant bodies are not readily available, so the approach was to reduce the release quality resolution requirements to 1024×512. Still 11 maps remain with lower quality (512x), probably until our solar system has been better researched and photographed. Nevertheless, the phase of improving planet textures is considered closed for now, and I will focus on other future tasks.

Finally, new and better planet rings are now available in the data set. They are of reasonable quality so that you may still enjoy them when flying close by. Further, 20 of the upgrade images have been provided with better quality pictures. And last, on your HUD you will notice that 3 indicators - the weapons capacitor charge, the FTL and JUMP drives energy, and the fuel status - have now a text overlay, so you don’t need to remember the meaning of each one.

You may wait for the new release or check out the SVN version to start enjoying the improvements already.
I hope that you will like those changes.

Working down the laundry list

Thursday, July 12th, 2007

I’m a bit on the busy side, so forgive me for being excessively terse.

Jump/SPEC tweaks — Jumping while in SPEC no longer allowed. Shields should also drop on jump — haven’t implemented that yet. In general I’m going to attempt to (where reasonable, given timeframes) limit the interactions possible while in SPEC. I’ll need to test some ideas out against the tail mission in the example campaign, to make sure that doesn’t break.

HUD tweaks — All 8 armor faces now have their own graphical representation on the HUD.  Need to get around to adding new display for velocity reference object, and then add it to all the cockpit files. Likewise need to add long overdue change to velocity gauge to only display the velocity relative to the reference object (the V relative to the system just isn’t useful when using the set/unset velocity reference functions).

Basecomputer — Upgrades now have more colors… it’s still not quite what I wanted, with a clear correspondence between reason for non-purchasable status and color, because the categories that can be discerned are a bit broad, but it’s an improvement over what it was. I’ll make another pass and see if I can hijack the existing “can’t-buy” flag preprocessing behavior to a more useful end.  Changed the prohibited upgrades functionality to work on category tree roots rather than leaf nodes only (can prohibit/quantity-limit at arbitrary depth in tree) and then coupled that with adding explicit quantity limits for the categories with multiple items in units.csv. Will need to sit down soon and bite the bullet on trying to debug why certain upgrades appear damaged immediately upon purchase… my deep suspicion is that the PercentOperational function is flawed, perhaps inherently so - it has previously displayed some very odd behaviors that have required kludge workarounds.

A cascade of artwork

Wednesday, July 11th, 2007

I’ve been spending the past few days clearing out the blacklog of artwork in the production pipeline. I am now happy to report that I’ve added seven new models from Oblivion and Fendorin to the subversion repository with a few more still to come.

I’ll let the artwork speak for itself.

Oblivion's Vendetta Oblivion's Skate (Dodo replacement) with destroyable cargo subunit :)

Oblivion's SeaxBane (nee Daphne) Oblivion's SeaxBane (nee Daphne)

Fendorin's Diligence Fendorin's Tridacna

Fendorin's Pirate Asteroid Base Fendorin's Pirate Asteroid Base with glowmap by me ;)

Fendorin's Aeran Medical Base (and more?)

Data Set Ruminations

Wednesday, July 4th, 2007

Spent a bit of time primarily working on the data set itself, although there were a couple of negligible code changes I commited tonight.

Ammo levels are somewhat more sane now. I’ve split the ammunition category into some subcategories so that there can be some factional/basetype differentiation on quantity, pricing, and just plain old availabilty. I’ll be doing the same thing with some other categories too tomorrow, and likely introducing some more species-specific variants of some types of upgrades.

While testing, I realized that all of the Sartre variants were missing the damage map they referenced, so I dirtied up copies of the texture and named them appropriately. It’ll do for the moment, but I’m no Picasso, so someone will probably want to replace those at some point. Likewise in the missing category - there were some missing unit warnings among the newly defined weapon upgrades caused by some mismatched keys, so I tracked those down and fixed them. This would perhaps have been easier to find if there weren’t a slew of warnings concerning nonexistent .template files (which the VS data set doesn’t use), so I put in a check before the warning is printed to check a new config variable for whether .templates are being used. The deluge of (harmless) “missing” factional variant texture messages is far worse, but it looked like it would be a bit more invasive to make those statements conditional, as it is non-trivial to determine whether you really are missing a file, or there just is no factional variant art for that vessel (the latter being much more common) — and the level at which the statement is being printed doesn’t match the level at which such knowledge would be more readily available. So, I’ll let that be for the moment, but we _really_ need to clean up our stderr sometime soon.

Back in the land of dataset hackery, I went and changed the required volumes of some of the key upgrades. The reactors were the most heavily affected, and this because the reactor is in many ways the place with the most leverage: if you can’t fit a larger reactor, and have to take a smaller one, you may still have room for a more advanced shield module, but you probably won’t be able to sustain its recharge rate, etc. This is just a first go over, so I’m sure I’ll change it again, but we’ll see how the new sizes play out. Pricing for the basic vessels, ammo, and weaponry was also modified. I’m less confident about the absolute range those numbers have wandered into, but the relative is probably a bit better now than it was before.

There were some changes to keys and relevant categories that had to be mirrored in the python code. I don’t know that I’ve found them all yet, but I think the primary places of reference are fine (I may have missed some of the less used python modules — gives me something to do tomorrow while I’m not BBQing.)

Moved the player start position to a few hundred Km from starting planet rather than a few 100,000 Km. This causes an immediate redock on initially leaving the planet, but no further hassle. I have a pretty good idea what’s causing the re-dock, but I’m not sure how to fix it yet, so I’ll sleep on it.

Other assorted fiddlings/minor bug fixes:

Fixed AI turret key binding typo in vegastrike.config (config file change) (it’s amazing what one can find if one actually reads stdout.txt :-P )
Changing warp-stretch settings, attempting to only have length distortion at relativistic and greater (FTL) effective velocities (config file changes)
Expanded size of stars (and indirectly, planets) and increased spacing of objects therein (config file changes)
Fixed typo in reference to config variable in galaxy_gen.cpp relating to above

In any event, it’s naptime here -

-jackS

Weekend update

Sunday, July 1st, 2007

Revamped weapon set (first approximation of long planned overhaul).

Fixed broken feature relating to ammunition: for non-missile weapons, you now have to actually have a gun of the appropriate type before ammunition can be purchased.

Ammunition made extremely plentiful for testing purposes. Levels will be reduced tomorrow now that I remembered to make each ammo pack have multiple rounds :-/.

Keys changed in MPL/units.csv — new savegames reccommended for anyone pulling newest SVN.

Images of initial upgrades now appear properly.

Added workaround for bug where purchase of additional sensors would make the previous upgrade appear broken. Root cause likely remains, but should probably be ignored. Entire upgrade system will need to be reimplemented after next release anyway.

Began cleanup of ship variants available for sale. Separated noextension (equipped military) and .milspec (for sale, from military). Likewise separated .blank (explicitly referenced by game engine, assumed to be BLANK SLATE) and .stock (most basic ship variant for sale). This should eventually both ameliorate some of the problems historically caused when using milspecs and allow greater flexibility in the variants available (making .blanks immediately flyable at purchase has unfortunate consequences for all other variants. No longer having this restriction (leaving that task to the .stock variants) frees one to make more interesting variants.)

Noted that some upgrades are reported as upgrading columns for which they have no entries. Initial investigation showed the generated upgrade unit having non-default values for the reported fields. I will look into this further tomorrow.

Upgrade re-sizing and sanity checking of prices still pending. Will switch over to said tasks if above mentioned bughunt does not seem promising.