Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Topic started by: Galemp on May 11, 2015, 03:21:23 pm
-
I am gonna necro the HELL outta this thread. (http://www.hard-light.net/forums/index.php?topic=70352.msg1390673#msg1390673)
------------------------------------------------------------------------
r6280 | Goober5000 | 2010-07-05 00:41:57 -0500 (Mon, 05 Jul 2010) | 1 line
Changed paths:
M /trunk/fs2_open/code/starfield/starfield.cpp
use motion debris in asteroid fields, per Galemp
------------------------------------------------------------------------
It sounds like a cool feature, but Axem and I have noticed a few issues this might lead to.
It'd be present in missions even when you're not in the asteroid field. There were missions (back before skyboxes were possible) which used an asteroid field to imitate a planet's rings... Also, it seems like it'll show up in missions that have debris fields (rather than asteroid fields), and in nebula missions... consider the Terran debris field from the mission with the NTC Trinity.
Also, there's the issue of it not having any noticeable effect if the player hasn't already disabled motion debris. And possibly ticking them off if they disabled it.
If the motion debris were only enabled when you're within the asteroid field (preferably without appearing/disappearing suddenly), that might be acceptable. Perhaps an entry in asteroids.tbl (IIRC that's the one that defines field types/models/textures), "$Default motion debris:" or somesuch, which controls what sort of motion debris to use within that sort of field, but which could be overridden via FRED? If necessary, an additional entry, "$Nebula motion debris:" to modify the behavior for nebula missions... might be useful.
So when introducing my stepdaughter to FSO yesterday and updating my installation after many years, I noticed this feature I requested went away a long time ago. :sigh: What can we do to get it back?
Aardwolf has some good ideas. Gradually increasing motion debris density as you enter the asteroid field boundary would alleviate the problem of having motion debris with fields in the distance as scenery, or the Trinity problem. The additional entries in asteroids.tbl would also give modders maximum flexibility; having paint chips or loose screws would be a very nice touch in debris fields.
There's also the potential to use this function for other effects, perhaps on a per-mission basis; I can imagine using the nebula motion debris as 'ionized particles' in a mission like Silent Threat's Cloak and Dagger, or FS2's As Lightning Fall. Dream sequences could have twinkling stars.
Finally: How does everyone feel about having them turned OFF by default?
-
I'm all for off by default, but then, it is a change to what (unfortunately) is kind of a core thing about the retail experience.
-
Finally: How does everyone feel about having them turned OFF by default?
Plzno.
I can't stand having motion debris off, it kills all feeling of speed and makes me feel like I'm standing still in space.
-
Yup, I didn't think everyone would be down with that. I'm sure many feel the same, that it's a very important tool for the ambience of being in space. If we could figure out how to update it a bit so they don't look like blurry eye squiggles, that would probably be awesome. I might even consider turning it back on. Right now they just look so dated alongside the pretty updates the engine has received over the years.
-
I like the idea of "$Default motion debris:" and "$Nebula motion debris:", although I haven't looked at the relevant code to see how easy/difficult they'd be to implement.
-
If we could figure out how to update it a bit so they don't look like blurry eye squiggles, that would probably be awesome.
This. I've tried turning them off because they look really bad, but as Spoon pointed out you really lose any sense of speed, so I grit my teeth and generally keep them on. I suppose that making them tiny 3D objects would kill performance (although... if they're no-collide it could be OK since collision detection is the biggest bottleneck?) so we'd need some decent new 2D art, and maybe a check to ensure that it doesn't get scaled up on larger resolutions and start looking horrid again?
-
Actually, what about just not upscaling the current art at higher resolutions?
-
I'd certainly like to see how well motion debris consisting of singular pixels would work. With the typical high resolutions of today it might look just fine. I've always thought it slightly surprising that a '99 game actually did choose to use tiny bitmaps for it.
What is completely atrocious though is how the debris clips into the camera instead of gracefully sliding off to the sides when it passes you. No matter how pretty the particles themselves are, that problem more or less ruins the effect for me.
-
The last couple of suggestions could possibly be very small tweaks to the code, anyone interested in checking that out?
-
I turn them off because they look atrocious too. Haven't played retail vanilla in a long time, and I didn't realize they were on by default.
There's one (terrible) game that got motion debris right, and it's called Battlestar Galactica Online. Just for reference.
-
Single pixels would suffer from aliasing, I suspect.
-
Actually I just meant the not upscaling the size, and fixing the clipping. I agree, I'm not sure single pixel would play nicely, or have much variation to them.
-
Are the motion debris bitmaps moddable? I remember trying to figure out if I could replace the bitmaps and failed. If they aren't, you could at least open them up to modders so we can customize them (and perhaps make nicer looking ones).
-
I'll take a gander at the motion debris code and see if I can do anything.
-
Actually, what about just not upscaling the current art at higher resolutions?
Bad idea, because some people play at very high resolutions like 3840x2160, and the debris would be very tiny for them.
-
Bad idea, because some people play at very high resolutions like 3840x2160, and the debris would be very tiny for them.
...So what? The effect would still be the same: a relative speed indicator.
-
Yeah, tiny motion debris at high resolutions does not sound like a bad idea to me, either.
-
I turn it off, would consider turning on if it was better.. Right now, it's out of place. Where you are in the middle of space should be no motion debris. In an asteroid field, or the aftermath of a space battle, sure.
Plus, it needs updating.
Plus, IIRC, the direction always shows as coming straight at you even if you are being knocked sideways.. Completely ruins immersion when that happens.
Even when there is more debris, you would expect it to be more random I would think. Not all a uniform density.
-
Bad idea, because some people play at very high resolutions like 3840x2160, and the debris would be very tiny for them.
...So what? The effect would still be the same: a relative speed indicator.
The debris pieces are basically small objects that exist in the game world (even if they're treated very differently from other objects). Thus, like ships and weapons, their apparent size shouldn't depend on screen resolution. Besides, you need to scale them anyway so that they enlarge as they move toward the player (which is what the game does now) rather than "pop" into view.
-
So after looking at the code, it looks like there's no explicit scaling or anything that's going on with motion debris sprites. What you guys are perceiving as scaling is merely points being transformed and projected from 3D to 2D space. It's why a given particle billboard on a 1280x720 screen will take up the same ratio of screen real estate on a 1920x1080 screen.
Motion debris particles are about 0.12 units wide in the environment. This value comes from a constant called BASE_SIZE in starfield.cpp. We use a g3_draw_laser to draw them. That's about all there is to it. I thought this was going to be more complicated but it's actually really simple. I thought I was going to simplify some code and remove some unecessary scaling but it looks like this is being done by simple projection transforms which quite typical for anything drawn in 3D. I have no interest in complicating this code but someone else is welcome to address the concerns in this thread now.
-
Bad idea, because some people play at very high resolutions like 3840x2160, and the debris would be very tiny for them.
...So what? The effect would still be the same: a relative speed indicator.
The debris pieces are basically small objects that exist in the game world (even if they're treated very differently from other objects). Thus, like ships and weapons, their apparent size shouldn't depend on screen resolution. Besides, you need to scale them anyway so that they enlarge as they move toward the player (which is what the game does now) rather than "pop" into view.
Yep, if it was pixels I fear it would feel like a wing commander one minefield.
-
The HUD still shrinks down at larger resolutions right? Becoming smaller but more crisp looking? That's what I thought we could have happen with the debris. Relative size changes related to speed would remain in place, but the overall size would shrink with increasing resolution like the HUD, so that they always cover the same pixel area instead off unit area. Maybe it wouldn't work well, but that's what I was getting at.
-
HUD works that way because we're transforming 2D points manually in software; there's no perspective Z and we use an orthographic projection for the HUD.
Motion debris doesn't work that way because motion debris are drawn in 3D. Meaning they have a Z and therefore are transformed by a perspective projection matrix in hardware.
-
Ah, wow. I had no idea they were that differently handled.
-
I like the concept of motion debris, but I've kept it turned off for years because the retail implementation frankly looks butt-ugly. If you guys can figure out a way to gussy it up I'll put it back on in a heartbeat. :yes:
-
Every time I saw the flag, I just assumed it was an option to keep debris chunks from ships from rotating. So I had no idea that the option existed!
-
Are the motion debris bitmaps moddable? I remember trying to figure out if I could replace the bitmaps and failed. If they aren't, you could at least open them up to modders so we can customize them (and perhaps make nicer looking ones).
From a quick dig through the code I believe the answer is yes. It can be set/changed in stars.tbl (http://www.hard-light.net/wiki/index.php/Stars.tbl#Non-nebula_debris) and in theory they can be .ani, .eff, or even a single image bitmap. The retail ones (normal debris only, there don't seem to be any retail assets for nebula debris?) are .ani at 18x15 res with 7 frames each.
-
I made custom motion debris for FotG, so it's definitely possible to replace them with something nicer looking. The thing that really bugs me about motion debris is how they don't rotate properly when you roll the ship. I can only notice it when the ship is at a standstill of course, but it makes them really jump out as sprites rather than something that seems like a natural part of the backdrop. If they could either be made to rotate correctly or just faded to transparency as you slow down that might make them more acceptable to a broader assortment of players.
It's also kind of weird how they always are rendered behind ships even when they clearly should be closer to the camera.
-
I can tell you that there are 2 sets of debris for Motion Debris, one is standard, the other is for Nebula (but for the longest time, the Nebula entries in the code were not specified and looped (if I recall correctly) using the non-Nebula ones, so I'm not specifically sure that it's utilizing any "different" ones in a nebula vs. not.
So it is possible to make a separate toggle for each depending, I'll admit though that it's been awhile since I've looked at it, so I don't fully know what it would require.
debris_vclip Debris_vclips_normal[MAX_DEBRIS_VCLIPS] = { { -1, -1, "debris01" }, { -1, -1, "debris02" }, { -1, -1, "debris03" }, { -1, -1, "debris04" } };
debris_vclip Debris_vclips_nebula[MAX_DEBRIS_VCLIPS] = { { -1, -1, "nebdeb01" }, { -1, -1, "nebdeb02" }, { -1, -1, "nebdeb03" }, { -1, -1, "nebdeb04" } };
debris_vclip *Debris_vclips = Debris_vclips_normal;