Friday Facts #411 - All about asteroids

[KillHour]

Will the new features added re: shaders and arbitrary sprite rotation be available to modders and usable planet-side, or is it all hard coded for the asteroids?

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

[jaredjeya]

On average, larger asteroids should rotate slower than smaller ones (because of conservation of angular momentum in any collision)

Specifically, due to equipartition of energy, the rotational speed should scale as 1/sqrt(ρr^5) or ρ^(1/3) * m^(-5/6), where ρ is density, r is radius, and m is mass.

This assumes they’re a well-equilibrated system.

(Physics is my day job, I can’t help it, sorry).

[DrakeyC]

Not to be mean, but seeing all the effort put into the space background and in particular the asteroids...feels kinda pointless.

I just mean, how much time are we actually going to spend in space? I don't recall it being mentioned that there will be resources that can only be acquired in space, so we won't be going into space unless we're traveling between planets, and I'd assume once we get there we'll be spending most of our time on the surface. If travel between planets is a significant investment of time, we're gonna avoid doing it until we have to since that's time not spent on the planets doing something productive; conversely, if travel isn't a significant time investment, we won't be looking at the space screen very long.

There's also the Fridge Logic others have brought up, and while I don't really care myself, given Factorio's commitment to relatively grounded concepts of physics and science, it does come off as a bit odd that bullets fall onto the platform like anti-gravity, or that there are constant asteroid storms between planets so we can mine resources on our way there.

Though this FFF does make me think more about space platforms as a whole. I remember a previous FFF talking about how we'll build and expand our platform, how we'll have to generate fuel for it, build defenses to shoot asteroids and claw mechanisms to gather resources, and the size of the platform effects its fuel efficiency or speed, so power efficiency modules are useful here...

Point is, how much time do the developers see us spending on the space platform? Because while it looks neat, it seems like a novelty that can wear off fast and will become busywork that's easily cheesed once we figure out a few optimal builds to get us between planets with minimal effort and resources.

[FuryoftheStars]

I don't recall it being mentioned that there will be resources that can only be acquired in space

Space science packs can only be produced (in bulk) in space. And fuel for your platforms can only be produced there, too.

But otherwise, yeah, the only times we'd be in space is while physically traveling from one world to another, which they've improved to remote tools in an effort to minimize that.

[mrudat]

Will the new features added re: shaders and arbitrary sprite rotation be available to modders and usable planet-side, or is it all hard coded for the asteroids?

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

That does sound awsome, I expect extracting the normal map would be easy enough... but I'm not sure there's enough information with just that to do lighting planet-side.

Lighting based on normal maps is for mostly-flat objects, eg. a stone wall; it doesn't work well for something like a power pole, or for hollow items like the big power pole.


Something I'd like to see; (nominally, or better, visibly) differential thrust when you turn around to leave planet x to go to planet y, with the world rotating around you.

I suspect, given how things work it might be feasible.

[morhp]

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

Moving the light source doesn't really work as the directions of the shadows are fixed (unless you want to use tons of sprites for different shadow angles, but that kinda defeats the point). That shader stuff works best for things that rotate while the sun stays in the same place. It could work for some particle effects, though.

[TOGoS]

I know it helps giving the impression of movement, but having "stars" moving in the background is very un-realistic...

I'd actually be okay with the stars visibly moving on the grounds that the Factorio universe is simply a lot smaller and denser than ours, hence running into asteroid fields all the time. That said, if a more-realistic-as-far-as-distance-to-stars-is-concerned approach were taken, I wouldn't mind that either.

What bothered me much more was the instant starting and stopping shown in an earlier FFF when the rockets were going or not. Trains have momentum and take time to speed up and slow down; the space platform should certainly act as if it has a great deal of momentum and accelerate/decelerate slowly, even if there is a crapload of dust that it's constantly ramming through. I'm hoping the instant start/stop was only an artifact of it being an early preview. Having your spacecraft decelerate so rapidly when the engines stop would be quite jarring!

