Hard Light Productions Forums
Community Projects => The FreeSpace Upgrade Project => Topic started by: Shadow0000 on March 10, 2006, 01:56:50 am
-
I was seeing that DaBrain Shockwaves uses 804 polys, it may not be much, but when there are lot of Shockwaves there is always a slowdown in most system, maybe a little maybe too much (if you have played INF you know what I mean).
My question is, why in exchange of using those polys, why don't make a Planar Square model using Alpha Channel Textures, the DDS version of DaBrain are DXT5, so they already have an empty alpha channel (32 bits depth).
Here is what I mean, seems logically and totally possible (and even better really easy), this is a model of White Dwarf (actually the White Dwarf needs to be added):
(http://i29.photobucket.com/albums/c254/Shadow0000/3D_Shockwave_Idea.jpg)
It could have a problem, I don't know if the FSSCP support Multiple Alpha Channels, I have tried with the TGA but it didn't work, maybe it works with DDS. Anyways even with a Binary Alpha it would look good.
The only thing that could ruin this, is that the collision of a Shockwave vs. Ship is managed by the Radius of the Model Shockwave, in this case a square won't work, I don't believe it is calculated that way....
------------------------------------------------------------
If this is so stupid please let me notice, because it I can't, it seems too perfect to be a idea that works...
-
Thing is that it's not the number of polys causing the slowdown. It's the number of textures. Using the alpha would mean bigger (or same sized - I forget which it is) textures and thus wouldn't cause any speed up at all.
-
Never mind that if you're going planar you really should be falling back to 2d anyway. There is no instance where a 2-polygon shockwave will EVER look better than the bitmap ones.
-
Certainly an interesting idea, though. 'Tis always nice seeing ideas brought to the table. :)
-
Thing is that it's not the number of polys causing the slowdown. It's the number of textures. Using the alpha would mean bigger (or same sized - I forget which it is) textures and thus wouldn't cause any speed up at all.
Same Size, DXT5 are 32 Bit Alpha Textures, it saves the Alpha even if you don't want that channel, it should be the same size and memory usage. For that there are DXT1 and DXT3 textures.
I know the Textures are the one exausting the RAM, but DDS use MipMaps, while the Model of the 3D Shockwaves are just Detail-0, that means 804 polys for every Shockwave even at unseen distances. I am sure that in INF (and others), as an example we get up to 6 shockwaves for ship simultaneus and with a Wing of 6 Ship, we get 6 x 6 = 36 simulateous Shockwaves, with just LOD0 it is just 28944 polys, that's only per 1 Wing of Bomber if there were even more Wings (which happens), , that's a good number compared to FS2 Campaing...
I don't really know how Alpha is managed by SCP, because I can't get any Alpha to work for Texture Maps, not even Binary Alpha. For Backgrounds it works totally OK, as it should be, but for Models it works different, I can't really figure how....
Never mind that if you're going planar you really should be falling back to 2d anyway. There is no instance where a 2-polygon shockwave will EVER look better than the bitmap ones.
This simple Model just has 12 polys.
A Model rotates and has an unfixed position for Shockwaves, a Bitmap is Static it doesn't rotate or anything, the viewpoint is always the same. The difference is clear...it seems that EVER just means EVER when your affirmation is not wrong (2D Earth Background have frequently more quality and colours than a 3D Model)
------------------------------------------------------------
The Main case, is this, a Square Planar model can't be seen from Left / Right / Botton or Top view, it is planar, the problem is that the Shockwaves made by DaBrain doesn't have a real texture from those sides, so at the moment it would be the same, I mean, have sometime a Shockwave hit you from one of those points ?, you should see two lines just 2 lines, it happens with the actual Model of Dabrain, it's is rare and not so...in exchange of see that we should see a Explosion (Blue, etc.) wall coming over to us, but at the moment that can't be made, with a Planar square model that would be totally 100% impossible to be made.
So, actually both could have the same graphical quality, I don't really see too much difference
-
Shadow's quite right on most accounts actually. You could indeed produce an identical shape of shockwave with a 2d plane as opposed to the 3d model currently being used - though you'd need to use a minimum of 16 polys on it. ;)
The reason? If you look at the animation DaBrain created, (the frames themselves, not the spectacular end result), you'll notice that the shockwave is expanding out from the corner, and only a quater of the shockwave is actually drawn at any time.
It works like this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Shockwaves1.jpg)
Basically, the projection of the animation onto the model remains the same throughout the sequence - the expanding motion we see is caused by the animated shockwave itself growing relative to the model. It is not only because the model is expanding.
(though it should be noted that the model is actually expanding throughout this, which is why they were originally much faster than normal shockwaves).
So really, the model itself is acting just like an expanding 2d plane for the shockwave animation anyway! ;)
All that would be needed to make it more efficient is to create two quatered planes stuck together. It would have the exact same look as the 3d model, with the possible difference of there being less distance between those twin parallel shockwaves we see with the current model. (to create a single shockwave, you'd just create a single quatered plane - I think they're visible from both sides)
The problem with 3d mesh based shockwaves is this:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Misc/3D_Shockwaves.jpg)
From some angle, you will always see a horrible hard edge. There's not really a good way around it other than particle based effects.
In regards to the alpha mapping, it's automaticly done on all effects - which is why you don't see dark outlines around them. ;)
-
Yeah. We don't have the capability to make our shockwaves look like the ones that Industrial Light and Magic makes for movies like the Star Wars: A New Hope update or Star Trek VI.
-
Karajorma is right. The poly count doesn't really matter. The maps are the problem. A problem with two parts. First part is the loading, which causes slow-downs on some machines and the second problem is the total ammount of used memory.
So it comes at a cost. The High-End version works just fine for me, but for anyone with slower and even with a faster PC, I got additional versions.
A flat plane... well I know many people do not like the dual layer shockwave, but trust me, it's a good idea. The shockwaves appear with random angles and a flat plane looks just flat from the side. -> Very ugly.
Using two layers minimizes the problematic angles. And they are not 100% flat. So the problem isn't completely fixed, but at least you won't see it very often anymore. For a complete fix, we'll need either a code change that limtes the possible angles, or shaders.
-
Karajorma is right. The poly count doesn't really matter. The maps are the problem. A problem with two parts. First part is the loading, which causes slow-downs on some machines and the second problem is the total ammount of used memory.
So it comes at a cost. The High-End version works just fine for me, but for anyone with slower and even with a faster PC, I got additional versions.
A flat plane... well I know many people do not like the dual layer shockwave, but trust me, it's a good idea. The shockwaves appear with random angles and a flat plane looks just flat from the side. -> Very ugly.
Using two layers minimizes the problematic angles. And they are not 100% flat. So the problem isn't completely fixed, but at least you won't see it very often anymore. For a complete fix, we'll need either a code change that limtes the possible angles, or shaders.
That's what I was trying to get at. I still prefer 2D because shockwaves should be spherical in space (the Praxis effect as it's called has always bothered me, to be honest) and the only way to make that work without shaders is to use a map that always faces the player in the same way. There are downsides, yes. But it's still the most practical way to do it especially if you're quibbling over polycounts, and it avoids the edge problem entirely.
-
How'bout a solution where you have a single expanding map always facing the player AND a separate spreading ring of fire that has an angle of max 60 degrees compared to the main plane?
-
A flat plane... well I know many people do not like the dual layer shockwave, but trust me, it's a good idea. The shockwaves appear with random angles and a flat plane looks just flat from the side. -> Very ugly.
Actually the image I post above it's not a planar single layer, it has 2 layers as the shockwave model has. I know when you see a shockwave, most times you see 2 the a lower and a upper one. So we should see something very much like it.
My machine can afford even the Super-High End Shockwaves (OpenGL Mode, mostly), but since I see this tech for used for a White Dwarf, I believe it could be interesting (it's unreal I know, but the player should not see the difference).
----------------------------------------------------------
This is not really related, I just wanted to report it, but I take this idea from Celestia, a program that simulates the Solar System mostly (uses OpenGL), it uses *.TGA and *.DDS Textures (and others), it also supports multi-Alpha channel textures, Bump, Normal and Specular Level maps (shaders, etc.)
I don't know if this will help, but if someone found this useful (want to try to port some of the mapping code for the SCP mapping), Celestia is Open Source writted in Visual C++, the page of the source is here
http://sourceforge.net/projects/celestia
-
Technically any format that FS supports that can have alpha transparency will use it, more or less. The trouble is the polygon ordering is not as robust because the rendering system was not originally designed for transparency and so you can have transpartent polys obscure non-transparent ones. This is a fairly major issue with cockpits, and it's something I've had to deal with numerous times. In theory it's supposed to be getting some attention, but I don't know how far Bob's gotten with the material system.
As an aside, the trouble with fixing the angles in which shockwaves can generate is that you cannot provide any assurance that the minimum angle that you set will be maintained through the duration of the shockwave's existance. In fact, no matter how you set it up, I can still produce a screenshot that will show the shockwave at a hard angle that is very much non-optimal. As for using both, I think everyone dev-side will shoot that one down in a heartbeat, as shockwaves are already the single leading source of texture map memory usage and adding a second map to that equation (2D plus the one for geometry) would be fairly universally condemned, just on performance concerns. But ultimately I stand by the insistance that there is absolutely no way you can make a shockwave with a box model that looks good from many angles (or at least doesn't scream "I'm 4 polygons!") from most angles.
-
Well, my currently-weird net connection swallowed my post..... :(
My whole point was that the current model being used to render shockwaves onto isn't all that efficient, since the shape of it is having absolutely no bearing on the appearance of the shockwave other than having two layers.
If you were to replace the current 800 poly rounded shockwave-shaped model with a better version of this 16 poly shape, you would have a result almost identical in every way to what we currently have:
(http://i5.photobucket.com/albums/y184/VA--Twisted_Infinities/Shockwaves2.jpg)
(side on they'll still both look silly though, as seen above. :\ )
HTL or not, if you're not even able to see those 800 polys on something so commonly used like the shockwave, there's not really a good reason to have them there. ;)
Allmost all the pure awesomeness of the current shockwaves comes from the map, not the model, since the model is acting exactly like a dual layered plane anyway! The roundness of it is just unnessecary. :)
(and by 2d plane I mean a 3d modeled object, not the mechanism Strat's referring to, where the plane always faces the player)
-
Yah, I always thought that I had a pretty high end computor. Pentium 4 1gig of ram, 256mb graphicscard Nvidia 5400 (or was it 5200, oh well) In anycase, whenever a single shockwave appears, weather it be from a bomb or a ship exploding, my computor will slow down to a crawl. And if its 5 bombs that blow up a ship, well you can guess. There should at least be a flag that can choose between 3d shockwaves or 2d. Quite frankly I think Vasudan Admiral's concept would be fine, and seems very realistic enough for kind the technology that most people have. (most of us dont have Think Blues and HAL 5000 in our closets) There is no point In having a massive 800 polygone shockwaves with TGA textures, or what ever, if you can't see it trough the slideshow. And If my computor is better than most and is still expieriencing this diffulculty, then I guess most, will have to sit trough the slide show, which in the longrun will hurt SCP popularity.
-
Well, that shouldn't be happening at all - the number of polys used in it - even at 800, only ammounts to a tiny difference in performance untill you have a very large number of them at once, since HT&L is so blindingly fast at rendering polys.
More likely you have the super high end shockwaves installed - check for a .VP file named "mv_adveffects" in your main FS folder, and move or delete it if you find it.
If that isn't the case, try using one of DaBrains lower res versions as Shadow posted here: http://www.hard-light.net/forums/index.php/topic,38016.0.html
-
256mb graphicscard Nvidia 5400 (or was it 5200, oh well)
Oh... I guess there is the problem. The 5200 is a really slow card. Even slower than many older cards (like the 4600 and the 4800).
Also many 256MB versions have slower ram, to keep the costs low for this low-end card, so you'd be better of with a 128 MB version.
If your P4 got more than 1,5 Ghz, you should really start looking for a better gfx card.
-
I have an A64 3500+, 1gig of Ram, X550 Radeon.
With me it's a little different. The FPS slows to a crawl (and by crawl, I mean 1/2 second 2 FPS) only with the first four or five explosions and then all the rest of the explosions work fine after that.
I gather they need to be written to memory or something first, and then after the game can quick-read them or something, they cease to be a problem.
Weird ****.
-
Again a really slow GFX card.
The X550 is a refresh of the X300, which was a low-end card. You can't use the high-end versions of the shockwaves with these cards. They can't handle it.
The mid-quality version needs a gfx card with at least the power of a GF4 TI, GF FX 5700 or Radeon 9600 Pro.
-
I wish my laptop vid card had HTL support. :(
-
My Celeron D, 512MB computer with a ATI Radeon 9250 (PCI :mad:) card handles most of the normal effects pretty well, but tends to slow down to 20 fps whenever a 3D shockwave appears. I know I don't have a high end card, to say the least, but I think a more available lower end shockwave (included in the baseline media VPs) might be in order, because many peoples systems don't really seem up to it.
-
It's too easy to change anything in the MediaVPs.
Just download this small file:
http://www.game-warden.com/starfox/Non_SF_related_stuff/SW3D_Low-End_blue.rar
And up the "data" folder in your FS2 root directory. Just 'replace' the exsisting data folder.
The low-end version is really awesome. I think it looks really nice, while it needs a lot less memory than the stock effect. It's my most efficent effect. ;)
-
If you're using a mediavps folder you should put that in medavps\data instead BTW.
-
I have an A64 3500+, 1gig of Ram, X550 Radeon.
With me it's a little different. The FPS slows to a crawl (and by crawl, I mean 1/2 second 2 FPS) only with the first four or five explosions and then all the rest of the explosions work fine after that.
I gather they need to be written to memory or something first, and then after the game can quick-read them or something, they cease to be a problem.
Weird ****.
I happen to have the X300, and I just usually end up slogging through those first few shockwaves. The beauty of that high-end shockwave is worth the rampant slowdown created by the first few 'splosions. :)
-
Freakin' broken search, I knew those were somewhere I just didn't know where... thanks.
-
Again a really slow GFX card.
The X550 is a refresh of the X300, which was a low-end card. You can't use the high-end versions of the shockwaves with these cards. They can't handle it.
The mid-quality version needs a gfx card with at least the power of a GF4 TI, GF FX 5700 or Radeon 9600 Pro.
Are we talking about the same thing here though? As much as I'm aware, the PCI-E X300-550-800 versions are way faster than any AGP Radeon 9600pro or GF FX 5700.
What are we talking about when it comes to the "high-end" shockwaves? 7800GT? X1900?
-
I think this question would go quite nicely into this thread...
Is there a way to get 2D shockwaves to be used instead of 3D shockwaves when mediaVPs are in use? Other than removing the 3d shockwaves from mediavps and all data folders? I tried to set the 2d shockwaves with $Shockwave name: field and end result was that according to the FS.log 2d shockwave was loaded (eff ani) but 3D shockwave was shown ingame instead.
-
personally, I think that the shockwaves in the mediavps are too high. They should be replaced by the mid range shockwaves, which look almost as good (in combat, it's really hard to tell the difference anyway) and they're much faster on a wider array of cards. Then, those of us with higher end cards can always add the high or super high end ones in.
-
Ok, something has to be wrong here - if you total up the file sizes of all the frames in the shockwave, it ammounts to a mere 5mb. Considering many effects and other textures have a considerably larger memory footprint, and will thus be harder to swap in and out of video memory, there is something else at work here. There are just too many people with machines that should be easily capable of handling the shockwave effect having problems with it. :\
I'll do some digging today and try and figure out what in the world is going on with them.
-
Problem is that in order to play the shockwave, all of the frames must be paged in at once, and 5MB is a little more than you usually want to be paging in. Actually what I suspect is happening (as it only happens the first couple of times the shockwaves play, maybe just the first) is that the game simply has not loaded those frames yet at all and it has to retrieve them from disk. That's going to be slow, no matter how small the files are.
-
Are there similar pauses when a ship with a big 2048 res texture warps in? I don't recall hearing about any, but if not, why not?
-
One file as opposed to 128? Remember that each frame of an EFF is a discrete file on the disk.
-
@Wanderer: Unfortunately not with current builds. I added something in CVS that will do it if you use "$Shockwave model: none". Untested, but it was simple enough.
@Vasudan Admiral: How large is your video card memory? 5 MB could be quite a bit when you consider all the other ship textures and effects onscreen. Remember that all the HUD textures must be in memory, plus background, plus ships, and all of that will be stored in uncompressed 24-bit (or 16-bit?) PCX, unless they are DDS to begin with.
-
personally, I think that the shockwaves in the mediavps are too high. They should be replaced by the mid range shockwaves, which look almost as good (in combat, it's really hard to tell the difference anyway) and they're much faster on a wider array of cards. Then, those of us with higher end cards can always add the high or super high end ones in.
If I recall, it is the mid-range ones that are in the VP's. You should only get the super-high if you're using Adveffects.
-
My cards a 128 meg Radeon 9800 Pro, making it roughly mid range nowadays, and thus I can't really speak for the lower end cards, but I've played with only slight slowdowns in a mission consisting of every HTL ship so far.
Each 2048 res main texture I've made weighs in at 5.4 megs, with an additional 1-5 megs for the glowmap and/or shinemap.
My question is, why is it the shockwave in particular that a fair few people are having trouble with, while these other hefty ships and textures - which need lighting calculations and multiple render passes, are apparently not causing similar problems?
If Strat's right, and it all comes down to the fact that it's multiple frames being used, well, not much can be done about it for now.
However, why is a similar problem not occuring with the warp map - which also ammounts to 5 megs? It just seems strange to me that the shockwaves are the ones to cause the problems when there is so much else that runs fine on the same systems.
-
I'm not sure that it doesn't happen with the warp map, actually (is it EFF or ANI, because that matters for disk access; I can't remember which it is offhand) it's just that the warp animation happens at a time you don't notice it as much. Warp maps may also be properly preloaded while shockwave maps aren't or something.
-
If the latter is indeed that case, then we should probably make sure the shockwaves get preloaded too - as even a bit less lag just on the first one would mean a lot less complaints about them. :)
The warpmap is EFF - DDS, but I now notice that though it's DDS files are bigger, it only has 30 frames in it compared to the shockwave's 159, so that could be a factor also.
-
The shockwave should be preloaded. There was a bug not too long ago which prevented that from working properly but I fixed that (hopefully). The big problem is just the number of frames. If the shockwave has 159 frames then all 159 have to be available for it to work. If the game can't get all of them in memory at the same time then something else has to come out of memory (effects, ship textures, etc.) to make room. If whatever got kicked out is still needed, or soon will be, then something else has to get kicked out to make room for it again (which could mean ditching some of the shockwave frames). This constant back and forth is what tends to kill performance. I have thought of prioritizing effect textures so that they would be preferred to stay in memory at all times, but just haven't gotten around to that yet.
And with a 128meg video card you will only be able to get a max of 90-110 meg of textures in video memory (could easily be less), depending on the mission.
-
Thanks for clearing that up taylor. I knew it had something to do with the shockwaves' absurd animation length, but I wasn't exactly sure what the game was doing about it. If the bug with preloading was recent then it's quite possible that much of the complaints related to the shockwaves is related to that, as that update never got a lot of attention and people may not have noticed a behavior change. At any rate, I still think the shockwaves (and animated beamglows), while pretty, aren't realistic for real-time rendering and so shouldn't really be used unless people know to expect slow performance.
-
Hmm, ok - thanks Taylor. :)
Well, what alternative ways are there of creating such a cool shockwave effect without incuring the same problems?
One option is to use a combination of a vaguely shockwave/doughnut-shaped 3d model, a very short animated texture (or possibly the materials system - can that be applied to effects?) and on the coding side of things, that overexposure thing that was shown ages ago. That way it actually is a 3d model, but the overexposure removes the hard edges that geometry will inebitably create.
Any other ideas? Particle based perhaps?
-
Well for one thing, the shockwave really only needs to expand in one "dimension", i.e. texture OR model, and not two. That's a big cause of the number of textures that are in use now; they account for growth when in fact the model itself also grows. It should be possible to create a simpler animation that cycled (if that were possible) that would use fewer frames and look almost as good.
-
That twin expansion thing is the exact problem I was trying to explain from the start in this thread. ;) It's also the reason the shockwaves were much to fast when they were first released and needed table modifications to slow them down.
And by 'texture', the sort of thing I was refering to was a....shockwavy-energy-rippling square effect - making it tilable over the whole shockwave geometries' surface. Not the expanding ring effect currently used. :)
-
I just wonder...I know it's not that realistic, but in Shadows of Lylat, they should have a spherical explosion model just like in Starfox 64. I wonder if something like that can be used.
-
Now that we talking about 3d shockwaves... would it be possible to get the 3d shockwaves to always appear within certain limited viewing angles.. Say 3d shockwaves would be drawn at a randomly determined angle within (for example) 30 degree angle from the normal of the plane of the shockwave. So that the rather bad looking gaping sides or flat plates (depending on the shockwave model used) would be avoided?
For example in some missions even the retail version shows currently better shockwaves than the SCP version as in those cases the shockwaves are viewed from the side so that with 3D shockwaves the textured sides are almost in 90 degrees angle from the viewing point and are very hard to notice.
-
That's the issue we're trying to figure out how to eliminate rather than avoid - the current 3d shockwaves are effectively 2d shockwaves acting like a 3d shockwave would, which is why we often see them at the nasty 90° angles.
A truely 3d shockwave effect would be visible from all angles and still look good. (Incidentally, Strat's right in that shockwaves in space would be spheres, meaning the 2d shockwave that always faces you is closest to reality, but I'm a fan of the current expanding doughnut shape - much bigger cool factor there. ;) )
-
Yeah, but we need blooming or glowing shaders for this... otherwise 'real' 3d effects looks very plain.
-
Personally I greatly prefer, and only use, DaBrain's 2D shockwave (the blue one) and don't really like the 3D versions at all. I don't want to get into a debate on personal taste though. I do want to touch on one thing that I'm not sure too many people are fully realizing...
The general idea when texturing a ship model is to use as few textures as possible on it. I think everyone gets that at this point. But the thing is that a 3D shockwave is a model too, only in this case you aren't using 1 texture, or even 10 textures, but 160 of them. For a ship that uses animated textures, each frame of that animation is also a texture, so you have to add them all into the texture usage. They may not all be rendering at the same time (for the same frame render of one model at least), but they do still all have to be loaded at the same time. I'm simplifying the analogy a bit, but the basic idea is the same.
I don't think it's fully possible to have really good looking 3D shockwaves at this point in time. We could do more with it, perhaps expanding on the idea of the new secondary weapon transparency effect, to make a shockwave have settable alpha setting at the start and end of it's run. Model transparency should mostly get rid of the seams, and mixing that with cycling texture transparency could give an enhanced visual effect without having to use new animation frames to do the same thing. Perhaps this would allow a better looking spherical shockwave and maybe even reduce the number of required animation frames.