Hard Light Productions Forums
Modding, Mission Design, and Coding => The FRED Workshop => Topic started by: Razial on July 28, 2009, 03:58:35 pm
-
After much straining of my brain I finally finished my first planet with GIMP. It is ok but I would like to see what it looks like in FRED. I have saved it as .bmp .tga and .pcx as i'm not sure which can be used (if either)
Do I need to merge it into one of the existing mediavps perhaps? I have tried putting it in data/maps but that doesn't seem to work. Any suggestions would be greatly appreciated. :) *scratches head*
[attachment deleted by Tolwyn]
-
You'll probably need to alter a table so the game knows to look for the image.
-
Erm I can alter the tables easily enough, but how do I put the altered table back into the vp so it can be read?
-
You don't.
Look, go read the Wiki about .tbms, okay?
-
put it in your modfolder data-->effects.
Now, either check in the vp's for a planet name, Planet03 for instance and name it so, it should overwrite the one in the vp's.
The other way is to create a .tbm file and add it there, then put the tbm into modfolder-->data-->tables.
-
For reference, this is the table you want: http://www.hard-light.net/wiki/index.php/Stars.tbl
-
I think I modified the tables ok. The planet (JonPlanet1) is now in FRED but After making a mission and loading the game, the planet doesn't show up.
-
Make sure you're running a mod that contains your planet.
If you're using older build (you shouldn't) check if you have "use jpg/tga textures" selected in launcher.
-
I think I modified the tables ok. The planet (JonPlanet1) is now in FRED but After making a mission and loading the game, the planet doesn't show up.
Use the tga version.
If it still doesn't work, remove the modified table, and name the planet planet03, then try it again.
-
save always in .DDS (use DTX3).
you got your table alright with the name of the file?... if so check this:
you are probably runing FS2 with the "mediavps" as mod, in order to replace the mediavps files you need to place the planet file in the folder "data/effects" ON the directory of your selected mod, so you go to the folder mediavps on the root directory of FS2 and you create those two folders and place the planet.
You can see the planet on FRED2 because FRED is using the retail files as mod, but not your FS2 engine ^^
If you did correctly then when you go to play the mission the planet will load (asuming you did not use a incredibly huge file, which sometimes causes the game to crash, some other times it doesn't load, a file of 10MB is already too big...scale it down if so).
PD: about the planet, you won't need the background with the stars for the game, next time just save the planet on a transparent layer, it will make the planet look better (when you place the planet with that background it will cover the skybox on the back)
-
save always in .DDS (use DTX3).
I'm not sure how to save in .dds dude? I found one program for converting but it doesn't work properly. Do you have a program that can do this?
-
save always in .DDS (use DTX3).
I'm not sure how to save in .dds dude? I found one program for converting but it doesn't work properly. Do you have a program that can do this?
http://developer.amd.com/gpu/compressonator/Pages/default.aspx
This one.
-
gimp saves in DDS, not sure if you had to download a plugin for that.. just google "Gimp .DDS" and that should do it... anyways, when you save on the lower part of the window you'll see a "+" button, press it and a drop down list will apear showing the different file extentions to save.
-
I have a plugin for that, although I think it's supported natively now
-
Right got a planet or so working in FRED now and got the .dds plugin for GIMP :) I just saved one of my planets in GIMP format and the file is like 36mb compared with the 800kb jpeg and 1mb tga. You said over 10mb is too big for FS2 to process, does it format it somehow in game, or do i need to change another setting?
-
Erm. You know that the gimp format, with all its redundancies, layer information and general uncompressedness, isn't usable by the engine? dds shouldn't use much more space than the jpg image, really.
-
36MB... well my first planets where also that big, I even got a 60 MB planet (jupiter) working ingame, but after resizing pass x5 on FRED the game crashed or did not show the planet at all
Here's the deal with DDS (AFAIK):
When saving on .DDS always try to make the image a power of two like...
512 x 512
1024 x 1024
2048 x 2048
and so on, this way when GIMP saves on .DDS it also compacts it in a much more smaller file, this is the strong point of using .DDS files, I'm guessing that if you resize your actual picture to 1024x1024 you'll get the same file in the range of... 1MB / 3 MB max.
It's a good idea also to save with mipmaps generated.
EDIT: oh and I forgot, before saving merge all visible layer down! you don't need a multiple layer image loading in game... hell I'm not even sure if it will load properly if it's saved that way in FS engine.
-
36MB... well my first planets where also that big, I even got a 60 MB planet (jupiter) working ingame, but after resizing pass x5 on FRED the game crashed or did not show the planet at all
Here's the deal with DDS (AFAIK):
When saving on .DDS always try to make the image a power of two like...
512 x 512
1024 x 1024
2048 x 2048
and so on, this way when GIMP saves on .DDS it also compacts it in a much more smaller file, this is the strong point of using .DDS files, I'm guessing that if you resize your actual picture to 1024x1024 you'll get the same file in the range of... 1MB / 3 MB max.
It's a good idea also to save with mipmaps generated.
EDIT: oh and I forgot, before saving merge all visible layer down! you don't need a multiple layer image loading in game... hell I'm not even sure if it will load properly if it's saved that way in FS engine.
Thanks dude, I got the right file size now, but it is not seen in FRED. Are you sure FRED can recognise dds background images, as most of the planets and nebulas you use in FRED are bitmap i think. I have put my file (Mars2.dds) in the tables and copied the file (in dds format) into my mods data/effects and freesspace data/effects and freespace data/models folders just to be sure but it still isn't being recognised.
-
Thanks dude, I got the right file size now, but it is not seen in FRED. Are you sure FRED can recognise dds background images, as most of the planets and nebulas you use in FRED are bitmap i think. I have put my file (Mars2.dds) in the tables and copied the file (in dds format) into my mods data/effects and freesspace data/effects and freespace data/models folders just to be sure but it still isn't being recognised.
FRED2_Open does recognize DDS textures as far as I know. After all, I think it uses the same rendering engine as FS2, but in a mission builder environment.
The way I started getting my planets into FS2 to see how they looked was as follows: I made a mod that simply replaced one of the planets used in retail FS2 mission (usually Surrender, Belisarius!) and the file name was planeta.*
When I later learned about making a modular planet-str.tbm file, I started using that, but for getting the game to see the planet, making sure it's in a correct format without black border around it and without being all-round transparent, a replacement mod is the single most easiest and fastest way to do it. I still do that occasionally if I can't be bothered to make a table, since renaming an image file to planetA.dds is a lot faster than making a modular table that adds it to the game. Not a good solution for anything you release, but for WIP it works smashingly.
As far as formats go, you should use DDS, or possibly in work-in-progress phase TGA if you don't want to bother with DDS conversion. Important thing is that you work in lossless formats (PSD, XCF, TGA, bitmap) and only when you have it ready, try converting it into a DXT compressed DDS file. It will lose some of the quality, but usually so little that it's better to use a compressed rather than non-compressed DDS file, although the latter is an option for certain image types (usually stuff with a lot of smooth gradient transitions rather than sharp, abrupt changes).
Also, it's important to realize that DDS is not as much a format as it is a container that can hold several types of image formats. In addition to uncompressed DDS files (rarely used, but very useful in certain conditions where the DXT compression doesn't work favourably), FS2_Open can use DXT1, DXT3 and DXT5 compressed formats. DXT1 should be used when the image file does not need transparency or uses additive blending (ie. black is transparent). This kind of things would be the sun bitmaps, nebula bitmaps and most if not all diffuse textures (with the exception of those that have cockpit glass texture integrated into them).
DXT3 and DXT5 are compression formats that include alpha channel, and should be used whenever you need alpha blending for the image file. This means stuff like planets where you want the planet NOT to be transparent, but the edges and atmosphere should be so. You also need an alpha channel in shinemaps (assuming you want to control environmental reflectivity, which you usually do) and most definitely in normal maps, at least the way it's being dealt with now. The only difference between DXT3 and DXT5 compressions is the way they deal with the alpha channel; if I remember correctly, DXT3 alpha is better suited for more abrupt changes (like nameplates where the text is opaque and has quite sharp borders) and DXT5 alpha is better suited for things that aren't as clearly defined - like, maybe, an atmosphere that has more gradient shift from opaque to transparent.
DXT compression typically reduces the memory footprint of a texture to either 1/6th (DXT1) or 1/4th (DXT3, DXT5). It's important to notice that even if you can have much smaller file size with PCX or JPG, or even run-length encoded TGA files, the memory requirements for all of these are the same regardless of the file size.
This is because the graphics processing unit can not deal with PCX, JPG or TGA files directly and needs them converted into uncompressed bitmap format, which takes a fixed amount of memory depending on amount of channels and resolution. In other words, a PCX file with resolution of 512^2 takes the exact same amount of memory as a TGA file of same resolution (although if there's an alpha channel involved, TGA takes a third more of memory).
DDS, or Direct Draw Surface, is different because the GPU can use them directly from the hard disk drive with no need for any conversion. Therefore, video ram is significantly saved.
Another reason why you should be using DDS format is that it offers a way to include mipmaps in the texture, which (although increasing the file size) reduces the need for processing cycles used to create mipmaps in the fly, so to speak. So, even if you end up unable to use DXT compression, you should still use DDS format (u888 for RGB files, u8888 for RGBA files) because of the mip maps.
-
Thanks Herra dude!! :) I was wondering about which settings to choose when saving in .dds that has def cleared it up :) I think now I have got into a bit of a jumble as I have maybe 3 mods running from different folders, I also have multiples of files and tables in different sub-sections of my main FS2 directory just to make sure they files are recognised lol. Could you tell me where I need to have an altered table file (if at all) and where I need to have the new .dds planet files to which it refers?
I have been told so many different (not necessarily wrong) things from people I think I may have muddles quite a few of them up xD
-
Okay. There's only one right way to do this. Put everything you've done into ONE folder, i.e. merge all the different data folders you have created into one, put it into your own modfolder, and created a mod.ini which references the mediavps:
[multimod]
secondaryline = mediavps;
If you want to FRED using that folder, create a shortcut to FRED, and add "-mod <your mod's name goes here>,mediavps" in the target field.
Also, take a look at this wiki page (http://www.hard-light.net/wiki/index.php/FS2_Data_Structure). It tells you exactly how the data\ folder structure looks like, and what files go where.
-
Okay. There's only one right way to do this. Put everything you've done into ONE folder, i.e. merge all the different data folders you have created into one, put it into your own modfolder, and created a mod.ini which references the mediavps:
[multimod]
secondaryline = mediavps;
If you want to FRED using that folder, create a shortcut to FRED, and add "-mod <your mod's name goes here>,mediavps" in the target field.
Also, take a look at this wiki page (http://www.hard-light.net/wiki/index.php/FS2_Data_Structure). It tells you exactly how the data\ folder structure looks like, and what files go where.
mod.ini files are recommendable for a finished, distributed mod, but they have their pitfalls and personally I simply use the manual -mod Mod1,Mod2,Mod3,...,ModN command line.
I agree that you should keep your creations in as few places as you can. I also strongly suggest you abstain from putting anything at all into the following directories:
..\FreeSpace2\data\*\
..\FreeSpace2\mediavps\data\*\
The reason for keeping things out from root data directory is that the game ALWAYS reads that directory. Putting stuff there will eventually make you a victim of a rogue table or something similar and then you and everyone trying to troubleshoot will be scratching their heads when you can easily avoid the problem by never putting anything there at all.
Same is true for the mediavps\data\ directory; you can do it, surely, but it's much easier to troubleshoot MediaVP issues when the data directory there is clean. You can do it, just don't expect support and warm fuzzy feelings from FSUpgrade team. :p
For these and other reasons, you should create a mod directory for your stuff, ie.
..\FreeSpace2\RazialMod\data\
and put appropriate sub-directories in there, ie. models go into \RazialMod\data\models, maps go into \RazialMod\data\maps, effects into \RazialMod\data\effects, tables into \RazialMod\data\tables etc.
Then, either put in a mod.ini file that activates mediavps when RazialMod is activated, OR (as my personal preference is), locate the Custom command line in the Launcher's Features tab, and type in
-mod RazialMod,mediavps
which does absolutely the same as the mod.ini file with the exception that you immediately see every directory that you are telling the game to read.
Personally, I'd like to add that I often make a specific mod directory for specific stuff. As a result my -mod command line is sometimes a rather long string of directories, but I haven't noticed any adverse effects from this.
An important thing to realize with the file structure is that VP files should only be a distribution media, as in a container for your mod directory. The VP file has the exact same internal structure as any mod directory; it has a data directory and appropriate sub-directories.
Also, this thread could be moved (or split) to FreeSpace modding, as most of this stuff has little to do with FREDding (as in, mission building) and more with general modding. But I'll leave that for the FREDding forum mods to decide. :)
-
an easy way to do the first steps (the way I did it.. :P) to see planets in the background would be...
grab the stars.tbl from the retail VP file, uncompress it and edit it with a notepad.
INSTEAD of replacing already used entries, put a new planet, just copy one of the lines and put your custom named planets... something general like: MYPLANET or CUSTOMPLANET, then you save your planets as MYPLANET.DDS or CUSTOMPLANET.DDS and then you place it in the mod folder (remember! you have to select the mod in FRED2 and in the launcher so the planet is rendered in game and in FRED2) along with the stars.tbl and there you got it... an easy way to test planets, you just need to replace the MYPLANET or CUSTOMPLANET every time you need to see it ingame or in fred, if you are making a lot of planets.
Not enterely correct way, but it works and keeps your mod retail-compatible
-
Quick note: if you're using dds, you are way past the point of retail compatibility. Besides, why would you do it the WRONG way, when there is a RIGHT way available?
-
Quick note: if you're using dds, you are way past the point of retail compatibility. Besides, why would you do it the WRONG way, when there is a RIGHT way available?
It keeps retail compatibility because you are not messing with the retail entries, you are just adding a new one to the old table, I never said anything about changing the old mediavp planets for .dds versions ^^
-
Hmm these steps all seem to make sense but I still don't seem to be able to get FRED to recognise my new file. Oddly the other two planets (pictured) are recognised and can be seen in game (and are in the new mod directory as tga bmp dds and jpg) but the new one (pictured in directory) 'Mars2.***' isn't. I'm not sure what needs to be altered,removed or added.
I am following the simple steps but for some reason I am making it much more complicated than you have clearly illustrated xD Sorry to keep nagging, once this is sorted then hopefully it will make my nagging much less intense lol :D
[attachment deleted by Tolwyn]
-
sorry to ask this again but.. did you selected that folder as your mod in FRED2 right?
-
Yeah, that would be my question as well. Run a debug FRED, then post the fs2_open.log.
-
Yeah, that would be my question as well. Run a debug FRED, then post the fs2_open.log.
...or maybe fred2_open.log? :nervous:
Can't remember if FRED makes it's own debug log, as I don't use it all that much.
-
No, FRED creates an FS2_open.log as well.
-
Erm, I dunno how to do the debug thingy, I have never tried tbh. And by select mod, if you mean click 'select mod' in the launcher, and choose the folder that contains the modded data (as well as adding the folder to the target), then yes I have done that.
-
But to select a mod in FRED you need to do the "Create shortcut, add -mod commandline argument in the target field" dance. And you should have a debug FRED (called fred2_open_3_6_10d.exe) in your FS2 dir.
-
that's why you are not seying your planet, you are using the retail files on FRED
To set a mod , create a shortcut to fred, then hit properties, then in the "target" box put behind the path that's alredy there : " -mod nameofyourmodfolder"
this way you are telling fred to use nameofyourmodfolder as mod source, you can also add diferent mods in the same command line IIRC, but I would not recomend it.
I got it this way: "C:\Games\FreeSpace2\FRED2_OPEN.exe -mod AG,mediavps" just as an example (might be wrong though).