[mrudat]

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

That shader stuff works best for things that rotate while the sun stays in the same place. It could work for some particle effects, though.

So... stuff that rotates already: turrets, radar, trains...

I wonder if you added the new shader to existing rotating sprites if you could reduce the number of frames required enough to counter the increased memory usage of the normal map, that or make things just that little bit shinier for an increase in memory usage.

[QELO]

Thank you for explaining the process of making it easier to distinguish between the three types of asteroids.
I don't think it's necessary to get close to reality because it's pseudo-reality. Plus, the asteroids you build will be smashed by rocket turrets on our space-platform!

[FuryoftheStars]

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

That shader stuff works best for things that rotate while the sun stays in the same place. It could work for some particle effects, though.

So... stuff that rotates already: turrets, radar, trains...

I wonder if you added the new shader to existing rotating sprites if you could reduce the number of frames required enough to counter the increased memory usage of the normal map, that or make things just that little bit shinier for an increase in memory usage.

Not in that way, no. It would be useful for rendering shadow from uneven surfaces onto itself, like the shadows cast onto the asteroids themselves by their own craters. It can't be used to render a shadow cast separately onto the ground or to render different sides of the object itself as it turns. Note how the asteroids only rotate on the flat plane... the shader can't do the sides we don't see to create tumbling.

[Roxor128]

Say, wouldn't all those micro-meteors and space dust damage the platform?

You could implement that as simply applying a constant amount of damage per second to whatever's on the front edge of the platform while it's moving, and scaling up with platform speed. You'd only need to figure out what needs damaging when the player changes what's on the platform or something gets destroyed.

[mrudat]

Using this to do directional lighting that changes throughout the day and with local light sources would be really cool, although probably a lot of work to render all the new maps.

That shader stuff works best for things that rotate while the sun stays in the same place. It could work for some particle effects, though.

So... stuff that rotates already: turrets, radar, trains...

I wonder if you added the new shader to existing rotating sprites if you could reduce the number of frames required enough to counter the increased memory usage of the normal map, that or make things just that little bit shinier for an increase in memory usage.

It can't be used to render a shadow cast separately onto the ground or to render different sides of the object itself as it turns.

That's why I'm thinking of an extension of the existing rotating sprite; the ideal would probably be to be able to have a diffuse, normal and shadow animation, with the ability to have non-uniform frame timing, so each sprite could cover a different arc of the rotation.

Hmm. Yeah, rotating in the plane of the surface is distinct to that of the projection used for the building sprites; I'm not sure if you could usefully tween a rotating sprite by using simple rotation, on the other hand if the rotation is small enough between sprites, it might not look too janky, or at least less janky than stepping from one frame to the next?

Thinking about it a bit more, you could perhaps store motion vectors for tweening frames; you displace the pixel you look up by this much between this frame and the next, and issue a new frame when you have to make up too much stuff. Something like space warp for making up new frames from old frames for when your graphics card is too weak, but we have complete information, as this is an animation.

Hmm. That suggests that you want something akin to a bidirectional prediction frame (e.g. MPEG-2) that records how the image can be warped from frame 1 to frame 2, so you can smoothly interpolate between the two without needing to make things up at all.

That would then suggest we want a simple video codec with a shader decoder capable of extracting a tweened frame for storing simple animations and one capable of tweening across two or more dimensions for complex animations; I wonder if such a thing exists.

[twig]

i feel very mixed on the background stars, it just *feels* like it's a 2D sprite moving across the background, not to mention how unrealistic it is - i assume the team has tried moving the background stars at different speeds, or maybe that's too computationally demanding?

[mrudat]

Perhaps what might look best is stationary (seed-based random) background stars, with smaller and smaller parallax scrolling asteroids?

Perhaps the occasional asteroid passing over the platform by way of a shadow?

