[Herra Tohtori]

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
2D-shockwave_1024_DXT1.7z
2D-shockwave_512_U888.7z
2D-shockwave_1024_U8_greyscale.7z (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.)

[Nighteyes]

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...

[Fury]

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.

[pecenipicek]

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?

[Herra Tohtori]

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. It does explain why the filesize is smaller than expected, though.

[Nighteyes]

not really. maybe animated 1kx1k effects or larger

hmm and a shockwave effect is not animated?!
anyway I'm just speaking from experiance, I once made a HUGE explosion for Diaspora, 250 frames at 1024x1024 the framerate died

[pecenipicek]

why the tapdancing sweet**** would you need a 250 frame animation


of course it kills framerate when its more than... 20-80 frames. eh.

[Nighteyes]

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...

[Herra Tohtori]

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...

[pecenipicek]

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, 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 (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




an aside question, more out of interest than anything else, are normal maps animatable?

[Herra Tohtori]

@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 (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.

[Nighteyes]

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 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

[pecenipicek]

@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 (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 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

[The E]

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 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.

[Vasudan Admiral]

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.

[Fury]

4750? Oh boy...

[Vasudan Admiral]

Yeah - it's a very scary number for anyone who's say, even glanced at the bazillion files necessary to display the silly interface.

[The E]

@VA: Gotcha


As for the interface, that one uses roughly 1100 images. Say goodbye to those slots....

[Dragon]

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.

[Nighteyes]

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 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