Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Fozzy on May 09, 2007, 04:27:37 am
-
A nebular is a massive cloud of gasses, would it be possable to make smaller nebular clouds that you can fly into and fly out of back into space. they could be moving randomaly like an asteroid field...
Fozzy
-
Been discussed before, would require a major code change.
-
Well, could we have glowing, flashing nebulae in the background, like what you see in, say, Homeworld Cataclysm? If there are lightning bolts discharging in the gas clouds, a little flash here and there would be realistic, if it can be done.
-
Animated backgrounds... Like we didn't need another thing that drains the computer resources faster then takashi your control over your anger.
-
lol... It was just a suggestion. Didn't know it'd be that much of an issue.
-
Why not animated backgrounds? It would be cool if you asked me.
-
Because animation with N frames takes N times the memory of a still picture of same resolution.
-
Forgive me for asking this but is really SCP That hard on the hardware, I ran it at 1280x1024 on my old computer with no promblems what so ever with basiclly all things turned on and that computer was over three years old..........
/Dice
-
Because animation with N frames takes N times the memory of a still picture of same resolution.
Random observation: Why DOES the SCP always take so much memory to do things that other games seem to do with minimal overhead? Please (throws up hands) don't kill me coders, I don't mean offense. I'm just curious.
-
Random observation: Why DOES the SCP always take so much memory to do things that other games seem to do with minimal overhead? Please (throws up hands) don't kill me coders, I don't mean offense. I'm just curious.
Using the current FSO build, playing pure retail, the typical mission uses 15-19 meg of RAM. With the MediaVPs, in the same build, it's over 100 meg. Most games don't have multiple 60+ frame animations, 2048x2048 maps for general objects and background, don't load multiple high quality event-based soundtracks and many different sound effects, and don't have to keep everything in memory all the time due to the basic nature of a space sim.
It's neither a SCP issue nor a code issue, so if you have a complaint about memory usage then direct it towards the proper people: mods and the MediaVPs. It has nothing to do with us. :)
-
on that subject, and i know your gonna hate me for bringing this up, will 8,192^2 textures work if the video card supports them? now thats a huge texture even in dxt1. it seems thats what my 8800 gts can take, and i assume most others in the gf8 line. now for a ship using such a map is totally rediculous. but i was thinking of maybe using them for skyboxes or mayby large terrain maps. yes they will be over 24 megs, but assuming youre only using one at a time, and your other data is less than the map size, the result would be an absolutely stunning background that might get more people involved in the engine.
-
Been discussed before, would require a major code change.
Actually, it's not so hard, just requires to sacrify the asteroids: see these blinking lights on ships? well, you make an empty pof, and you add "blinking lights" consisting of the nebula poofs, you put these as asteroids and hop! you're set.
-
on that subject, and i know your gonna hate me for bringing this up, will 8,192^2 textures work if the video card supports them?
Any limitation would be on the hardware side. But using those is going to kill performance. Which is, again, a hardware issue though. Most game engines that use textures that large do it with lookups (just using parts of the image at a time). We don't really have that luxury though, so it all has to be loaded and rendered all of the time. Whatever perfomance bottlenecks you get will just be yours to deal with, since there is nothing we can do in code to make stuff like that work any better.
-
...so if you have a complaint about memory usage then direct it towards the proper people: mods and the MediaVPs. It has nothing to do with us. :)
Exactly. So that means animated backgrounds capability could be added to the code. And reducing some background resolution (arguably doable) by the mod person would allow him to add lightning to the nebula with no performance hit. It's an idea anyway.
Plus, IIRC taylor said the next release would be more efficient with graphics.
And didn't I already fly in and out of a cloud playing FS2 recently? I'm sure I'm missing something there, but even if it's not possible now, is it that hard to add? Again, it's up to the modder to determine how and if the memory gets eaten up.
-
Creative use of skyboxes already allows the use of limited "animated" backgrounds.
Take a close look at BtRL's mini-campaign missions in the asteroid field. And obviously there's the belowed, nauseating subspace skybox we all know and have learned to love...
To be honest, I don't think animated backgrounds would be even remotely plausible, considering the scale of things. If you see a nebula in the distance, there's no way you're gonna see any kind of detail changes in a FS2 mission timescale... except if a supernova goes off inside the nebula. Then you could possibly see a sudden brightening inside the nebula that would spread to the surrounding gas at the speed of light... It might actually produce kinda cool effect... Shame that such phenomena are very rare, and -
Oh wait. :lol: :drevil:
-
...would be even remotely plausible...
Can an animated background be that big a deal to implement? And how rigid is plausible? Well, I think plausibility always succumbs to good storytelling, and good space stories demand good effects. I'm just questioning how much effort would be required to add the capability. I've seen BtRL and WC Prologue do things that supposedly weren't possible, so I have to leave it up to the creators whether they use new capabilities for good or evil. :D
-
Well, with skyboxes I think it already *is* possible to use animated "background" textures. Just map a texture to a part of the skybox and use animation on it. It's a model, it doesn't use the same system as the old background rendering...
The question of plausibility is just my physics freak rising it's ugly head. Again. :p
-
... so I have to leave it up to the creators whether they use new capabilities for good or evil. :D
The problem is that it's not the creators that get *****ed at for the game being slow, or crashing, not being compatible with this video card or that particular driver version ... people ***** at us. I have long thought that we need to give as much control as possible in particular features to the modders, but I've been burned from that position on multiple occasions. Not putting limits on the number of frames in EFF animations, not putting limits on the number of frames for glow maps, not putting tighter limits on the number of ship textures, etc. ... all things that I've tried to do even though it might be best or has been heavily recommended. So I'm not going to walk blindly into an obvious issue which does little more that reproduce the same issue.
A lot can be done with skyboxes, as BtRL has proven, but it also has it's limitations. That's a good thing, since it allows creativity without giving control to the point where it's just ludicrous. Many people have proven time and time again that they simply do not understand how/why something works, should work, or shouldn't work. And we are always the ones that get blamed for it. You can't ask for us to volunteer to code the same situation willingly, because we simply are not going to do it.
And regarding textures, yes that stuff is better in my Xt builds, but it is never going to get better than that. I've spent two years getting it to the point that it is, but I'm well aware of the fact that it can and will only get worse from here on out.
As soon as people start proving that they understand every effect is part of a full game then we will be more willing to introduce new capabilities like this. But so far just about everyone makes effects for the sake of that effect, not for the sake of the game content as a whole. You can't make 1024x1024 effects, you can't make multiple 2048x2048 textures for 100+ ships, you can't make 120+ frame shockwave animations, you can't make 80+ frame explosion effects, you can't make 200+ frame glowmaps, and have the game perform in an even remotely usable fashion. It just isn't going to happen, and having to keep repeating this fact over and over again is getting really old. You have to sacrifice quality for the sake of usability, but if you do it intelligently then users shouldn't even notice. I maintain my own set of MediaVPs with that goal in mind, sacrifing image size, number of frames in an animation, various effects, etc. And you know what, it looks great and performs like silk. It's pretty, it's vivid, the load times are managable, and there aren't any skips due to texture swapping or anything else content related. When that lesson has been learned by everyone else that will be a very happy day for me.
-
It's worth pointing out that BtRL doesn't actually contain any animated skyboxes.
Yep. You heard me.
If people are getting the idea it does cause of the two missions in Scar's Playground they're wrong about what's actually is going on there. The Skybox itself is static. We simply have a very big rotating model in the mission with a bunch of asteroids textured onto it.
-
Yeah, that's why I said "creative" use of skyboxes... ;7
At any rate, rotation is animation of one kind. Animation usually refers to 2D image sequences, but term "animated" in it's basic meaning has no relation to textures themselves. It just means something that has life, or something that moves. :p
Thus I think it's fair to say that both Subspace and the Scar's Playground skyboxes *are*, for all purposes, animated, since they do move. :nod:
-
I think you miss my point. The skybox is static. It doesn't remove or rotate at all.
A ship called Astlayer is responsible for the moving asteroids. That's why multiplayer missions don't have the moving skybox. Ships can not respawn in the bounding box of another ship. As a result when we first tried it ships were respawning 200km away from each other.
-
Ah. I see, my bad. :blah:
So it isn't possible to set submodel rotation for skybox model? :nervous:
-
I think you miss my point. The skybox is static. It doesn't remove or rotate at all.
A ship called Astlayer is responsible for the moving asteroids. That's why multiplayer missions don't have the moving skybox. Ships can not respawn in the bounding box of another ship. As a result when we first tried it ships were respawning 200km away from each other.
THAT's why arrrrwalktheplank spawns a friendly Scar insanely far away!
-
Wouldn't surprise me at all if that was the case. :) It's probably using MOVE_AWAY_BBOX same as the respawn code.
-
dont suppose it would be possible to hack the bounding box on that model so that its somewhere off in the middle of oblivion outside the mission area?
-
A better solution is simply to implement better respawn code that allows you to spawn in certain areas of space..
-
it would be nice to have a general feature that allows use of large background models. skyboxes are ok but a little bit too static. animated textures can do things like battle scenes in the background, but those are too costly. i think mission embedded background scripts would be cool. they would give access to skybox submodels as well as the old background system. you could script a nebula to grow bigger as you fly to it for example. the btrl asteroid ring could be embedded in the skybox, and animated with a couple lines of script.
-
Well, could we have glowing, flashing nebulae in the background, like what you see in, say, Homeworld Cataclysm? If there are lightning bolts discharging in the gas clouds, a little flash here and there would be realistic, if it can be done.
There has been some of them released before, but they were of rather low quality, and regardless if it takes memory it would still be cool to have them used sparingly.
-
or just wait for shaders, and handle the effects procedurally. which is definately more effietient on newer video cards. older cards with minimal shader capability probibly wouldnt run them very well.