If you're really keen, background stars for the journey from planet a -> b, rotated 180 degrees for b -> a, a different set for a -> c, b -> c, ...

Possibly with the outer planets appearing in the distance for a journey between two inner planets.


Edit: Thinking about planets a bit more, satellites and spaceships must be parked at L1; if there's no day/night cycle in space, we must be in a stable, nearby orbit that's not in the planet's shadow... which I think pretty much means L1.

This suggests that we should see the planet just before arrival, which would be roughly below the centre of the platform while parked at L1.

Hmm... no, there are also Sun-synchronous orbits, which would be interesting to work out how the background stars would look for, but would place the planet towards the edge of the platform... which suggests that rockets should arrive/leave from/to the edge of the screen; presumably the bottom edge to make life easier.

It would also mean an orbital laser canon would need to face the bottom of the platform.

[escfoe2]

Honestly, the longer the descriptions, the better. The more information I can digest, the better. And the further the rocket gets to travel when I'm done........the better.

[TROPtastic]

In addition to the other commenters who've mentioned that stars in the background shouldn't move at all (interstellar distances are incomprehensibly bigger than interplanetary distances), something seems off with the relative speeds of the gas clouds and the asteroids.

In the final gif, when the ship stops the dust clouds come to a gradual stop, but the asteroids for some reason stop instantly and then move downwards again. The dust clouds should presumably be close in distance to the asteroids, so both should speed up and slow down at the same time. Actual movement speeds (as opposed to accelerations) can be different.

[mmmPI]

I'm not sure it's correct regarding physics, it would need some space-experimentation to make sure, but i think i have an explanation for the movement of the background stars :

The space platform is having some sort of circular motion represented here by an orbit around a brown circle

orbital simulation.jpg (35.56 KiB) Viewed 1614 times

When the platform rotate, what is visible depend on the rotation of the platform, this is difficult to see in game because the rotation is happening in the 3rd dimension, when the game only seemingly has 2.

Sometimes the angle between stars should change, but it make perfect sense that they disappear very fast , if the platform is making a fast rotation.

Right ?

[MeduSalem]

[...]

Sure, rotation of the platform itself around a certain axis would make the background stars also move.

Lets analyze the possibilities:

First defining the axis:
x-axis = horizontal screen axis
y-axis = vertical screen axis
z-axis = perpendicular to screen

1. Rotation around x-axis
   The consistent "top to bottom" pattern of background stars where only the y-coordinates of stars changes... would correspond the most with the platform rotating around the x-axis. The x-axis it rotates around would always be on screen, but can be shifted along the z-axis (meaning it can be down below the platform)
   1. x-axis at platform center (Pitch)
      The platform would behave like the tilted axis of the Uranus which basically "rolls" along its flight path like ball on a surface would.
      For the space platform that would be really stupid because of the implications it has. Eventually you would rotate the platform such that its entire front surface faces into the direction of the movement and at some point it is the back surface where you don't even have turrets to shoot the asteroids. ^^
      Not to say that it totally conflicts with the rest of the graphical features like asteroids, dust etc which don't go along with it.
   2. x-axis at planet center (Orbital movement near planets)
      For the background star movement to be a result of orbital rotation it also implies we look down on the planet's surface while nearby. But haven't seen anything like that yet.
      Anyway with the planet in the view there likely would be no rotating background stars because the planet blocks the view. ^^
   3. x-axis far (Transfer between 2 planets)
      Since you constantly look down on planets it would be weird in space because it would imply an "ascent" flight path like an aeroplane does; you would have the feeling of gaining "height" while moving away from planets until you moved far enough that the planet would leave the screen. Similarly you would have the feeling of "descending" while you approach a planet.
      Anyway you would only notice background stars rotating once far enough away from a planet because otherwise the planet would block the view. And the further away you are the slower the background stars will rotate because of the "radius" of the curve from the transfer path becoming extremely huge.
      Exactly on half-way between the 2 planets the background stars would move the slowest in relation to the platform because the radius of the transfer curve will have peaked. Sounds contradictory but that is how it is. ^^
