Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Herra Tohtori on March 06, 2010, 03:26:04 pm
-
Since the 2D shockwaves in MediaVP's are of relatively low resolution due to attempts to keep the size within constraints of all common sense, here's something that might interest people who like the 2D shockwaves but prefers 3D shockwaves simply due to their higher resolution textures...
2D-shockwave_1024_U888.7z (http://www.mediafire.com/?nwmwugxzdj2)
2D-shockwave_1024_DXT1.7z (http://www.mediafire.com/?bztkywdgouj)
2D-shockwave_512_U888.7z (http://www.mediafire.com/?hhymeychlmn)
2D-shockwave_1024_U8_greyscale.7z (http://www.mediafire.com/?zomgayijmzm) (due to stupid, nvdxt saved these as dxt5 despite the -u888 flag was used; apparently -greyScale flag superceded the other command line selector... as a result, these will have black boxes and are basically worthless.)
So basically here's uncompressed 1024^2 resolution blue 2D shockwave, compressed 1024^2 shockwave, uncompressed 512^2 shockwave and an interesting experiment, namely grayscale 1024^2 shockwave, which is rather significantly smaller than the U888 version, so unless you definitely want the blue retail-ish hue, this might be worth a try at least.
Feel free to test these and pick the one you like the best, and if you can be bothered to post performance/visual looks feedback, all the better.
(Should probably add that I didn't make these, these are AFAIK the source files from which the current MediaVP versions were rescaled of.)
-
I didn't test this out yet, but don't 1024x1024 effects absellutly kill framerate? at lease thats what happned to me last time I tessted one out... and I have a decent card, a geforce 9600gt...
-
I tried out the grayscale one, it did look pretty good. But why it is in DXT5 instead of DXT1? I suppose DXT1 512^2 would work nicely for the grayscale version. I don't see why a shockwave should have colors anyway, it is a shockwave after all. Only how the shockwave looks could use improvement, mediavps one is somewhat uninteresting.
-
I didn't test this out yet, but don't 1024x1024 effects absellutly kill framerate? at lease thats what happned to me last time I tessted one out... and I have a decent card, a geforce 9600gt...
not really. maybe animated 1kx1k effects or larger, but it shouldnt unless it starts occuring... everywhere at the same time. (yes, i have a 9600GT too, best damn cheapass card ever bought, in my gf's pc, used it before i got a GTX260, 216sp version)
on the other hand, trails tend to kill performance in a horrible horrible manner if too many are on screen at the same time.
@herra, i'll test these out later, got any reccomendations for some... "benchmark"-ish thing to test performance with?
-
I tried out the grayscale one, it did look pretty good. But why it is in DXT5 instead of DXT1? I suppose DXT1 512^2 would work nicely for the grayscale version. I don't see why a shockwave should have colors anyway, it is a shockwave after all. Only how the shockwave looks could use improvement, mediavps one is somewhat uninteresting.
Dunno. I used the command line
nvdxt -file *.tga -greyScale -nomipmap -u888
...so it looks like -greyScale option automatically forces the output into dxt5. Wasn't expecting that to happen. :rolleyes: It does explain why the filesize is smaller than expected, though.
-
not really. maybe animated 1kx1k effects or larger
hmm and a shockwave effect is not animated?! :P
anyway I'm just speaking from experiance, I once made a HUGE explosion for Diaspora, 250 frames at 1024x1024 :P the framerate died :D
-
why the tapdancing sweet**** would you need a 250 frame animation :wtf:
of course it kills framerate when its more than... 20-80 frames. eh.
-
of course it kills framerate when its more than... 20-80 frames. eh.
thats stupid, whats the difference between 80 or 200 frames? it still plays it one frame at a time, if should drain the fps in the same way just for a longer period of time...
the 250 frames animation was a test, as I stated above, and what to do, if you want long lasting explosions it just can't be done with 20-80 frames, that just dosn't work...
-
First thing that comes to mind is that if all the assets don't fit into system ram the game will have to start using the pagefile...
-
of course it kills framerate when its more than... 20-80 frames. eh.
thats stupid, whats the difference between 80 or 200 frames? it still plays it one frame at a time, if should drain the fps in the same way just for a longer period of time...
the 250 frames animation was a test, as I stated above, and what to do, if you want long lasting explosions it just can't be done with 20-80 frames, that just dosn't work...
*facepalm*
first of all, learn how the game allocates the memory for the damn things. if an animation has 250 frames, all of the 250 frames are in the memory the whole time the object that uses them is in the mission. now, combine that with other memory intensive things, other textures and models, etc etc etc, and consider the general state of "optimisation" of the engine, there are some limits.
read this (http://www.hard-light.net/forums/index.php/topic,37158.0.html), even tho the post is 4 years old almost, it is still very relevant, as i do not believe that much has changed in the parts that taylor describes.
Yes, hardware has improved vastly in the last 4 years, but FSO wasnt exactly optimised back then for that era's hardware, and its certainly not optimised for todays hardware.
as for longer lasting explosions, make more of em spawn at once, use lua for finer control of explosions, etc etc etc. using extremely long animated maps is just asking for trouble and/or a sign of extreme lazyness of the artist to try something else.
if you are interested in the lua approach, i'd reccomend wanderer's flashy death scripts as a base for your own attempts.
as an aside note, as a 32-bit application, freespace 2 cannot use more than 2 gigabytes of memory at one time. page file and physical adress extensions and other "memory availibility extenders" do not matter at all
@Herra, not really. only if the amount of stuff it loads exceeds the amount of availible system ram. when you hit the pagefile, what happens most often is as follows: your hard disks starts revving a lot, your cursor get sluggish like hell, and heavens help the app that caused the pagefile hit. (note, for fs2 to hit the pagefile you have to already be doing something insane on your system already, or be really lazy when it comes to keeping spyware and background programs in check :p (applies to any system with more than 2 gigs of ram)
it tends to happen to me on a 64 bit system with 4 gigs of ram when i try to render anything with insanely detailed displacements :p
an aside question, more out of interest than anything else, are normal maps animatable?
-
@Herra, not really. only if the amount of stuff it loads exceeds the amount of availible system ram. when you hit the pagefile, what happens most often is as follows: your hard disks starts revving a lot, your cursor get sluggish like hell, and heavens help the app that caused the pagefile hit. (note, for fs2 to hit the pagefile you have to already be doing something insane on your system already, or be really lazy when it comes to keeping spyware and background programs in check :p (applies to any system with more than 2 gigs of ram)
Consider that WinXP 32bit is designed to allow any process to only use 1.5 GB of RAM...
an aside question, more out of interest than anything else, are normal maps animatable?
Yes, they are.
-
well, 256x256 DXT1 effects, lasting 170 frames take 5.5 mb of memory... is that soooo bad? I've read the thread, and honestly I believe 4 years makes alot of it irrelevant... just looking at Diaspora for example, 100k tires models, multiple 2048x2048 textures... 5.5mb of memory for an effect that you see more times then some of these models is acceptable IMO, correct me if I'm wrong :)
-
@Herra, not really. only if the amount of stuff it loads exceeds the amount of availible system ram. when you hit the pagefile, what happens most often is as follows: your hard disks starts revving a lot, your cursor get sluggish like hell, and heavens help the app that caused the pagefile hit. (note, for fs2 to hit the pagefile you have to already be doing something insane on your system already, or be really lazy when it comes to keeping spyware and background programs in check :p (applies to any system with more than 2 gigs of ram)
Consider that WinXP 32bit is designed to allow any process to only use 1.5 GB of RAM...
even worse when considering things altogether. under 64 bit os your 32 bit apps can use up to 2 gigs of ram. if you are lucky.
an aside question, more out of interest than anything else, are normal maps animatable?
Yes, they are.
thanks :)
well, 256x256 DXT1 effects, lasting 170 frames take 5.5 mb of memory... is that soooo bad? I've read the thread, and honestly I believe 4 years makes alot of it irrelevant... just looking at Diaspora for example, 100k tires models, multiple 2048x2048 textures... 5.5mb of memory for an effect that you see more times then some of these models is acceptable IMO, correct me if I'm wrong :)
a bit by bit and whuuuop, slowdown.
the problem is not in a single effect, its in the fact that every damn thing stacks and has vast potential to make everything go *poof*
and no, that thread is still very, veeery relevant. just because its 4 years old doesnt invalidate it.
also, no, i will not look at diaspora as i have no interest in yer freaking toasters or however you call it :p
-
well, 256x256 DXT1 effects, lasting 170 frames take 5.5 mb of memory... is that soooo bad? I've read the thread, and honestly I believe 4 years makes alot of it irrelevant... just looking at Diaspora for example, 100k tires models, multiple 2048x2048 textures... 5.5mb of memory for an effect that you see more times then some of these models is acceptable IMO, correct me if I'm wrong :)
Yes, a single effect takes not that much memory. But, as pece said, things stack. Since the game has to keep a copy of the effect in memory for each instance of that effect, those 5.5 MB effects can eat your video memory really quickly. A single big model that uses a few huge UV-maps is comparatively easy to deal with. After all, how many Basestars or Galacticas are there going to be in a sane mission? And how many Flak explosions, for example?
EDIT: Disregard this. It is wrong. Read VA's answer a few posts down for the truth.
-
Your biggest enemy when creating long animations is not the total memory available, the speed FSO can render the frames or stuff like that - it's bmpman. Every image file used by the game is loaded into bmpman including effects, glows, backgrounds, textures, interface art, and the rest, and the problem is that bmpman only has a finite number of available slots (4750), and when you run out AFAIK it just starts from the beginning - overwriting the textures it has already loaded, and you can imagine the problems that causes pretty easily. ;)
So no you're correct that a 170 frame, 256 res explosion won't eat all your memory and won't murder your FPS, but it WILL eat a sizable chunk of available texture slots. For this reason animated glowmaps are pure evil too. There are 1631 of the damn things in total - a third of the total available slots not counting anything else, and I bet if you had one of each animated glowmap ship in a mission, you'd break the bmpman limit very quickly. Once we have a material system we'll be able to achieve equal or better results than the animated glowmaps using other techniques (such as masks and maths) and once replicated or improved upon, I intend to pull the whole lot out for good. :)
I reckon animations in general should be used as sparingly as possible, and the animations that are necessary to create a particular effect should be as short as can be gotten away with.
Edit: The E, no as far as I'm aware you have one copy of the effect in memory - each frame is stored in bmpman and called when necessary by the various instances of the explosions.
-
4750? :wtf: Oh boy...
-
Yeah - it's a very scary number for anyone who's say, even glanced at the bazillion files necessary to display the silly interface. ;)
-
@VA: Gotcha
As for the interface, that one uses roughly 1100 images. Say goodbye to those slots....
-
Your biggest enemy when creating long animations is not the total memory available, the speed FSO can render the frames or stuff like that - it's bmpman. Every image file used by the game is loaded into bmpman including effects, glows, backgrounds, textures, interface art, and the rest, and the problem is that bmpman only has a finite number of available slots (4750), and when you run out AFAIK it just starts from the beginning - overwriting the textures it has already loaded, and you can imagine the problems that causes pretty easily. ;)
I can not only imagine the problems it may cause, but I actually experienced them.
I don't know if it belong here, but I think that this limit should be seriously bumped, becasue after replaying a large mission with Steve-O's ships in it (there's a couple of missions in WiH that fit this description, but I got it even on Forced Entry after a lot of replays) a couple of times, it ussualy runs out, resulting in FPS drop and texture corruption.
It would be great if something could be done with it.
-
Thanks for the clarification Vasudan Admiral... it works then more or less how I thought it did, and as I said in earlier threads, the FSU should consider what it best for it, stupid animated glow maps, or nicer explosions/effects that you get to notice much more...
also, for the same reason, I feel free with Diaspora, as there is absolutely no animated glow maps :P the limit will be hard to reach even with 10 explosions lasting 170 frames each(don't worry, most are more reasonable, from 60-120 frames)...
The E: if I'm not mistaken, the interface stuff, as well as the animated CBanims don't count to the total frame limit, only stuff that loads at the beginning of the mission, as in effects, diffuse, shine, and normal maps...
pecenipicek: you'r loss :P
-
Any image - including those in the interface is loaded into bmpman. I'm not sure about .ani files though, and I also don't know about where or when images are unloaded - especially in regards to interface files. Hopefully that's done efficiently but it may well not be.
As for what the FSU does with animated glowmaps - from memory I don't think anyone on the team thinks they're worth the performance hit they cause actually. :p
Hence the add-on VP to 'abolish' them. I doubt they'll come out entirely due to their widespread popularity until we can provide an equal or better alternative method via a material system.
-
I don't think anyone on the team thinks they're worth the performance hit they cause actually. :p Hence the add-on VP to 'abolish' them.
Shouldn't this be reversed?
-
Hmm, IIRC it was kept in the main one to make things as simple as possible to install (especially with MV_Complete), but since then the MVPs have become download-separately anyway so putting the animated glows in their own VP would probably be more ok for the next release.
-
even worse when considering things altogether. under 64 bit os your 32 bit apps can use up to 2 gigs of ram. if you are lucky.
hi,
under windows x86 (XP, vista 32 bit and so on), each application has a address-space of 2 gigs.
thats not limit to the installed ram, if you have 1 gig ram installed, the application, can still address 2 gigs of address-space.
under windows 64, is the same, only if the application has flag with the "large address flag". then the application can use the full 32 bit address-space of 4 gigabyte and if you have installed 4 gig or more of ram, the application can then use then 4 gigabyte of the ram for theres data.
why its limit until 2 gig address room in windows 32 bit?
because the rest is reserved by the operation system to mapping in the graphic-card and so on.
but man can chance the reserved in the boot.ini so that the system only reserved 1 gig of the address space, for example (you can type i a amount of the address-space which has to be reserved for the operation system, but less a 1,5 gigabyte for the operation system isnt really good).
the problem is, if you limited the system to 1 gig address-space you get trouble with the drivers and the system didnt work or get instable.
Mehrpack
-
pecenipicek: you'r loss :P
Excuse me, but how was i wrong? Its still a bad idea in my opinion, and now you just got tons of better explanations as to why its a relatively bad idea.
@Mehrpack: what you said.
Also, PAE sucks :p
(hint, just move the quote tag to the end of my quote, it'll be abit more readable...)
Hmm, IIRC it was kept in the main one to make things as simple as possible to install (especially with MV_Complete), but since then the MVPs have become download-separately anyway so putting the animated glows in their own VP would probably be more ok for the next release.
Arent the animated glows in the advanced part anyway?
To tell you the truth, i kinda like the animated glows on the SF Mara and SD Ravana. In my opinion, one of the better uses of animated glows.
But actually, i do support separating them to another VP, if it wont be too much of a hassle.
-
[...]
@Mehrpack: what you said.
Also, PAE sucks :p
(hint, just move the quote tag to the end of my quote, it'll be abit more readable...)
[...]
hi,
yeah, so really, had make more trouble as solved really problems.
thanks, total oversee that i forget to close the quote *g*
Mehrpack
-
pecenipicek:
So no you're correct that a 170 frame, 256 res explosion won't eat all your memory and won't murder your FPS, but it WILL eat a sizable chunk of available texture slots.
eat a chunk of texture slots, witch I have plenty to spare, so its not such a bad tradeoff IMO, as I said, its not like ALL effects are 170 frames...
and by you'r loss I was refering to you'r comment: "also, no, i will not look at diaspora as i have no interest in yer freaking toasters or however you call it"
-
pecenipicek:
So no you're correct that a 170 frame, 256 res explosion won't eat all your memory and won't murder your FPS, but it WILL eat a sizable chunk of available texture slots.
eat a chunk of texture slots, witch I have plenty to spare, so its not such a bad tradeoff IMO, as I said, its not like ALL effects are 170 frames...
your loss :p
and by you'r loss I was refering to you'r comment: "also, no, i will not look at diaspora as i have no interest in yer freaking toasters or however you call it"
then quote properly you muppet :p
-
I would agree with Nighteyes that dedicating a reasonable chunk of slots to such widely used effects is a good idea. Unfortunately while the animated glowmaps are still lurking taking up a decidedly unreasonable chunk, we can't so easily do that. :\
-
perhaps a poll should be posted, regarding moving the animated glow maps into an optional VP, while the normal mediavps don't use them, or just use them on specific parts(like the nice ravana tubes)... this won't only give some breathing space regarding new effects, but will also allow the usage of more ship diversity in mission :yes:
-
mv_advanced... it was made for a reason.
-
mv_advanced... it was made for a reason.
Umm, sigtau, the question is not whether animated glowmaps or large effects are materail for mv_advanced or not. It's about one of the most fundamental engine limitations. Consider this: There is a fixed budget of 4750 bitmaps the engine can have loaded at any given time. You can't go over it, and going even near it can lead to strange things. Now, imagine what happens if someone builds a mod based on the mediavps. How many bitmap slots are available?
-
perhaps a poll should be posted, regarding moving the animated glow maps into an optional VP,
...snip...
That won't be necessary. The poll that is. As it will already be happening exactly that way. Advanced will still be Advanced, with animated effects and the animated ship-maps will be separate (Which will then cause for MV_Abolish to be abolished as it won't be needed anymore).
Hopefully, we'll also be able to container all of the animated effects into a per-effect container. I had also thought about a really old trick from Win98 days to have animated BMP's in the boot screen, where you have a single static frame, and then color code to "animate" it. For a basic ship animated glowmap, we still have a few more options before we have to start looking at the model format. My guess is though that POF is running out of room and durable expansion.
-
A few years ago Bobboau prototyped a material system that looked really really promising. You could only do ship-wide material effects but I had loads of fun plugging different sine waves into the RGB values for the glowmaps and creating a disco on an arcadia. :p
I mean, that's really all a lot of the animated glowmaps do now - they take 30-90 frames to just pulse in brightness. That kind of thing is piss easy with the simplest of material systems, but if you added masks, texture translation, rotation etc (of the mask in particular) you could get some very sweet effects for the footprint of 2 or so frames compared to a 60 frame animation.
A more complete implementation could also allow you for example, to remake and even improve those shivan animated effects where the red stuff just shifts back and forth between 2 'forms', you could do things like crossfades between two (or more!) glowmaps to achieve the same effect. For stuff like the rippling flow on the ravana pipes, a translating brightness mask would work perfectly. You could make the lights on a ship flicker and fail sporadically when it's about to die like this: http://s5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cutscenes/?action=view¤t=FenrisGlowDie.flv
The possibilities would be endless!
-
Endless indeed. You could pretty much do the same for a normal map, simulating (for example) a surface of water with multidirectional waves interfering each other... :drevil:
-
A few years ago Bobboau prototyped a material system that looked really really promising. You could only do ship-wide material effects but I had loads of fun plugging different sine waves into the RGB values for the glowmaps and creating a disco on an arcadia. :p
I mean, that's really all a lot of the animated glowmaps do now - they take 30-90 frames to just pulse in brightness. That kind of thing is piss easy with the simplest of material systems, but if you added masks, texture translation, rotation etc (of the mask in particular) you could get some very sweet effects for the footprint of 2 or so frames compared to a 60 frame animation.
A more complete implementation could also allow you for example, to remake and even improve those shivan animated effects where the red stuff just shifts back and forth between 2 'forms', you could do things like crossfades between two (or more!) glowmaps to achieve the same effect. For stuff like the rippling flow on the ravana pipes, a translating brightness mask would work perfectly. You could make the lights on a ship flicker and fail sporadically when it's about to die like this: http://s5.photobucket.com/albums/y184/VA--Twisted_Infinities/Cutscenes/?action=view¤t=FenrisGlowDie.flv
The possibilities would be endless!
THIS!
Also, as a side question, wouldnt this be possible already if we could assign shaders on a per-ship basis and with some fancyful render-to-texture stuff? (especially for animated normalmaps :p
-
Thanks for the clarification Vasudan Admiral... it works then more or less how I thought it did, and as I said in earlier threads, the FSU should consider what it best for it, stupid animated glow maps, or nicer explosions/effects that you get to notice much more...
also, for the same reason, I feel free with Diaspora, as there is absolutely no animated glow maps :P the limit will be hard to reach even with 10 explosions lasting 170 frames each(don't worry, most are more reasonable, from 60-120 frames)...
The E: if I'm not mistaken, the interface stuff, as well as the animated CBanims don't count to the total frame limit, only stuff that loads at the beginning of the mission, as in effects, diffuse, shine, and normal maps...
pecenipicek: you'r loss :P
:wtf: eyes of a Cylon? Unless you do it differently...
-
:wtf: eyes of a Cylon? Unless you do it differently...
well, yes there is that one, but its a tiny effect, so I don't count it :P
what about rippling normal maps for shield impacts? :D
-
wouldnt work properly. would be nice to see, but i really doubt you can do anything with the shield regarding textures honestly...
-
If given a way to tell if the shields have been struck, then about the best you could do with the kind of material system described would be to have the whole shield shimmer. For anything more advanced you'd need to be forming systems that project certain effects onto the shield when needed, or perhaps a poor-mans UV projection system would involve the modeller unwrapping the shield mesh onto a 'shield texture', and somehow working out where on the texture space the strike occurred and passing that on to the material system to draw whatever effect was supposed to occur.
There'd be a seam though, since if the shield texture was stuck near an edge, it wouldn't neatly wrap around to the other side of the map....
Yeah that kind of location-variable effect would be quite difficult. :\
-
If given a way to tell if the shields have been struck, then about the best you could do with the kind of material system described would be to have the whole shield shimmer. For anything more advanced you'd need to be forming systems that project certain effects onto the shield when needed, or perhaps a poor-mans UV projection system would involve the modeller unwrapping the shield mesh onto a 'shield texture', and somehow working out where on the texture space the strike occurred and passing that on to the material system to draw whatever effect was supposed to occur.
There'd be a seam though, since if the shield texture was stuck near an edge, it wouldn't neatly wrap around to the other side of the map....
Yeah that kind of location-variable effect would be quite difficult. :\
quasi-volumetric shaders on the other hand... where the shield mesh would only define the outer boundary to which the shield effect would extend and inside it would be a "sphere" made of (for example only, not that experienced with shaders) particles which would react to hits. the seam wouldnt really matter that much if using the uv map for example.
-
Shaders would be the logical way to do this - all you need is the mesh itself, plus the location of the impactor.
- In fact, there's a lot of very nice things one could do with a shield shader if you pass the vector, size (maybe even a texture) for the impactor.
'Splash' across the shield could be changed depending on the angle of impact of the weapon - glancing blows could easily look different to straight-on blows, you could 'bend' the shield as well (GFX only, *not* collision), and maybe even use a different kinds of splash depending on the weapon.