[Galemp]

I am gonna necro the HELL outta this thread.

Code: [Select]

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

[chief1983]

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.

[Spoon]

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.

[chief1983]

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.

[AdmiralRalwood]

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.

[niffiwan]

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?

[chief1983]

Actually, what about just not upscaling the current art at higher resolutions?

[zookeeper]

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.

[chief1983]

The last couple of suggestions could possibly be very small tweaks to the code, anyone interested in checking that out?

[SypheDMar]

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.

[Phantom Hoover]

Single pixels would suffer from aliasing, I suspect.

[chief1983]

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.

[mjn.mixael]

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

[Swifty]

I'll take a gander at the motion debris code and see if I can do anything.

[Yarn]

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.

[Galemp]

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.

[AdmiralRalwood]

Yeah, tiny motion debris at high resolutions does not sound like a bad idea to me, either.

[jr2]

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.

[Yarn]

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.

[Swifty]

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.