2. Rotation around z-axis
   While possible it would mean that both relative x & y coordinates of the stars are transformable. It would imply that sometimes background stars can enter/leave on the left/right edges (depending on what's the direction of the rotation) of the screen in addition to from entering at the top of the screen. They would also move around the screen in a more curvy path since both x&y coordinates can change.
   1. z-axis at platform center (Yaw)
      Which would rotate the platform around its center axis. It would spin like the asteroids. Obviously doesn't happen. ^^
   2. z-axis at planet center (Orbital movement near planets)
      In this one we don't look down on the planet like above; but rather we look down into space below the platform; the planet (and with it the axis of rotation) would be somewhere left or right to the screen edge.
      The background stars rotating effect would happen more noticeably because we can see space; and the orbital period near a planet is relatively "short", so the background stars would rotate relatively fast.
      Also the effect would still be noticeable, albeit slower, even if the platform is "stopped" because the rotation is caused by the orbital movement and not just by accelerating the platform. But from some of the clips it is shown that the background stars stand still when the platform stands still, so that contradicts with the expected behavior.
   3. z-axis far (Tansfer between 2 planets)
      The axis would be even further away left or right ouside the screen. Similar to the other transfer between planets above it would also happen that the background stars rotate. But even so it again would happen at a much, much slower rate the further away from any planet because of the large "radius" of the rotation involved.
3. Rotation around y-axis (Roll)
   All 3 variants can be ruled out; because rotation around y-axis would make the background stars consistently enter and leave from the left/right edges of the view screen. Since that doesn't happen it can be ruled out.

Nothing really works without some weirdness. xD
Anyway... we are interpreting too much into it. ^^

[mmmPI]

Lets analyze the possibilities:
[...]
Nothing really works without some weirdness. xD
Anyway... we are interpreting too much into it. ^^

I was thinking of "pitch" , but forgot it was called this way. I wasn't thinking of 1)a), such "too fast rotation" is not intuitive to me, i was thinking of the spaceplatform as a rollercoaster making a looping. I'm not sure between 1)b) and 1)c).

I tried to improve the drawing, the plane like the space platform has front back, up down, left right. When we play, we see from the top,we never see the planet because space-platform orbit around. When going from one planet to the other, we would see the destination if we where in first person view as the engineer. But it's not the case. Instead when the platform goes from position 1 to position 2 we will see 4 stars, coming from top of screen and disappearing at the bottom. Then from position 2 to position 3, only 1 star, from 3 to 4, 3 stars.... and so on.

orbitalapproach1.png (160.76 KiB) Viewed 1435 times

I'm not sure that make sense as a trajectory for spacecraft, i documented from this scientific website : https://xkcd.com/2909/. I have yet to put that in practice

[MeduSalem]

[...]

Ahhh. That is actually the only variant I didn't think about; that the planet might actually be "above" us, rather than looking down upon it. xD

But yea, since the platform view would always be facing away from the planet that would make such a rotation of the stars possible. ^^

The only thing that would still be wrong with the way it is in the FF's clips though is that the stars would rotate faster the closer you are to a planet because the relative angular speed close to a planet is higher than when far away from the planet. The curve of an orbital path is just tighter and the resulting orbital period shorter than the curve of a transfer path between planets. Transfer orbits are some weird elliptic orbits after all. ^^

So the background star movement speed would still have to be some inverse-function depending on the distance from Planet 1 & Planet 2, where it feels like the stars almost don't move at all when you are exactly half-way between Planet 1 & Planet 2, and slowly accelerating the closer you get to a planet.

So the initial issue still stands, the stars move too fast when further away from the planet. xD


That said the "always facing away from the planet" variant is a last resort cop-out. ;P
I would even prefer that it was the opposite where we at least get to see the planet below while in orbit. ^^