Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Bobboau on March 01, 2004, 01:38:24 am
-
today I was thinking about some stuff, and with the newer memory management code added shortly after the decal code was made I decided to make a fork of the work I had currently and merge in the new decal code to see how well it actualy worked, I was suprized by how well it actualy did, and I spotted and fixed the big memory leak bug rather quickly. haveing spent fifteen minutes going over old code I thought for a moment about my experements with something a few months back and decided to reintegrate it into the fork I had, in the proces I saw what I had been doing wrong all those months ago and it finaly worked, another hour of work and I had it running nearly flawlessly.
now before some individuals start reminding me about the freize, 99% of this was something I did months ago (well the new decal code was a few weeks, it's in there as well), and I have fixed a lot of bugs over the last few weeks, so this isn't deriliction of duty.
now that said try out this build (http://freespace.volitionwatch.com/blackwater/fs2_open_env.zip) and see if you can tell what I did (note; don't go to the tech room as you need to be in mission once before it will work properly)
first person to guess corectly wins.. being the first to see it.
look carefully, it is a somewhat subtle effect.
-
can be seen with just any mission or..?
-
eh, any retail mission, most user created missions worth a crap, the new background test missions LS made would probly be great
-
I really should be studying for my midterms right now XD
Anyways...
WAY COOL, ENVIRONMENTAL MAPPING *cheers*
And there seems to be a lot more debris (transparent too). It's a little distracting having that much stuff flying into my face with full afterburners.
Framerates still good. A steady 85 as usual for the first mission.
-
yup :D
cubic, made on the fly specific to a mission
-
Do I get a cookie?
-
uh, yeah, sure
/*pulls cookie out of the void*/
-
So eh... will this be a 3.6 thing then?
--Rga
-
Woohooo!
/me goes off and tucks it away in a personal subspace vortex locker
-
will not be in 3.6, will be after 3.6, imediately after
-
Mmmmmmmmm....so reflective.
-
post screenies dammit!
-
env map is kinda hard to show in a screenie. i used my skybox and it was just plain sweet. i take it that it uses the shine map in the rendering code. id never thought id see that in freespace.
-
my hosting is gonna break for this.....
im not sure if this captures it - hope it does, otherwise i loose a lot of bandwidth for nothing :/
(http://anandraj.sphosting.com/Freespace2/test.jpg)
(http://anandraj.sphosting.com/Freespace2/test2.jpg)
-
Oh man, way cool! Very metallic. I love it.
-
You need to see it live. The shininess is awesome, Bob... but you gave it away in the exe title. :D
Yeah, screenshots don't do it justice:
-
uhm, bob?
when you go to external vview, move around a bit, and then go back in, the back end of the fighter stays visible in the lower part of the HUD.
when pulling up, it disappears, but when moving down, the back end moves up.
when warping out, you see the rear end disspear through the node, but you continue straight on, and then you see the debrief.
-
(http://nodewar.penguinbomb.com/aotd/kasperl/screen00.jpg)
(http://nodewar.penguinbomb.bom/aotd/kasperl/screen01.jpg)
(http://nodewar.penguinbomb.bom/aotd/kasperl/screen02.jpg)
(http://nodewar.penguinbomb.bom/aotd/kasperl/screen03.jpg)
(http://nodewar.penguinbomb.bom/aotd/kasperl/screen04.jpg)
i don't know why these are red x's, they work when i go to the url directly.
here are the links, in case it keeps bieng red x.
http://nodewar.penguinbomb.com/aotd/kasperl/screen00.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen01.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen02.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen03.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen04.jpg
-
if you think that is sweet, try it with a skybox
-
Originally posted by Nuke
if you think that is sweet, try it with a skybox
how do you get this skybox? :/
-
skybox (http://www.angelfire.com/ak3/nukewar/skybox.zip)
pof in models, jpgs in maps. use opengl fred and put the name of the pof in the skybox field in the background editor.
-
yeah it uses the shine map, I figured it would be just about perfict, and haveing a thrid map would be a huge wast of memory and slow, this way it already has the shine map set properly and it just canges a few minor things and makes a third pass (no way to realy do this well at the same time as the shine map)
-
bob, what about that bug i posted?
do you know if this is your code, or should i try FSO 20_01?
-
I don't know what your talking about there,
can you get a screen shot?
-
Looks gorgeous, but by God it takes a chunk out of the Framerate at the moment ;)
Flipside :D
-
it does? I didn't see any diference
-
Originally posted by kasperl
(http://nodewar.penguinbomb.com/aotd/kasperl/screen00.jpg)
(http://nodewar.penguinbomb.com/aotd/kasperl/screen01.jpg)
(http://nodewar.penguinbomb.com/aotd/kasperl/screen02.jpg)
(http://nodewar.penguinbomb.com/aotd/kasperl/screen03.jpg)
(http://nodewar.penguinbomb.com/aotd/kasperl/screen04.jpg)
i don't know why these are red x's, they work when i go to the url directly.
here are the links, in case it keeps bieng red x.
http://nodewar.penguinbomb.com/aotd/kasperl/screen00.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen01.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen02.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen03.jpg
http://nodewar.penguinbomb.com/aotd/kasperl/screen04.jpg
http://nodewar.penguinbomb.bom/aotd/kasperl/screen04.jpg
.com not .bom
-
Hmmmmmmmmmmm... It's probably the way it's being used here, look at 'RT's Texture Code' thread in the Internal Forum, and imagine that with Environment mapping, I think that's what's causing the slowdown ;)
-
well turn off his code, he said you shouldn't use it anymore (as it doesn't work)
and can we get some shots of something that is not the ass end of a Loki
-
I was going to say that the glitch is probably retribution for choosing to fly a Loki in the first place :p I don't have time to test this right now, but the premise is more than a little exciting. Can't wait to see the environment map off of my cockpit glass :)
-
Can we a screenie with someone using a skybox?
-
Originally posted by Bobboau
and can we get some shots of something that is not the ass end of a Loki
That was his complaint. :p
-
When I start up this build, nothing shows up. There's just a fullscreen black screen, and the menus and sounds are underneath but invisible. This includes not displaying the splash screen.
Latest one I have that works is 1/20/04.
ATI Radeon 9000 Pro 128mb
1024 mb RAM
Intel Pentium IV 1.8GHz
Windows XP Home Edition
Are there any known fixes for this bug, like registry changes or something? Or do I need to figure out how to work Mantis and put it in there?
-
Ambient Light kills this feature - i would really like to see this with ambient turned almost to zero. Implemented the command line yet? :p
Also, I found a really nice & hidden bug for you. It's not actually a bug, but a feature.
Well, you have updated the way ANIs are loaded into textures - they get preferred over other file formats. That's good - but it causes a slight problem with the main FS2 data. The tech room anim and the texture of most bombs (and some other missiles) have the same name. Try firing a cyclops in-game. It will use the tech room ani as a texture instead of the bomb texture. Same with Helios, the TAG missiles and some other stuff as well. :D
-
I turned off some random stuff in the command line section...and this build seems to work.
Kickass!
-
mm it doesn't work here, but due to my old system, you probably don't have to worry about.
I see something like the old shard of death in the techroom, but much much more messy, the screen is flashing white and is messy, everything is slow, even the movements of the mouse cursors, and I can't continue to the mission simulator, no matter how many time a press the mouse button, and after a while it crash and I have to reboot.
-
Another erm... feature.
Try dying in a mission. It's quite a _stretch_ to believe that is supposed to happen ;)
-
don't mention this in any bug reporting (mantis) yet as it's just a little demo thingy.
the animation thing is going to require some major hackage to get working right, this is why I had it set to load anis if it couldn't find a texture, not the other way around.
as I said, the tech room isn't likely oing to work (at least not before you go into a mission fist)
and Solatar, try to figure out with comand line option killed it
-
Originally posted by Lightspeed
Also, I found a really nice & hidden bug for you. It's not actually a bug, but a feature.
Well, you have updated the way ANIs are loaded into textures - they get preferred over other file formats. That's good - but it causes a slight problem with the main FS2 data. The tech room anim and the texture of most bombs (and some other missiles) have the same name. Try firing a cyclops in-game. It will use the tech room ani as a texture instead of the bomb texture. Same with Helios, the TAG missiles and some other stuff as well. :D
Hey, that's freaking cool! :D
-
Originally posted by Bobboau
and Solatar, try to figure out with comand line option killed it
Already working on it.:)
EDIT: -d3d_notmanaged
Says it's not finished in the launcher anyway, and I was just checking out random command lines. I did manage to get into the game. Ingame, all textures are white, there is no HUD, no backgrounds, no text.
-
Really? I turned that off, and every screen was 'screenes' over the prior one and the mouse left a trail all over the screen. I do have a screeny if anted. :p
-
Originally posted by Unknown Target
Can we a screenie with someone using a skybox?
(http://www.angelfire.com/ak3/nukewar/sbenv1.jpg)
(http://www.angelfire.com/ak3/nukewar/sbenv2.jpg)
(http://www.angelfire.com/ak3/nukewar/sbenv3.jpg)
-
Ach, I won't get a chance to test this beauty out till the weekend. In the mean time, let me just say, regarding the piccies in this thread (the ones which aren't the arse end of a Loik): DAMN![/b]
-
the hecate is pants wettingly cool now (useing LS's shinemaps)
-
ok, last I'm going to touch of this till after 3.6, I added my trueform code into this and it makes everything just, oh so much better looking (too bad it also makes everything crash randomly for no reason)
use the comand line -max_subdivide 2.5 (2.5 can be a smaller or bigger number, that's just what I recomend for now)
it's the same file,just re-download
-
Originally posted by Bobboau
as I said, the tech room isn't likely oing to work (at least not before you go into a mission fist)
yeah, the prob is that I can't even get to the missions:p
-
Nuke, you have the most psychadelic backgrounds I have ever seen in all my days of FSing. ;)
-
Originally posted by Bobboau
well turn off his code, he said you shouldn't use it anymore (as it doesn't work)
and can we get some shots of something that is not the ass end of a Loki
bob, one more time:
i am reporting a slight bug, when you go out of the cockpit, and then back in, you see the back end of your ship, locked in front of you, when you moce around, it mves in the opposite direction, the screenies show the exact problem. the only problem was that i posted with an .bom URL instead of .com, redmanace reposted it without the typo.
-
oooo damn I have piccies of an Orion - but I need someplace to host it, seeing as how all ye HLPers managed to break SPhosting AGAIN!!! :P
-
(http://anandraj.sphosting.com/Freespace2/env8.jpg)
(http://anandraj.sphosting.com/Freespace2/env7.jpg)
(http://anandraj.sphosting.com/Freespace2/env6.jpg)
(http://anandraj.sphosting.com/Freespace2/env5.jpg)
(http://anandraj.sphosting.com/Freespace2/env3.jpg)
-
4 FPS?
-
takeing screen shots does that
-
It's even worse with the original FS2 actually since it's writing even larger .tga files (not that bmp is exactly small!). :D
-
in d3d, the screenshot function also compresses the TGA while the OGL version doesn't so its much faster, but i doubt the effect will work. this is yet another thing to work on *sigh*
-
BTW how do you disable ambiant light?
-
Can we please make specular and reflection maps seperate? I really hate seeing metal that should be specular, but not reflective also.
-
Deepblue, I think this answers your question:
Originally posted by Bobboau
yeah it uses the shine map, I figured it would be just about perfict, and haveing a thrid map would be a huge wast of memory and slow, this way it already has the shine map set properly and it just canges a few minor things and makes a third pass (no way to realy do this well at the same time as the shine map)
-
No. It doesnt look good to have both shine maps and reflection maps on the same surface sometimes. (especially when it comes to the hull, it should be shiny but not reflective)
-
Okay. I must be doing something wrong cause as soon as I run this build all the specular lighting and glowmaps disappear.
Here's my command line -spec -glow -pcx32 -jpgtga -d3d_no_vsync -d3dmipmap -fps -fov 0.42 -max_subdivide 2.5
-
Originally posted by Deepblue
No. It doesnt look good to have both shine maps and reflection maps on the same surface sometimes. (especially when it comes to the hull, it should be shiny but not reflective)
i kinda think he's right, the effects should be kept seprate. however adding another map could be a problem too. another pass would slow things down abit.
i take it that this code is based entirely off of an older build and has nothing to do with the uber fast htl test build. assuming this, once the code is integrated into the uber htl build then we could probibly get away with another pass if we sacrifice uber polycounts (as in < 8000 polys/ship). the map situation would start getting out of control, modders would need 4 bitmaps/ship (texture, glow, shine, and env). this gets confusing fast. i think havins some kind of material library woud be cool.
-
I dare say that his code is actually rebuilt on top of the uber-fast HTL code since it's going at 65-85fps for me.
-
shiny = reflective.
Another map is a useless waste.
-
Nothing should be shiny but not reflective. Shiny things reflect light, which is why they are shiny.
-
Holy smoke!
(http://www.penguinbomb.com/lightspeed/SCPTest/Ravanaprecious.jpg)
(http://www.penguinbomb.com/lightspeed/SCPTest/Ravanaprecious2.jpg)
Just look at this!
I LOVE THE NEW AMBIENT FACTOR!
I LOVE THE ENVIRONMENTAL MAPPING!
The only prob with the new build: If I turn on trueform it gets slow as hell, with it turned off I don't seem to have any slowdowns at all. I'll do a proper performance test tomorrow.
-
Originally posted by Solatar
Nothing should be shiny but not reflective. Shiny things reflect light, which is why they are shiny.
In that case is there any way we can control the glossiness of the specular? Right now specular on cockpits doesn't have nearly enough gloss.
-
Thats awfully purty bob
the effect is obscenely overdone on Terran ships; i didnt test any Vasudan caps, but the toths in the test missions looked alright.
Test mission: Greyface
Karmas skybox, LS 32-bit TGA art
Bob, it olny renders backround art.....i wanna see me in the reflections :P
notice the planet.....
(http://mywebpages.comcast.net/ksickafoose/images/envmap01.jpg)
It looks amazing with a skybox
(http://mywebpages.comcast.net/ksickafoose/images/envmap03.jpg)
the effect looks alot better on darker ships
(http://mywebpages.comcast.net/ksickafoose/images/envmap02.jpg)
Lightspeed already pointed this out, it look ****ing awesome on Shivans. Its renderd in perfect subtley.
-
I myself nearly pissed my pants the first time I saw it on an Nephelem (that is my favoreite shivan ship), and it's just amaseing to fly over a big ship and haveing all that reflaected detail rippleing below you
there do seem to be some small bugs in the setup of the cubemap (some if not all the reflections are out of alignement)
and this is not ever going to be reflecting weapons or other ships, it's just not how this works
-
try it on the seraphim....my god the seraphim looks EVIL in the techroom - imagine it In-game!!!
And I still dont know how to use the skybox, or whether im using it and it makes much of a difference. I entered everything correctly - but my background is still there. Is the skybox supposed to replace those or simply add on to them?
-
I think it adds on
-
you know, there is a differance between diffusive reflectance and direct reflectance. its like comparing a shiny silver plate to a dull titanium panel. you could use a second 24 bit texture for reflctane mapping you could assign the red channel to diffuse reflectance, green for env reflectance, and blue for mirror reflectance (or any other feature requiring a map).
-
ooh, that's a good idea
R for Glowmap
G for Specmap
B for Envmap map
Environment map map sounds lame. I need to find the correct vernacular for that.
Although, I don't think that would work for the glowmaps now that I think of it, as those utilize color...as do a few specmaps also
Ideas, ideas...
-
environment could be held in the alpha mask of a shine map
-
would that mean like.....you would only need one texuture for Glow, spec, and evn?
kewl...
-
Ok, did my brain just bug out? i coulda sworn there were some awesome pics of the enterprise using Bobs code in this thread.
--Rga
-
I made one in the modding forum, that is were tehy are
-
am I the only one to dislike the fact that everything looks glassy now? The fenris is all grey, stained, battle sworn, not some kind of stylish mirro :doubt:
That's great for cockpits and stuff, not for hulls ( well, depends of the ship, of course ). it should be there, but so faint that you can't recognise planet03.pcx on the wing of your fighter...
-
Originally posted by karajorma
Okay. I must be doing something wrong cause as soon as I run this build all the specular lighting and glowmaps disappear.
I'm also getting this problem. It might be caused by some older change though as I haven't downloaded a new build in a couple of months.
-
Oh and I agree with you Nico. It looks a little over the top judging from those screenshots, also verging on tacky.
-
id like to avoid using an alpha chanel because it prevents one from useing the 8x compression advantage of the dds format (using dxt1). using other dxt formats decreases the compression ratio. if the glow map rendering code was altered in a manner that it would use a greyscale image rather than a color image, then you could combine glow/spec/env map into a single 24 bit image file. that way your texture would be in one map, and your effects would be in the other. usind dxt1 dds files, both the maps file and the texture file would still take up half as much memory as a single tga texture. the downside to this idea is that it would require a total overhaul of the glowmap code. in addition it would render any maps made by the community useless. of course all one would have to do is convert their env, glow, and shine maps to greyscale, then paste them into seprate channels in 24bit image in photoshop.
as for making the glowmaps greyscale without loosing light color data, it would be tricky. the way i understand them, they are simply rendered fullbright a pass after the texture gets rendered. instead would it be possible to multiply the pixels in the texture map with the greyscale glowmap, then render the resulting pixels as fullbright. this sound simple but it might be too much overhead when it comes to rendering effiecency.
-
Amen
-
Im not sure if DDS can be used that way.
-
as far as the file format is concerned it contains a channel of red, a channel of blue, and a channel of green. when freespace sees it it sees a channel of glow, a channel of spec, and a channel of env. but now that i think about it i havnt a clue how the video card (and the code as well) handels such things.
-
Originally posted by Nuke
you know, there is a differance between diffusive reflectance and direct reflectance. its like comparing a shiny silver plate to a dull titanium panel.
they are both about as reflective as each other. the "dull" quality you speak of is actually because of the surface is rougher, blurring the reflection.
the reason some things have specularity but not apparent reflection is because the reflection is so subtle that it's hard to see, but the specular highlight shows up because the light source is so bright. it's beyond 255 255 255. so if bob would just make the specular highlight smaller but extremely bright, it would solve the problem.
-
Idea for the RGB solution:
for the glowmaps, let's use the color already present in the texture, this way they'll just be a brightness map. You could use the red channel for this.
Then you can use in the glowmaps another channel (blue) for the envmap.
Since the shinemaps use color sometimes they'll need to be a separate map.
You will still have another channel (green) free for use in those new glowmaps......bumpmap?
-
Originally posted by Wes
I'm also getting this problem. It might be caused by some older change though as I haven't downloaded a new build in a couple of months.
Add this flag to your command line -ambient_factor 75 (You can change the 75 to another number if you want).
-
*grumbles* Guess what?.. that's right.. no workee!
-spec -glow -pcx32 -jpgtga -fps
anything i need to add to this to get it to work?
-
Originally posted by KARMA
Idea for the RGB solution:
for the glowmaps, let's use the color already present in the texture, this way they'll just be a brightness map. You could use the red channel for this.
Then you can use in the glowmaps another channel (blue) for the envmap.
Since the shinemaps use color sometimes they'll need to be a separate map.
You will still have another channel (green) free for use in those new glowmaps......bumpmap?
No.
I have an idea that will keep it working.
Glowmaps need to be seperate, as you can do cool stuff with seperate glow maps (lights that leave black bulbs when turned off, not some turned on but 'not glowing' lights, etc.).
Specular maps without an alpha channel will use the normal spec map as the env map. If the image has an alpha channel, it will use the shinemap's alpha channel as the reflective map. Like this, you can create barely shiny but really reflective cockpits (the only use I find for having seperate shinyness and reflectiveness on one surface).
So you would have:
Texture
Texture-Glow
Texture-Shine
as we have it now, but with added Env map in the shine texture.
This doesnt break anything and will look good enough without extra data, and extra data will be easy to add in. Transparent shinemaps / reflective maps are nonsense so using the alpha channel is a really good idea, since most formats you use support alpha channels (TGA, DDS) - and if it doesnt find one it will simply use the normal shinemap. You will be able to use most shinemaps unmodified, and only some specific ones (fighter cockpits etc) will have to be modified.
That's what I would like to see :)
-
Originally posted by Turnsky
*grumbles* Guess what?.. that's right.. no workee!
-spec -glow -pcx32 -jpgtga -fps
anything i need to add to this to get it to work?
I only had -fps and it worked. :nervous:
-
...
okay.. if ANYBODY can recreate this, i would appreciate it
AMD athlon XP 2200+ (1.8ghz)
256mb pc2100 ddr
128mb ATI Radeon 9000 pro (hecules)
Ati catalyst 4.2 drivers
DX 9
-
i agree with lightspeed, glowmaps should be able to keep colours in them.
do specmaps use colours?
-
Originally posted by Lightspeed
Glowmaps need to be seperate, as you can do cool stuff with seperate glow maps (lights that leave black bulbs when turned off, not some turned on but 'not glowing' lights, etc.).
I don't agree, makes no sense, lights that turn automatically on when a ship turns away from light :doubt:
-
Originally posted by Turnsky
*grumbles* Guess what?.. that's right.. no workee!
-spec -glow -pcx32 -jpgtga -fps
anything i need to add to this to get it to work?
I saw nothing until I used -ambient_factor 75. I have no idea why it works now but it did.
-
no, he mean a light that could be turned on/off on a ship, and when the light is off you see the area (a window, or any else) dark.
But still, it's nothing you will really loose removing the colour from glowmaps
you can obtain the same results with animated textures/glowmaps and/or glowpoints, which wouldn't be much a performance problem since it's something that will be barely never used anyway, and removing the colour from glowmaps you'll have room for future bumpmaps w/o having to increase bits and therefore kb size of the maps.
And about why to keep reflections and shinemap separated is to have material-dependent reflections. As it is, it generate a chrome effect that personally I don't like, and I'd like it to happen only on certain surfaces.
Nonetheless using the alpha channel is surely a fair solution, mostly because it'll require less changes to the existing maps.
But then, it's a coder's decisions.
-
"Specular maps without an alpha channel will use the normal spec map as the env map. If the image has an alpha channel, it will use the shinemap's alpha channel as the reflective map."
that was my thought exactly
glow maps should remain seperate as right now you can have animated glow maps, and as said, glow maps that when turned off have a black spot rather than a whit spot (though nobody currently takes advantage of this). and shine maps use full color to a much greater extent, it is an incredably cool effect to have a spec map of a totaly diferent color than the defuse color (though this is only being used to a slight extent)
-
TVWP uses 'real ship lights' :D
Anyway, glad we agree 100% on this Bob.
I did some performance tests with your nice new build (which I have switched to as my standard FS2open build):
Performance:
COMPARISON:
Testing with TestMission Set v1.0: 20_01 build 26-2 test build Environmental Mapping Build
Testing with TestMission Set v2.0 (same as build v1.0, but crammed with my new nebula effects to test with "busy" backgrounds): Environmental Mapping Build
Polygons & Textures
(using the standard texture code (tick box not checked))
Detail - 1:
85 FPS | 85 FPS | 85 FPS | 43.4 FPS
Detail - 2:
44.3 FPS | 42.5 FPS | 42.5 FPS | 42.5 FPS
Detail - 3:
42.5 FPS | 42.5 FPS | 28.4 FPS | 28.4 FPS
Detail - 4:
28.3 FPS | 28.3 FPS | 21.4 FPS | 21.4 FPS
ANI performance
Low Use:
min: 85 FPS | 85 FPS | 85 FPS | 42.5 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 85 FPS | 85 FPS | 85 FPS | 85 FPS
Medium Use:
min: 85 FPS | 85 FPS | 85 FPS | 42.5 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 85 FPS | 85 FPS | 85 FPS | 85 FPS
High Use:
min: 35 FPS | 30 FPS | 42.5 FPS | ~37 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 38 FPS | 42.5 FPS | 42.5 FPS | 37 FPS
Weapon Effects
(using the standard particle rendering)
Low:
min: 85 FPS | 85 FPS | 85 FPS | 85 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 85 FPS | 85 FPS | 85 FPS | 85 FPS
Medium:
min: 85 FPS | 85 FPS | 85 FPS | 81.4 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 85 FPS | 85 FPS | 85 FPS | 85 FPS
High:
min: 61 FPS | 85 FPS | 85 FPS | 45 FPS
max: 85 FPS | 85 FPS | 85 FPS | 85 FPS
avg: 75 FPS | 85 FPS | 85 FPS | 80 FPS
Result:
The speed drop compared to the latest Test build and the 20_01 build is really small - It runs (almost) at the same speed, yet offers a lot more eye-candy. I'm sure when you perfect it (after 3.6) you can even make it cause less slow down than now.
Two thumbs up :)
-
there shouldn't be much of a performence drop at all, as the environment map is just a set of 6 512 textures, wich is rendered once per frame (this could be further improved to only being rendered once per mission, but anything that might be animated (someone try it out in a subspace mission!) wouldn't have an animated reflection) the only people who may have a slowdown would be the people who have cards that don't suport the rendering of cubemapping very well.
-
Originally posted by Drew on another thread
LS, i was foooling around with bob's evn build and i noticed that i couldnt move around the primaries on the select screen. not sure if this is a table error or what but could u please look at it?
i can mess around with Secondaris just fine...
I've noticed this too. It happened with LS's mods and with MindGames (which doesn't use them) so I think it's a problem with the build.
-
:shaking:
uh oh
:(
-
Originally posted by Nico
am I the only one to dislike the fact that everything looks glassy now? The fenris is all grey, stained, battle sworn, not some kind of stylish mirro :doubt:
That's great for cockpits and stuff, not for hulls ( well, depends of the ship, of course ). it should be there, but so faint that you can't recognise planet03.pcx on the wing of your fighter...
*points*
Originally posted by Deepblue
No. It doesnt look good to have both shine maps and reflection maps on the same surface sometimes. (especially when it comes to the hull, it should be shiny but not reflective)
-
Originally posted by Bobboau
:shaking:
uh oh
:(
is this very serious?
and how can something graphics related interfere with interface/table structures?
-
Hmmm, there's some weird problems with this build. Sometimes after playing several missions in succession, the 2D graphics in the options screen and stuff borks.
And then, for some reason I've yet to find out, when the Auriga jumped in (Derelict Mission), the framerate drops to 4 (1) unless I'm not lookin directly at it.
That said, this doesn't really matter (and I'm not going to post them on Mantis) since this is just a fun build =)
-
Originally posted by kasperl
and how can something graphics related interfere with interface/table structures?
that's why I'm worried.
-
anyway bob,
its weird, the evn mapping works on my card, but spec lighting still dosnt work in HT&L. thats why my ships look so ****ing glossed
its messed up i tell you
-
That ship selection problem is sporadic, if you persevere, it is possible to select a ship and place it, though several rapid left and right clicks are needed.
-
hmm, actualy now that you mention it, that does sound familiar, I was haveing the same problem, but I just thought it was the new wireless keyboard and mouse I just got acting up (it does that some times)
-
Originally posted by Bobboau
hmm, actualy now that you mention it, that does sound familiar, I was haveing the same problem, but I just thought it was the new wireless keyboard and mouse I just got acting up (it does that some times)
That's what I thought at first. I've also got a wireless mouse and the behaviour is similar to when the batteries are running out.
*Wonders if the wireless mouse thing is a coinicidence*
-
maybe we all got wireless mice at the same time and now the batteries are all dieing syncronusly
-
No, I remember having that same problem with an earlier build (I think it was 18_11_03) - but it vanished with the next new build released. Haven't checked it in the env build yet.
Using a corded old-skool mouse here so the probs definately been the build.
-
if your wireless mouse/keybord are acting up, move the reciever away from em sources, such as your monitor, computer, or emp generator. the thing is subject to rf interferance.
i disagree with the use of an alpha chanel for env mapping. not all dds textures have an 8x compression ratio. dds is just its extension, there are many pixel formats that it may use. each format has different compression ratios. dxt3 and dxt5 formats, which support alpha cannels, are twice as big as dxt1 format. id personally rather use an 8 bit (grey or index) texture format on all my maps, as to keep down memory usage. im concerned that we are putting too much data into the various maps. think abour it, whe have 24 bits in our textures, then 24 in outr glow, 24 in our shine, and another 8 in the env alpha channel. thats 80 bits per pixel. does anybody around here think that that is too much data? my idea uses 24 bit textures and 8-bit maps merged as channels in another 24 bit image for a total of 48 bpp. used in conjunction with uber compressable dxt1 the memory advantages are huge. if you need color in a map then the engine can multiply the texture pixels with th map pixels to generate it.
-
We have 8bit textures, 8bit glowmaps (who needs more colours in glowmaps needs to be whacked), 32bit spec maps (with env included) --> 48 Bits per pixel.
Also, there is DDS formats with alpha channels and good compression (although alpha is quite limited: to 16 different shades or so) - and who needs the performance that badly will not have a vid card able to store DDS textures anyway.
Really, screw the whole DDS thing. It's good for huge textures that can be compressed quite well, but not actually neccessary for small shinemaps. You can still have DDS textures, glowmaps and whatever you like. If it's still killing you, scale down your shinemaps (you'll lose quality, but so you will with DDS).
---
Tried around with the env build more (found out 2 things):
- Weapons & Ship selection works normally for me. No problems with Derelict (have to try with other mods)
- There seems to be a certain slow down when i'm getting close to larger ships (cruiser+) - It happens if the distance gets less than around 100. It slows down the framerate quite a bit (by at least 30 FPS). There's no LOD / texture switching, so technically it shouldnt be happening. It doesnt happen with any other builds, either.
-
I can't seem to get better than 10 fps with this build. And it CTD's after 20 seconds, but I had a randomly generated BG full of LS's nebulas, and I put a setekh class awacs with LS's shinemaps, and observed the beauty reflected on the arrays. I want a new vid card. :( :cry:
-
It's strange, but I'll reiterate, the Auriga (orion class) destroyer in Derelict REALLY slows down everything (to <10fps). I haven't got around to testing it with another orion yet though.
Doesn't happen with the Hatshepsut in the first mission of main campaign.
I get 85FPS staring at a few fighters, 70+FPS staring at an hatshepsut and 30-40FPS staring at a full blown battle with debris (Derelict style).
As soon as the Auriga came into view, it suddenly dips to <10FPS until I look away. @@
-
if ether one of you are useing trueform try turning it off
-
I'm not using it since I have a GF4 ti4200 ;)
I wish I had a 9800XT but that isn't going to happen unless some money magically appears, heh.
-
I'd have loved to pick some shots of a nebula reflecting on a TF cockpit, but it seem that I've to forget this:(
if I get to mission directly it crash, if I get to mission simulator the techroom crash:( ohh well I really need a new hardware.
btw, little ot:
is there a commandline to graduate the mipmapping? it's nice but it makes as it is the textures too smoothed.
-
btw I don't disagree with nuke's idea, as I already said, for a simple reason: we'll need in future 8 additional bits for bumpmaps, and hopefully 8 more bits for transparency (the pure green thing is quite limiting, and the tga's alpha is not designed for model's textures), and personally I don't think that making the glows 8bit would be that a loss, since there are other ways to obtain the same color effects (changing the underlying texture color), the few times you need em.
which would mean 24bit textures (32 bit with transparency)+ 24bit map(glows+bump+env)+8bit shinemap(I doubt you need more than 256 colours).
Talking about performance it is probably the best solution, but admittedly it would require some modifications to some already done stuff, which is a thing that it is better to avoid
-
I still side with mine and Bob's idea.
-
It still neglects the way glowmaps are currently rendered, and eliminates an option for modders in the way we use glowmaps to get colors. It could certainly be done, I just don't see the need. It's really the elimination of color from shinemaps that concerns me most, because as it stands some of the coolest effects I've seen come from using a different color shine than the hull.
Plus, I've got to go with what's previously been said here: shine maps should be used as environment maps. If you don't want something to reflect it's environment, don't make it shiny. While I do understand that you can have a diffuse shine like brushed metal and not get a reflection out, that reflection should (and by the look of things does in the current system) still reflect the color of whatever is emmiting or reflecting light on to the panel.
-
a mirror is different than a metallic plate.
reflective=mirror
shinemaps=metal
in many of the pics posted so far you could see ships so reflective that looks like if plated with crome, like a car, and suck, but still they'd need to be shiny since they look many times better if shiny.
Look at venom's arcadia in the thread on the modding forum, and other pics too.
env and shiny must be separated, that's it.
and nobody proposed to remove the color from shinemaps
-
I'm with karma on that.
i'll take the 3dsmax exemple: you have reflectivity, specularity AND even glossiness. You're taking some serious shortcuts assuming spec and reflections are the same and proportional. A high specularity re"flects light on a certain angle, that means you won't see anything more than oversaturated light. A white blob, for exemple. That has absolutly nothing to do with reflectivity. Take a mirror: either you see yourself in the mirror ( and then no specularity at all ), either it's all specular ( and you won't see a reflection at all ).
Balancing that is, actually, an essential part of material making for high poly modelisation. Please don't take some simplfied way and label it "it's that way, like it or not" when it's, more or less, the exact opposite.
-
Thats exactly what I have been saying.
For example, when you look at the SS anis for the Herc and Herc II they have reflection but no specularity, the bright spot you do see and might call specularity is merely a reflection of a light.
-
That's exactly the reasoning behind bob's and my idea.
Using the spec map as an env map works in a lot of cases. If you have it use the alpha channel if present, you will only have to update a few textures (for example the cockpits) - You won't lose much performance, and you will be able to have seperate shine & env intensity while not losing any possibilities you have right now.
-
Bob, are you going to make it so that ships will also reflect?
Cause it's sort of wierd when only the background does :)
-
I think that's not possible that easily :p
-
it's possible, it'll just destroy the framerate.
from what i understand, at least.
-
a) would be very tough to implement this into FS2
b) would kill every hardware there is available.
-
even duke nukem had it:p (joking)
no, seriously, I really don't remember exactly but there were a reflective effect on some Tachyon surfaces, but I don't remember if it worked on ships and stuff too.
-
there was no reflections in Tachyon.
-
I cant imagine it NOT destroying the framerate, due to the fact that when I use true reflection in Max, it takes a long time to prepare the reflection maps to render.
-
i get your point light/bob but i still dont like having to use an alpha channel. i really want to keep my effects maps down to 8 bit (grey or index). using an alpha channel forces us to use a 32 bit texture for effects. id much rather have -env and -shine in seprate 8-bit maps.
another incredibly complex and mind disrupting idea is to use a 24 bit effetts map and use only the first 6 bits te specify color data (64 shades of r, g, and, b), the remaining 2 bits specify what effects to use (up to 4 effects). that way you could apply effects on a pixel by pixel basis and possibly allow for a single pass rendition.
-
why - when making it alpha-based is sooo easy? :rolleyes:
-
alpha channels would be far difficult on modders who do not have acess to photoshop. i use photoshop for everything and for me, alpha channels are easy. but have you ever worked with alpha in paint shop pro or other non-adobe graphics programs.
-
Originally posted by Lightspeed
there was no reflections in Tachyon.
yes there were
the cockpits during the tunnels, althought it could be just a fake reflection made with an animated map, and I seem to remember a surface on a station, but I could be wrong in this and I should check (but I'm not going to install the game only for this)
-
it was most definately fake, you never got the same effect in the actual game. it makes me wonder if those tunnels were pre-animated. i never liked tachy on the fringe, plotlines were silly at best and you could never free roam space like you could in privateer 2 and freelancer. i did like multiplayer though, basewars were awesome. it is said that tachyon has better physics, though you could get the same effect in fs2 by increasing damp factors.
-
Originally posted by Nuke
it was most definately fake, you never got the same effect in the actual game. it makes me wonder if those tunnels were pre-animated.
you mean like a .avi cutscene? they should have looked better, then. more like the intro cutscene.
-
I use paint shop pro, and I sudgested alpha chanle, the thing is keeping it in one texture, if the shinemap contains an environment channle, then a slow slow slow texture change can be avoided.
-
Not only that, wouldn't changing the glowmaps to 8 bit mean that every single modder in the community would have to start batch converting their recently made glowmaps? That would NOT be very popular ;)
-
btw anyone who makes glowmaps with more than 8 bit is a lame, and you don't need more than 256 colours for shinemaps too.
All the :v: textures are 256 colors, and the only situations where you really need more color depth are on nebulas, planets and stuff like this, with lots of colors and lots of graduation of colors. But even if it may be reasonable to go for 24bit textures, using more than 8 bits for glows and shinemaps is just a waste imo.
And this is my main concern of using alpha on shinemaps.
unless it is possible to have an alpha channel on a 16bit (8 for colors + 8 for alpha) image, which I don't know (and in this case I'll shut up and you really should go for this solution), you'll be forced to use 32bit (24 for colors and 8 for alpha) shinemaps, which sound to me like a waste.
I'd be curious to know, at this point, if adding a third 8bit image (8bit glowmap+8bit shinemap+8bit envmap) would be more performance hit than having only 2 images (8bit glowmap+ 32bit shinemap) but with one of them 32 bit (a total of 40 instead of 24 bits).
In other words, my question is if it is better to have each effect (glow, shine, env, and in future bumpmap) on an individual file with the lower number of bits possible, than having more effects on a single file with a number of bit higher that what it'd be needed.
-
It's better to have more effects in a single file. Texture changes are a slow process on modern video cards, and should be avoided.
Yes, there is an 8 bit alpha, 8 bit color texture format, A8R3G3B2. I would disagree, though, and say that the 256 color V textures just don't cut it any longer. User created models continue to get better, but textures need to move into current standards. Even the standard V models would look fairly decent with 1024x1024 textures on them.
-
I think true reflectivity bsicallty requires ray tracing..... i.e. you need to calculate where every ray of light bounces of every surface before you can start to draw.
-
yes that's why this is a cheat reflection
-
Originally posted by Sticks
Yes, there is an 8 bit alpha, 8 bit color texture format, A8R3G3B2. I would disagree, though, and say that the 256 color V textures just don't cut it any longer. User created models continue to get better, but textures need to move into current standards. Even the standard V models would look fairly decent with 1024x1024 textures on them.
I agree on higher size resoltion, but not on color depth... i don't think anyone could notice any visible difference between a plain 256 color texture and a 32bit texture on a freespace fighter...just a waste of video memory imho. Only VERY large textures, such as background, could benefit from the higher color depth.
-
Originally posted by Sticks
Yes, there is an 8 bit alpha, 8 bit color texture format, A8R3G3B2. I would disagree, though, and say that the 256 color V textures just don't cut it any longer. User created models continue to get better, but textures need to move into current standards. Even the standard V models would look fairly decent with 1024x1024 textures on them.
Originally posted by KARMA
But even if it may be reasonable to go for 24bit textures, using more than 8 bits for glows and shinemaps is just a waste imo.
actually I already use more than 8bits for the textures, I was arguing about shinemaps, which I still doubt require an higher color depth than 256 colours.
ppl reported some slowdowns with many highres highbitcount images until they are converted to DDS, I was just afraid by adding more of those files using 32bit shinemaps when you actually don't need all this color depth on them, and I wonder what will happen when you'll have to find 8 addtional bits for bumpmaps.
But if you say that this isn't a prob, well, ok, no prob for me too
-
Originally posted by KARMA
actually I already use more than 8bits for the textures, I was arguing about shinemaps, which I still doubt require an higher color depth than 256 colours.
Of course, and i'm saying that even the stardard texture have very little notieacble difference, on a fighter, if they are high-colour, so having more than 8 bit for shinemaps seem just nonsense to me!
Of course it should be nice to have the ability to decide what color depth to use, so one can chose 8-bit textures or 24-bit textures, so people without uber top-end machines can use the low res ones to improve performance.
-
Enviroment map looks great, but there is a way make it look way better with some tweaking and to get rid of the old ambient.
a proper image based ambient lighting for both diffuse and specular.
specular is actualy just blurred enviroment map. (there is no difference in any calculations)
but addition of diffuse part would be awesome and sould be pretty easy.
it is MUCH blurried version of the enviroment map with texture cordinates taken directly from normals. (not view dependant.)
if you want it to look like movies (and im not kidding.)
add ambient occlusion term. per vertex should be enough and very fast.
.
becouse all maps are pretty blurry there is no need for high res maps. (something like 256x256x6 is already quite overkill for specular and 32x32x6 for diffuse is plenty.)
and becouse we talk about ambient theres no need for HDR. 8bits/channel should be enough.
this method would give the metallic look, not a perfect mirror like normal enviroment map.
some links to explain what is possible.
about ibl and ambient occlusion.
http://www.andrew-whitehurst.net/amb_occlude.html
http://www.debevec.org/IBL2003/
http://www.cs.wisc.edu/~ltokheim/ambenv/
exelent tool for creating maps and for blurriness reference if you want to do maps runtime.
http://www.debevec.org/HDRShop/
-
:welcome:
welcome to the HLPBB, once you're in, you never leave. At least not according to the 5 legged bouncer.
don't crawl through the ductwork, you might run into some Shivans. if you do, hope it's Carl, and give him a snack. If it is Carl, you'll live, if it's not, that's why you signed the life insurance policy for upon entering. Flamethrowers are under seats, but bring your own napalm. Heavier weaponry is locked up front, but you'll need an admin to unlock the door.
anyhow, i don't know much about this code, but what you say sounds awesome. how much work do you think it would be to implement it? would you be willing to?
-
Sadly i'm not very good coder. (yes i have made 'hello world' and i can save x*y moire to hard drive, but not much more)
i'm mostly graphician who loves to read and do research of different algorithms and think how those could be implemented.
to get ambient running shouldn't be very hard now that the enviroment map is up and running.
what would be needed is filttering for enviroment map when it is made to get specular and diffuse maps out of it.
then for the diffuse part the texture cordinate calculations so they wouldn't be view dependant. and change rendering mode from add to mult.
occlusion term would be most of the work but the ambient does get nice boost if its used.