Hard Light Productions Forums
Modding, Mission Design, and Coding => The Modding Workshop => Modding Tutorials => Topic started by: Spoon on March 22, 2009, 10:34:51 am
-
Heya, an other question.
After several attempts at making a texture myself (all failed horribly) I just yoinked something off the internet and slapped it on my model with decent results. Now i'm working in 3ds max 6 and pretty much applied the same texture as a bumpmap as well as the diffuse color.
(Top = result in pcs2, bottom = render in 3dsmax)
(http://xs537.xs.to/xs537/09120/k531.jpg)
When I export it like that though, PCS2 will only show the diffuse.
So how does one get a bump mapped model in freespace2?
-
pcs2 doesn't support bump mapping.
-
Aright, then how are all those HTL ships looking so nice and bumpy? Normal maps? (I dont t think 3dsmax 6 supports that though...)
Or was some other program used to import those models into freespace?
-
well you just have to use the proper naming conventions for the engine texturename-normal.whatever or texturename-height.whatever. pcs2 simply does not yet have the rendering capabilities of the fs engine.
-
Could you perhaps describe that in a bit more detail...?
I have a texture, I have a normal map made of that texture (nvidia plugin in photoshop). And now i'm missing the steps to get it working in fs. I've already spend hours looking at wiki entries telling me that stuff is possible (but not on how to actually do it) and searched the forums over and over.
-
This is a good start. It's where I started when I first got here. :)
http://www.hard-light.net/forums/index.php/topic,43189.0.html
Plus my thread when I did the Ezechiel:
http://www.hard-light.net/forums/index.php/topic,56741.0.html
-
I wonder why those threads never showed up in any of my searches of this forum... stuff like that should be stickied!
Thanks Jadehawk that certainly is useful stuff! I'm still in the dark on the normal/bump mapping thing though
-
Aright, then how are all those HTL ships looking so nice and bumpy? Normal maps? (I dont t think 3dsmax 6 supports that though...)
Or was some other program used to import those models into freespace?
In the mainhall, press F3 for the lab viewer
Normal map info http://www.hard-light.net/forums/index.php/topic,55854.0.html (http://www.hard-light.net/forums/index.php/topic,55854.0.html)
-
The first link IS stickied :nod:
My thread is like 12 to 15 pages back and was able to find it by typing in Ezechiel in the search function. :D
The first thread link gives you a run down on how to make normals.
but in a very basic way to make normals, you need a Neutral Gray background with Black and White details. Black will show up as recessed details and White will show up as raised details. Once you have something like that ready, save it as a .tga file. Get a program such as Crazybump, open the saved .tga file and let the program run. Once you see the normal in a viewer, you can adjust the image to show the relief as you want it. Once satisfied, save it as a normal file. Then run a nvDXT program to create the final normal FreeSpace2 can use. Save it and rename it "yourfilename"-normal.dds without the "".
Finally, make sure your video card can support normals and your Freespace2 program has the latest mediavps located on this site to use the normals.
-
The first link IS stickied :nod:
Buh.. eh... gah
HOW COME I MISSED THAT ALL THIS TIME? :hopping:
Ugh, at times I curse my own stupidity/blindness.
My thread is like 12 to 15 pages back and was able to find it by typing in Ezechiel in the search function. :D
The first thread link gives you a run down on how to make normals.
but in a very basic way to make normals, you need a Neutral Gray background with Black and White details. Black will show up as recessed details and White will show up as raised details. Once you have something like that ready, save it as a .tga file. Get a program such as Crazybump, open the saved .tga file and let the program run. Once you see the normal in a viewer, you can adjust the image to show the relief as you want it. Once satisfied, save it as a normal file. Then run a nvDXT program to create the final normal FreeSpace2 can use. Save it and rename it "yourfilename"-normal.dds without the "".
Finally, make sure your video card can support normals and your Freespace2 program has the latest mediavps located on this site to use the normals.
Alright well, I can't exactly blame myself for not searching with 'Ezechiel ' :lol:
Thanks for the info though! Same for you Water! I think i'm starting to understand how it's done now.
It's a bit troublesome that a lot of this info has to be gathered from several different threads&wiki articles and internet tutorials. It's a big puzzle for someone new to this stuff.
-
Forgive me for the double post.
(http://xs537.xs.to/xs537/09120/kk849.jpg)
Hurrah, some kind of result! I'm now just doing a lot of trail and error on several settings though. Saving it in photoshop as dxt5 seems to get the best result so far. But there are a lot of save options that don't really mean anything to me. Whereas im seeing a lot of recommendations for dxt5nm but that just gives me a wierd effect.
-
dxt5nm is what you need. The resulting map will look a weird greenish colour.
If the photoshop filter can't do dxt5nm then save as tga. Then convert the purple normal map to dxt5nm using either Nvidia or AMD normal map tools. (nvdxt or Compressonator)
-
Well color me confused (again)
I'm using the nvidia .dds&normal map plugin. But all my normal maps either look blueish/purple. And if I save them as a dxt5nm .dds and open them again they are grey. I never get a greenish version of anything.
-
If you used the right mode, it should look sort of like the ones in the mediavps, right?
-
Well color me confused (again)
I'm using the nvidia .dds&normal map plugin. But all my normal maps either look blueish/purple. And if I save them as a dxt5nm .dds and open them again they are grey. I never get a greenish version of anything.
All mine are Gray, so your good to go. :yes:
-
The ones in the mediavp's are not strictly saved with the DXT5_NM option, Just DXT5. And they only have data in the Green and Alpha Channels, hence the color. DXT5_NM populates Red and Blue with un-needed data and I think does nothing in the alpha channel.
Take the file saved as DXT5_NM. Select the Red Channel. Select All and Copy. Create Alpha Channel. Paste. Now turn Red and Blue solid black. Save as DXT5 (or u8888 if you are still making adjustments).
c_bump generation via the shaders only evaluates on the Green and Alpha channels, hence this method.
You can still get results just using a DXT5_NM, but we in the FSU have found the above process generates better results.
-
The ones in the mediavp's are not strictly saved with the DXT5_NM option, Just DXT5. And they only have data in the Green and Alpha Channels, hence the color. DXT5_NM populates Red and Blue with un-needed data and I think does nothing in the alpha channel.
Take the file saved as DXT5_NM. Select the Red Channel. Select All and Copy. Create Alpha Channel. Paste. Now turn Red and Blue solid black. Save as DXT5 (or u8888 if you are still making adjustments).
c_bump generation via the shaders only evaluates on the Green and Alpha channels, hence this method.
You can still get results just using a DXT5_NM, but we in the FSU have found the above process generates better results.
Umm.. you are getting the format completely mixed up...
Dxt5nm is the format used. Green + Alpha. Green is green - Red is in Alpha and blue is derived from those two channels.
The grey ones have extra un needed data in the red and blue channels. Aparrently the extra red and blue can cause extra artifacts in compressed normal maps.
@Spoon If they are saved as DXT5nm and they are grey don't worry about it. nm stands as you guessed for normal map, but the channels get switched around and only two are used. DXT5 won't do the job, it has to be DXT5nm.
-
Thanks for the replies guys! I finally got it figured out now. Though one thing I had to discover myself the hard way, to get any result 'convert to tangent space normal map' should be checked off.
The way i'm doing it now: 1. Make height map based off diffuse texture.
2. Throw heightmap into crazybump (and crazy it is, telling me i'm but a puny human), though I guess this phase could also be done with the nvidia plugin for photoshop.
3. Switch some sliders around (intensity should be kept pretty low)
4. Copy normals onto clipboard, paste it in a photoshop layer
5. save as DXT5_NM .dds (xxxxx-normal.dds)
6. throw file in maps folder
7. ???
8. profit.
(http://xs137.xs.to/xs137/09132/sothisishowitgoes194.jpg)
What photoshop looks like.
(http://xs137.xs.to/xs137/09132/there_be_normal_mapping683.jpg)
lo and behold, the illusion of raised surfaces.
(Disclaimer, yes it looks like sh!t. No I don't claim I put any effort into this to make it look good. Yes this is just the result of testing :p )
-
Umm.. you are getting the format completely mixed up...
Dxt5nm is the format used. Green + Alpha. Green is green - Red is in Alpha and blue is derived from those two channels.
The grey ones have extra un needed data in the red and blue channels. Aparrently the extra red and blue can cause extra artifacts in compressed normal maps.
@Spoon If they are saved as DXT5nm and they are grey don't worry about it. nm stands as you guessed for normal map, but the channels get switched around and only two are used. DXT5 won't do the job, it has to be DXT5nm.
I think you just reiterated what I just said. But they do not need to be saved specifically as DXT5_NM if the previously mentioned steps are taken.
Green channel data and Alpha channel data are used. We both have that. Red and Blue are irrelevant, we both have that.
So long as both cases are true, it does not need to be saved as NM, _for the purposes of use within the Freespace Open engine_.
As can be exampled by the existence of the normal maps in the mediavp's.
The Advanced VP contains normal maps that are actually saved in the u8888 DDS format to reduce AA compression artifacts along angled lines.
DXT5 and DXT5_NM contain the same compression scheme. Incidentally, as long as the channel management is done, DX1 (with alpha) can be used for a normal map.
Why in the name of Kobol you would want to is beyond me.
It may be called _NM because it does the conversion for you (sometimes well, some times not), but that does not make it the only viable option for creating a $ship$-normal.dds.
Shaders can use different techniques to render tangent-space normal maps, but the normal map directions are usually consistent within a game. Usually the red channel of a tangent-space normal map stores the X axis (pointing the normals predominantly leftwards or rightwards), the green channel stores the Y axis (pointing the normals predominantly upwards or downwards), and the blue channel stores the Z axis (pointing the normals outwards away from the surface).
If you see lighting coming from the wrong angle when you're looking at your normal-mapped model, and the model is using tangent-space normal maps, the normal map shader might be expecting the red or green channel (or both) to point in the opposite direction. To fix this either change the shader, or simply invert the appropriate color channels in an image editor, so that the black pixels become white and the white pixels become black.
Some shaders expect the color channels to be swapped or re-arranged to work with a particular compression format. For example the DXT5_nm format usually expects the X axis to be in the alpha channel, the Y axis to be in the green channel, and the red and blue channels to be empty.
Our shaders are written to only utilize the data in Green and Alpha. It may change at some point for proper tangent space normal mapping, and may even prove a benefit with the -height option, but that will be a bit before that happens. I think getting us a multi-pass capability in the rendering system for dynamic lighting (which can lead to a slew of other things) will make the option of reading the blue channel in the future more viable or simplifying the normal map to reading an RGB with the Alpha serving an entirely different purpose.
On an unrelated note: Layer support will be coming to DDS soon.
-
I think you just reiterated what I just said. But they do not need to be saved specifically as DXT5_NM if the previously mentioned steps are taken.
It sounds like our starting points are in different places. Maybe just different software. When I use the compressionator it spits out a green texture (DXT5 xGxR) using just green and alpha.
Sounds like you end up with blue+red also using dxt5nm.
For someone new to this, dxt5nm has a better chance of success than channel swaping ;)
@Spoon
Sometimes a small amount of guassian blur can give a smooth bump using a lower intensity.
-
Actually, I don't use DTX5_NM at all, I manually channel swap after conversion to a Normal map via the nVidia Photoshop Texture Tools.
-
I think you just reiterated what I just said. But they do not need to be saved specifically as DXT5_NM if the previously mentioned steps are taken.
It sounds like our starting points are in different places. Maybe just different software. When I use the compressionator it spits out a green texture (DXT5 xGxR) using just green and alpha.
Sounds like you end up with blue+red also using dxt5nm.
For someone new to this, dxt5nm has a better chance of success than channel swaping ;)
It's preferable that people know what they're doing from the beginning, even if they use tools such as selecting dxt5nm as the format... If they just blindly assume they HAVE to select the dxt5nm format as if it were the only thing that worked, they can easily end up in a situation where they save an already functional normal map again into dxt5nm format and, well, since it moves the red channel to alpha and populates red and blue with green channel content, they end up with the same information on all channels as follows:
RGBA -> GGGR -> GGGG
We've had this happen a few times in the past and almost invariably explaining how the system works with the channel information clears up the confusion.
Incidentally at one point it was possible to use TGA files as normal maps, as long as you had the red channel copied to the Alpha channel. I haven't tried this in a while though...
Regarding "green" and "gray" normal maps, the functionality is the same. However, there may or may not be some difference in how well the files compress, which depends largely on the compression utilities used. Using layman's logic it would make sense that loading unnecessary information to Red and Blue channels might affect the compression quality as opposed to full black channels which is just a bunch of zeroes in the file. It doesn't really affect filesizes, but it may have some effect on how the DDS compression algorithms manage to compress the file and how much or how little artefacts are generated in the file. Of course, uncompressed u8888 files aren't affected by this (their filesize is defined only by resolution, amount of channels and bits per channel value), but since we've had good experiences with the green variety of normal maps, we use them for the sake of consistency in the MediaVP's.
Sometimes a small amount of guassian blur can give a smooth bump using a lower intensity.
Experimenting is probably the best way of learning how different gradients work out with different normalmap filters. As a basic rule, sharp change in contrast (from black to white over one pixel change) will result in maximal angle on the normal map. A wider linear gradient will show up as wider linear slope on the normal map. Blurred gradients tend to produce rounded (bell or sine curve) normal map profile.
Also, 4 sample normalmap filter tends to create sharpest transitions, while 3x3, 5x5, 7x7 and 9x9 tend to produce more "rounded" or less detailed normal maps. My experience is that 4 sample and 3x3 work best for small, sharp details, while the 5x5, 7x7 and 9x9 will give better quality of the slope sampling at the expense of resolution. However, if you make the normal map on higher than final resolution, you can use the higher sample filters and the detail will still be preserved adequately...
I would upload sample images but my internet doesn't want to upload files (large packages won't upload, specifically). Perhaps later...
NB: I'm not telling this to you Water, I think you have a pretty good idea of what does what with normalmaps...
/me takes a look at the Valkyrie
...so... yeah. The tips and tricks section of this post is aimed for Spoon et al. :p
EDIT:
Here's a few samples of what does what...
Base elevation map:
(http://i44.tinypic.com/2m6vpdx.gif)
Here's a few samples about what different things actually do. Hard transitions from black to gray to white, as well as black to white directly; Gaussian 5 pixel blur on the right side; Radial gradient from white to black (linear from center to edge), and 30 pixel gaussian blurred version on the right side of it.
Basically the unblurred radial gradient shows up as a sharp straight-edged cone, whereas blurred one shows up like a rounded missile cover or something like that.
4 sample normalmap:
(http://i40.tinypic.com/2wdnf5w.png)
Worth noticing - change from white to black is equal to change from white to gray or gray to black. 4 sample filter doesn't really bother to take the brightness of the areas into account in this kind of cases. Also, when you zoom into the gradient stuff - especially the radial gradients - you'll notice a lot of artefacting, dithering and stuff like that, which will (if left alone) make the normal map rather fugly in the game itself. Resizing the map to half the size usually tends to smooth out artefacts like that (which is one of the reasons I usually make normalmaps at higher resolution than the final map will be...).
3x3 filtered normalmap:
(http://i42.tinypic.com/10oqkud.png)
Smoother on the gradients but slightly thicker on the sharp edges.
5x5 normalmap
(http://i40.tinypic.com/33d9zma.png)
Smoother still, thicker still. Same trend continues when the number of samples increases.
7x7 normalmap
(http://i40.tinypic.com/2vci8g4.png)
Same old, same old...
9x9 normalmap
(http://i41.tinypic.com/2ij4v2f.png)
And this is where GIMP's normal map plugin ends it's offerings pretty much.
In general, blurring tends to lead to "smoothed out" lines and leaving hard contrast changes on the height map usually works better at least for me (unless I actually want smoothed, rounded normal map details... like pipes or dents).
-
Using those methods allows you get parts the way you want. One normal map for deep recesses and another for lower intensity bumps and lines. Then merge them together. xNormal allows you to do this and I'd guess Crazybump would as well. There are three or so ways to do it in photoshop, some better than others.
-
At the risk of sounding like a broken record: Thanks a lot!
Your post answered my questions before I even knew I was going to ask them :lol:
Once i'm back from my 5 day trip to Sweden i'm going to put all this information to use and hopefully manage to produce a decent looking ship with pretty normal maps. :nod:
On a unrelated note, i've been using your (Herra Tohtori) lighting settings for a while now (which I really like the look of in game).
-
Using those methods allows you get parts the way you want. One normal map for deep recesses and another for lower intensity bumps and lines. Then merge them together. xNormal allows you to do this and I'd guess Crazybump would as well. There are three or so ways to do it in photoshop, some better than others.
I just stack the layers on top of each other and make #8080ff transparent on the top layer(s)...
Oh, and by the way. One quirk of the shader system is that the maximum acceptable range of tilt (delta-normal) per axis is apparently not 0-255 per channel (or #00-#ff in hex values), but instead 1-254. Extreme values on red or green channels end up producing black flecks of doom when the normal map is rendered (I suspect it has something to do with division by zero, or tangent of 90 degrees or something like that). Whatever the cause, you need to make sure that when you have the normal map in purple form, check the pixel colour values; if the values show either #ff or #00 for red or blue channels, you need to reduce the contrast a bit to fit the colours within the range that the shaders render correctly.
A simple act of reducing contrast by five or even three or two units does this rather handily. When this is done, re-check that the "level" colour is still at #8080ff. If it's something like #7979ff or #8181ff, it hardly matters - it's close enough to flat to not make any difference, but if it's remarkably lighter or darker it can cause strange things when flat surfaces appear tilted...
If you want to be perfectionist, probe the flat region's colour (let's say it says #7474ee), then add a #8080ff colour layer below the normal map, and make the probed colour of the normal map's flat range transparent, and the correct background colour will be returned. Merge and save, do the channel magic (or save as dxt5nm) and you're done.
-
I have a little request.. can somebody send me simple .pof file which use normal map :)
thanks :)
-
Uh......wat?
Any pof will use a normal map. The normal map is not attached into the pof, but based on the texture name in the format of $pofdefinedname$-normal.dds.
The engine processes it because of the $pofdefinedname$ part of the file name.
Basically, whatever the basic texture name inside the model is, all of it's extension graphics will load so long as the the requisite -shine, -glow, -normal parts are present.
Example: Myrmidon model is Fighter2T-05. The basic LOD0 texture name specified in the POF matches the model name (though it does not always have to). So, all textures related to the Myrmidon have to be named Fighter2T-05-$type%.dds.
-
Zacam, that explanation confuses me and I know what you're saying. :lol: Nob's don't now 'bout $pofdefinedname$ and %type% and other stuff like that... that's what always confuses the hell out of me in Linux man pages too, deciphering the command line options with all the brackets and additional stuff can be a pain in the arse if you don't know how to read the notation.
This is as simple as I can say it:
If a model uses a texture called texturename, you can make it use shinemap, glowmap, normalmap and height map by adding an identifier to the filename of the texture, not the model itself.
Here's a complete list of how a full set of maps for a single model would look like:
model.pof uses a single texture, aptly named "texture". It will look for files named "texture" that have a suitable extension (DDS or TGA, basically). You should always use DDS files for textures (preferably compressed but uncompressed works just as well, it just uses 4-6 times more memory), so for the sake of simplicity I'm going to use that extension in this example. In testing phase you might want to use TGA files, and that works out just the same, since the texture name stored in the model doesn't even have any reference to extension.
Basic diffuse texture: texture.dds
Shinemap: texture-shine.dds
Glowmap: texture-glow.dds
Normalmap: texture-normal.dds
Heightmap*: texture-height.dds
* Also known as parallax map. Anyway I have to point out that height map is virtually useless for ships due to various problems in how it interacts (or doesn't interact) with the normal maps, so as a basic guideline... don't use this.
-
Hmm I don't know that in pcs I should load only one diffuse texture but I read Your instructions and made this steps:
1. In pcs2 I load model and one diffuse texture alfa.tga I saved this as alfa.pof
2. I copied alfa.pof to models/
3. alfa.tga and alfa-normal.tga to maps/
4. change ship.tbl
5. run game and I have only ship with diffuse texture.. btw. in lab viewer I don't have option "no normals"
I'm modeler so in this kind of problems I'm total noob :p
-
Hmm I don't know that in pcs I should load only one diffuse texture but I read Your instructions and made this steps:
1. In pcs2 I load model and one diffuse texture alfa.tga I saved this as alfa.pof
2. I copied alfa.pof to models/
3. alfa.tga and alfa-normal.tga to maps/
4. change ship.tbl
5. run game and I have only ship with diffuse texture.. btw. in lab viewer I don't have option "no normals"
I'm modeler so in this kind of problems I'm total noob :p
For the normal maps to work, three conditions must be met:
1. You need a graphics processing unit capable of using them. Specifically, you need a Shader Model 3 compatible card and drivers. If some extensions are missing, the game reverts to fixed render pipeline, which results in normal maps not being available. Post your graphics card and drivers if problems persist.
2. You need the actual shader files for the game to use. If these are not present. then the game reverts to fixed render pipeline again. A version of these are found in the 3.6.10 MediaVP's, so if you have them activated, this shouldn't be the problem.
3. You need to enable normal maps on Launcher. Of course for this you need a build that supports them but I doubt that's the problem if you use a 3.6.10 build...
If you still have problems, first thing like I said post your GPU and driver configuration, and run a debug build, then post ..\FreeSpace2\data\fs2_open.log here (in code tags or as a link to pastebin.com) so we can see what's going on.
Also, with TGA file you need to make sure that the channels are correctly swapped (red copied to alpha), but otherwise it should work.
-
I think that the first point is no problem cause I have GeForce Go 7150m and on Nvidia website was written that it supports Shader model 3. I have 3.6.9 build and in luncher I have options like enable glow-map and shine-map but I don't have option enable normal-map. I think that the problem may occure in point 2 cause I have wing commender relase and I'm not sure that I have updated shader files so please tell me names of this shader files and location where I should copy them ;)
-
I think that the first point is no problem cause I have GeForce Go 7150m and on Nvidia website was written that it supports Shader model 3. I have 3.6.9 build and in luncher I have options like enable glow-map and shine-map but I don't have option enable normal-map. I think that the problem may occure in point 2 cause I have wing commender relase and I'm not sure that I have updated shader files so please tell me names of this shader files and location where I should copy them ;)
Yeah, GeForce 7 series card should be good to go.
Version 3.6.9 is at least a hundred years old and does not have GLSL (shader) support and therefore no normal map.
Just for grabbing the shaders, I would at the moment recommend this version (http://www.mediafire.com/download.php?5n7bnd5y9jt) which is a bit newer than the ones in the MediaVP's and has some issues fixed (it doesn't really look that much different from the mediaVP's but it has small things like normal maps affecting environmental reflections and not just speculars). I recommend installing the shaders in their own mod directory so you can activate and deactivate them with -mod command line tag as desired.
Then get the 3.6.10 RC1 (http://www.hard-light.net/forums/index.php/topic,61891.0.html) build and Launcher 5.5d (http://fs2source.warpcore.org/exes/Launcher55d.rar). Wing Commander Saga Demo should work with 3.6.10 RC1... Just be sure to activate the Wing Commander features on the Gameplay options from Launcher.
-
I install everything as You say and now in lab view I have option "no normals" and after installation of this new shaders I have in game something like normal-map on my model but it was created by shader and base on diffuse texture so my normal map isn't loaded..
I upload You this test box with two textures..
http://www.sendspace.com/file/yu4ujg (http://www.sendspace.com/file/yu4ujg)
If You have some time please try to check it in your FS engine and please let me know what is wrong..
-
Okay, first of all I hope you aren't trying to use JPG file here and it's only used for transfer as a sample because of small size. If you try to use JPG as normal map it won't work, and even if it worked it uses the same amount of memory as TGA or uncompressed DDS file and has lower quality, so it's a lose-lose situation. Even using it in archived form is questionable since it already has compression in-built and therefore does not usually compress very much when it's archived...
As a rule of thumb it's usually better to use lossless formats at the developement phase (TGA or PNG come to mind first and foremost), although it matters very little in this case.
But to get into business: For the normal map to work, you need to save it in a format that FS2 can understand. JPG file has no alpha channel. Normal map system reads information from green channel and alpha channel. If you try to use a JPG file as a normal map, no alpha channel is found, therefore it will not work.
Also, a normal map that looks purple like that will not work, because the channels that hold the relevant normals information are not in correct order. Specifically, you have a full white alpha channel and the actual information is in red and green channels. What you need to do is to manipulate the file so that the red channel information is copied to alpha channel. What you leave in red and blue channels is up to you, but common practice is to either fill them with black (which is what I do) or copy the green channel information into them. The first method results in greenish transparent normal maps, while the second results in gray transparent normalmaps. Functionally, they don't really have any difference when you see them in the game.
Also, when you select the DXT5nm saving option (where nm means "normalmap"), it automatically does this for you and results in a valid, DXT5 compressed normal map. This is a handy way to get results of some kind into the game. But if you require higher quality, you will need to do the channel management manually. Additionally, it is good to know what exactly the program does and it's even better if you can, if needed, manually mimick the results, which is why I am posting the following image which hopefully clears the channel management issue a bit:
(http://users.tkk.fi/~lmiettun/Kuvat/FS2_Open/channelmanagement-guide_v2.png)
If you choose to manually manipulate the channels into correct configuration, you need to then save it to either TGA or DDS format (DDS with either plain DXT5 or u8888 [u=uncompressed]), but do not use DXT5nm, since it would just try to move the channels around for the second time and it would fail badly. :p
EDIT: I'm going to edit the image in a bit because of clarity reasons.
EDIT2: Edited.
-
Thank You very much Herra Tohtori ;) the reason is bad format.. jpg instead of tga. Thanks for all your explanation it was very usefull :D please tell me can I take from those shadersvp only files which are responsible for normal-map shadering cause when I'm using all those shader files I have only about 20 fps..
-
????
Interesting. As the engine adapts to loading the appropriate file any way based on what your launcher options are.
There is going to be a refresh soon, as part of solving the Installer issues and to accommodate any changes made for 3.6.10 EXE final.
-
Ok :) I never used installer :p but It looks like this shader need some optimisation...
-
That has (hopefully) been done, and should be in the package Herra linked to you, it just may not be fully over riding the existing ones.
Aw crap. Rename the VP file 3610-ZuperShaderz.vp. It will then appropriately overwrite the shaders in MV_Core.vp.
-
Hmm... If he's using them in a dedicated mod folder (like I suggested) rather than mediavps directory, then it's just a question of which is first on the mod command line.
-mod zupershaders,mediavps would work properly because zupershaders are loaded before mediavps shaders and thus take precedence.
-mod mediavps,zupershaders would not work because they would be loaded after mediaVP's, and the shaders in mv_core.vp would take precedence.
If you put the zupershaders in mediavps folder, the precedence is defined by alphabetical order. So a_zupershaders.vp would work fine, but zupershaders.vp not so much.
-
I am using extracted core files.. not vp's but I was looking for any shader files and In this old wing commander release I can't find anything it looks like it didn't use any shader except engine shader... BTW. I rename this ZuperShader to a_Zupershader but engine is still really slow...
-
I am using extracted core files.. not vp's but I was looking for any shader files and In this old wing commander release I can't find anything it looks like it didn't use any shader except engine shader... BTW. I rename this ZuperShader to a_Zupershader but engine is still really slow...
Ah yeah, you wouldn't have any if you're doing this with WCS. It doesn't have shaders to begin with, so the shader VP file will work quite fine...
Perhaps you're just being too optimistic about your hardware capabilities?
What's your GPU and driver version? I "can" see the normal maps on a GeForce 6600 on my older PC, but the frame rates are like 20 at best with ships on screen. 7600GT deals with them fine, and my current GeForce 8800GT even better.
-
I have GeForce Go 7150m
It looks like I was too optimistic.. But in my opinion in dual core processor and geforce series 7 this kind of shader should run with better frame rate than 20..
BTW. Again thanks for help :)
-
No, not really. CPUs, even modern ones, are not very good at doing the stuff shader processors in GPUs can do. (There are a few examples in the DirectX SDK where you can select to use the "reference model" that uses a pure software renderer, including the shader code. Good Luck getting a playable framerate with those.)
-
I have GeForce Go 7150m
It looks like I was too optimistic.. But in my opinion in dual core processor and geforce series 7 this kind of shader should run with better frame rate than 20..
BTW. Again thanks for help :)
It's more about the amount of memory and it's bandwidth and amount of processing units on the GPU core that defines these things, not the numbers. Even if it's a 7 series GPU, it's a low end mobile version and likely steals system ram for all the huge textures in mediaVP's. Low end GPU's also have less units to calculate stuff like shaders, clock speeds are lower, and so forth. I'm not surprised that a 7150m ends up doing 20 FPS, but that's assuming this value is when there's some ships in view. Empty space should go up to VSync frequency (usually 60 FPS), so if the absolute maximum is 20 FPS then something might be more deeply wrong (tried removing the MV_Advanced.vp yet?)
My 7600 GT 256MB usually kept the game above 30 FPS mark, but multiple capital ships and especially particle effects on-screen tended to lower it to twenties, below ten at worst.
-
This frame rate I have when I have some ships in view and I know that GeForce Go 7150m isn't powerfull but difference between this new shader and old one which using WCSaga is only normal maps.. but in frame rate are very very big difference. In comercial games time is very important so usually if somebody would like nice game must buy new computer but in opensource games time isn't very important and I think that shaders should be more optimising.. I don't say this because I would like to tick off somebody but It is very nice when You may run something on Your computer and it looks beautifull and run fast. BTW. when I create new model I try to make it nice and keep polycount low it takes me of course some more time but I think it's important
-
The nice thing about the shaders is that anybody can write their own.
And given that I don't recall WCS having any (at this time, could be wrong) shader worthy assets (normal maps) you can use a 3.6.10 build with -no_glsl and not miss out on anything eyecandy wise.
If, even with -no_glsl on, you _still_ have low frame rates, there may be other issues at hand.
The 7150 has a lot of nice qualities, but complex shadows and lighting are the quickest way to turn a game unplayable on an IGP. And while the FSO engine does not have shadows, the lighting could be considered complex in terms of how an IGP handles it.
It is important to note that 7100 series does not support technologies such as: high dynamic range rendering (HDR) and UltraShadow II as well. As far as I can determine it has any where from 2-4 Vertex and/or Pixel Shaders, which is not a lot of band on an already limited bus.
If that mobile GPU was anything higher than a dedicated IGP/MCP, then your assessment of Dual Core and GeForce 7 series would be correct. However, the 7150 actually classes closer to the GeForce 6 series functions with production refinements mostly.
Mobility solutions can almost never be classed in the same category as their desktop counterparts.
-
Even with the tutorials, its pretty hard to make actual good looking textures with normal maps on em. The HTL models are real works of art.
I more or less somewhat completed my first fighter model now though.
(http://xs538.xs.to/xs538/09145/tehray785.png)
The 'normal map' (if you can even call it that much) is just a simple clouds render height map in photoshop which has been through crazy bump. The diffuse map isn't exactly a work of art either. Spend a lot of time figuring out how to work with the uwv unwrap (it puts bits and parts all over, with no logic. Was a pain just to figure out what goes where). The mesh is around 580 or so polygon's.
Feedback is very welcome.
For my first spaceship model i'm somewhat pleased. But I really wish to improve from here...
-
The tile type pattern suits larger ships. Use either motion blur to streak (or smudge)
The thing you are looking for is design. Grab the image and paint on it - DO NOT try to be careful and tidy, you want ideas. Some of them will look great, others need erasing ;) Once you have finished you will need to decide which texture bits belong on the the normal rather than the diffuse map. It can also give extra ideas to add to the mesh.
Don't worry if the first attempts look bad. Also the dodge/burn tool can be used to break up monotone areas into larger type panels.
Extra tools are useful. Blender has a paint on model mode that can help with the photoshop layout. If that's not an option, then colouring the polys and baking that out as a texture map would be a good first step to locate where everything is.
(http://i229.photobucket.com/albums/ee67/waternz/other/tehray785b.jpg)
-
After reading your post I was impressed, just a few lines, stripes and color makes such an improvement! So, I went to work.
(http://xs538.xs.to/xs538/09140/2184.png)
(http://xs538.xs.to/xs538/09140/3713.png)
Surely it's still not as pretty as any of the HTL models but personally, i'm happy.
(http://xs538.xs.to/xs538/09140/1904.png)
Thanks Water for the feedback, it really helped me progress!
-
No problem, the first attempt is always hard.
-
For real good normal maps, you practically have to create your own base texture. Precreated texture panels just don't give good results.
-
i'm planning on a large mod/campaign and i'm doing everything on my own. So i'll allow myself some degree of non perfection. If not i'll be forever stuck on details and i'll never get anywhere...
Creating a base texture with fancy panels by myself will probably take me an other day with mediocre results...