On the Subject of Planets

[CodeBlack]

This its the video:


Seriously, at some stage Starmade must to have planets that appear planets not planetoids.

I like this system...
i still think that there should be way less planets but the ones that are there should be bigger.

 

[FunnyBunny14]

That looks interesting. Actually, if we were to go that route, I'd prefer having more sides and larger & rarer planets with varying climates from poles to equator. Right now planets are too small to vary between poles an equator. Unfortunately, this still doesn't solve the issue of plate edges interrupting construction.

Varying biomes: yes.
Larger and rarer planets and more sides: no.
@CodeBlack : that would actually not work well, as has been stated by schema. There are all sorts of technical issues with that, and from what I've heard you really don't want those in starmade.

 

[Valiant70]

Varying biomes in current planet sizes: no. The planets are too small and it would not be likely to look good.[DOUBLEPOST=1411418851,1411418646][/DOUBLEPOST]

Varying biomes: yes.
Larger and rarer planets and more sides: no.
@CodeBlack : that would actually not work well, as has been stated by schema. There are all sorts of technical issues with that, and from what I've heard you really don't want those in starmade.

You think far too narrowly. There are a plethora of ways to make that system or a similar (and much smaller) system work well in starmade. Looks like my post about some of them is buried somewhere in the middle of this thread. Maybe I should make a new thread.

 

[NeonSturm]

I think some cracks are a feature.

With the impossibility to build on (or just bridges) it's mostly the gravity (and orientation) glitches which are unfun.


If planets would be bigger and lag-free, those cracks would seem natural earth quacke areas.

 

[Valiant70]

I think some cracks are a feature.

With the impossibility to build on (or just bridges) it's mostly the gravity (and orientation) glitches which are unfun.


If planets would be bigger and lag-free, those cracks would seem natural earth quacke areas.

IF I could actually build a bridge that:
a. Touches both plates
b. Looks right with wonky block angles
I would be inclined to consider your argument valid. As it is, no. The cracks look and feel like fail. Fortunately Schema made the edges of the plates match up more height-wise in a recent update, but even that looks artificial and weird in a lot of places, and as far as I know player-placed blocks cannot overlap with other plates, ruling out decent bridges and even inter-plate grav tubes.

 

[NeonSturm]

I would be inclined to consider your argument valid. As it is, no. The cracks look and feel like fail. Fortunately Schema made the edges of the plates match up more height-wise in a recent update, but even that looks artificial and weird in a lot of places, and as far as I know player-placed blocks cannot overlap with other plates, ruling out decent bridges and even inter-plate grav tubes.

Actually you could use open plex doors, dock a ship and close the plex doors of a dock to get 2 blocks in partially the same space.

Use wedges to kit the 0.5 m gap

Works pretty well with a single activation module next to the dock auto-opening and closing plex door walkways.
Just don't make it in a 45° cone above the dock or you can't dock anymore :p
As long as they are open you can dock. if you are docked the ship don't care about if they're open.

 

[Valiant70]

Actually you could use open plex doors, dock a ship and close the plex doors of a dock to get 2 blocks in partially the same space.

Use wedges to kit the 0.5 m gap

Works pretty well with a single activation module next to the dock auto-opening and closing plex door walkways.
Just don't make it in a 45° cone above the dock or you can't dock anymore :p
As long as they are open you can dock. if you are docked the ship don't care about if they're open.

Clever workaround. The game needs to allow you to place blocks on the planet segments that overlap like the natural blocks, though.

 

[clawson200]

That looks interesting. Actually, if we were to go that route, I'd prefer having more sides and larger & rarer planets with varying climates from poles to equator. Right now planets are too small to vary between poles an equator. Unfortunately, this still doesn't solve the issue of plate edges interrupting construction.

no it doesn't solve the problem of it interrupting construction. But if you made the section bigger and separate, by separate i mean going through a loading screen, you could make all the sections flat, no competition.

 

[Valiant70]

What do you think pals?

I think that's a great idea. The level of detail in the 3D map would be easy to configure (and it wouldn't use much processing power anyway), leaving a good-looking solution that works on all Starmade-worthy machines. It would be possible to make the texture of the 3D map from the actual surface as well, making it seem even more real.[DOUBLEPOST=1411476646,1411476534][/DOUBLEPOST]

no it doesn't solve the problem of it interrupting construction. But if you made the section bigger and separate, by separate i mean going through a loading screen, you could make all the sections flat, no competition.

The player base by and large does NOT want loading screens, and Schema doesn't either. A more advanced solution is needed if planets are going to have uninterrupted segments.

 

[NeonSturm]

Do we have a possible solution for vines? ((The floating things on purple planets))
Do we have a solution for overhang-cliffs?

These are the two things that (I believe) prevent schema from implementing it.

 

[Incap]

I especially like this idea. It gradually moves from a smooth round surface to a more Minecraft block shape. The transition looks believable and smooth, instead of moving instantly from 'ball' to 'blocks' like our current system. I'm giving you a like my fuzzy fluffy and huggable friend and I hope others do too so there is a passive chance the devs might see.

I also like how this can be done, this way we could still have spaceships glassing/landing on planets! And not only that, but now planets can be interesting to explore and build on instead of 'meh'. You could even add cool stuff like mountains, caves and chasms!

...Can someone who is popular send this off to the blokes? I really like it.

On it.

 

[Lecic]

Look at this video. Notice there are no loading screens.
In fact I'm going to gather the best posts from this thread and push this "3d mapping planets" movements for bigger better and more realistic planets.

Did I mention that was done by one person? Yeah, schema has actual competition :3

Space Engine isn't a game. It's just an engine showing off a possible feature. It would be a lot less smooth in multiplayer with players and ships and battles and creatures everywhere.

 

[WaffulMann]

Space Engine isn't a game. It's just an engine showing off a possible feature. It would be a lot less smooth in multiplayer with players and ships and battles and creatures everywhere.

It can use the same concept. 3d mappping is not something that cannot be done in a voxel game.

 

[Valiant70]

As stated before, we do need to find a good solution to the issue of overhanging objects for 3d mapping to look good. Any ideas for this?

 

[NeonSturm]

As stated before, we do need to find a good solution to the issue of overhanging objects for 3d mapping to look good. Any ideas for this?

Maybe just throw a virtual cloth over it (from straight above) and use it for rendering.

Floating parts could be ignored for high-map generation if they have only 1 block occupied per 1..2 blocks free below.
Floating parts may render like MineCraft clouds, on a second partially transparent high-map indicating that there is something you may crash into.

I don't know if that is a good solution for performance/usability, but the best I can think of right now.

 

[kupu]

[Reposting a repost here; but this is a pretty active debate and i'm not sure if all of you would of seen this. Hopefully it will help the debate / new generation of ideas.]

Spoiler: Schema's response

I think Schemas words on this (originally on reddit) should probably be pasted here for all to see. It gives a pretty good overview of his thoughts and might save a repetitive conversation (or spur a new approach to solutions).

That's a nice showcase, and I agree it would be more realistic, but basically it has been talked about a lot already.

Doing this without having physical space ships for singleplayer is not that much of a problem (it has a lot of game-play implications still)

Changing context from a sphere to a block world is something that only works in theory. I've seen a lot of attempts including my own. It causes way more problems than it would solve.

• Seeing the world from 2 difference points in space would have to account for the warp in space. And you dont even have a "point" in this space. If you would put actual space ships in there their geometry would be warped in the border zone. All shots/missiles etc would warp, which means you couldn't really hit anything on a planet from space. In their case they are warping the blocks themselves, which is relatively simple with one restriction that pretty makes the concept impossible for actual gameplay: The planets have to be huge, and there cant be any serious elevation going on. The more you move to or away from the core from a certain "good" value for that sphere you are on, you will see very ugly graphical things.
  
  
• data size: as every planet is it's own world, you have to save at best case everything modified. And modification is done as easy as a few missiles. Check the starmade server database, in where planets are the biggest entities (given there is a lot of room for optimization)
  
  
• gameplay: Those worlds are huge and starmade is already huge. putting in vast areas where even mincecraft players on the same player would never meet wouldnt exactly help gameplay in my opinion.

Still this is a very cool video, but it's just not practical, especially with starmade focusing on space and less on planets

...

oh yeah, more faces would make it rounder. A complete sphere (in theory) would have infinite faces. So based on that I tried to find (based on the input of the forum) a good middle ground of where gameplay and realistic planes would be ok to meet. I mean we are always talking about making a sphere of a cube which doesn't really work in this gameplay context.

If i saw any realistic chance of doing this kind of planet, believe me, I would do it.

The problems with bigger planets are things not visible in the video. The planet, except the places that are absolutely near the player, is hidden by LoD (Level of Detail).

It is mostly used in graphics programming, but in this case has to be also used for the data, as its impossible to hold even one planet of that size - even if one block is just one bit - in memory.

As a simple example of what that means, is shooting a laser from orbit to a planet that is just made out of general very rough faces (planet surface -> very big cubes -> smaller cubes -> smaller cubes -> ...). The shot would have to resolve that to the actual smallest blocks to see where those hit. Now imagine 100/sec of those. Also you have to build a physical mesh for all of those faces to check where stuff collides, and that mesh has to be recalculated constantly for more than one player.

This isn't the first video showing something like this, and people get excited. I understand that. But a fine showcase doesn't translate into the same gameplay that you'd expect. There are a lot of little and bigger things that have to be considered

The original conversations can be found at the link below for those curious.

http://www.reddit.com/r/Starmade/comments/2f07jc/this_is_how_planets_should_be_in_starmade/

 

[NeonSturm]

As a simple example of what that means, is shooting a laser from orbit to a planet that is just made out of general very rough faces (planet surface -> very big cubes -> smaller cubes -> smaller cubes -> ...). The shot would have to resolve that to the actual smallest blocks to see where those hit. Now imagine 100/sec of those. Also you have to build a physical mesh for all of those faces to check where stuff collides, and that mesh has to be recalculated constantly for more than one player.

It just hits that level of detail that is currently rendered.

lowest-loaded = Blocks -> damages blocks.
lowest-loaded = Chunk -> damages chunk; Not generated chunks have an average HP value.
Or just make a crater in the high-map and modify the damage overlay colour for this part. This affects how lower detail is generated once visited.
lowest-loaded-detail-level = 16*16 Chunk (see above)

If you want exact orbital fire, you have to load the chunks by zooming in.

To see something in high-resolution from distance, you have to pay :
2D resolutionIncrease = (scanTime * (scannerPower)^diminishingReturns )
2D resolutionIncrease = (scanTime * (scannerPower)^diminishingReturns )^0.5

They are generated based on parameterized input from damage|resource|modification-overlays.

damage|resource|modification = 0..16 or 0..255 per "raster-unit"
The raster may store time of last visit and erase damage as result of earth-quakes or natural growing plants, ...
Craters may influence the distribution of high below the highmap, but the planet may regenerate from some damage.

Another idea would be to make the orbit >2km thus preventing ships from firing at the surface.

There could be ballistic fire which can only be fired at loaded blocks.

If you or an projectile enters/leaves the planet radius :

  float3 lp := lastPosition
  float3 cp := currentPosition
  float3 cpr := cp^2 - planetPosition^2 // current position relative to the planet
  ..enter if(( ~inPlanet && planet.radius^2 > cpr{x*x + y*y + z*z} ))
     // subtract sector rotation
     // divide through sector scale (*1/factor == faster *1*multiplier)
     lpr := lp^2 - planetPosition^2 // last position relative to the planet
     // multiply with sector scale
     // add sector rotation
  ..enter
  ..leave else if(( inPlanet && planet.radius^2 < cpr{x*x + y*y + z*z} ))
     // subtract planet rotation
     // divide through planet scale (*1/factor == faster *1*multiplier)
     lpr := lp^2 + planetPosition^2 // last position relative to the planet
     // multiply with sector scale
     // add planet rotation
  ..leave
    // commented out parts (green) are calculated when entering planet sectors
    // or not needed as scale will probably be 1.

Usually the glitches happen by dividing. Multiplying with the 1/factor value could help.
Else try to get the position of the planet relative to the ship by

1. NOT getting the planet in the ship's coordiante system
2. but the ship into the planet's coordinate system (same calculations as with projectiles fired at the planet)

Then you need to translate the ship's position and rotation with (-value) to the planet's position relative to the ship
2nd are calculations which don't produce glitches like a divsion does.
That should put the very same glitches on the planet position on your screen as it does on projectiles entering it, thus negating the effect of glitches.

As it is not reasonable to hit a static target on a rotating+moving planet orbiting a rotating+moving sun with all the gravity influences from other planets, moons and the universe, I think it is realistic to just ignore the ability to exactly hit from outside a planet's orbit (said orbit, not gravity sphere )
I hope this gives some new Input

 

[WaffulMann]

[Reposting a repost here; but this is a pretty active debate and i'm not sure if all of you would of seen this. Hopefully it will help the debate / new generation of ideas.]

Spoiler: Schema's response

I think Schemas words on this (originally on reddit) should probably be pasted here for all to see. It gives a pretty good overview of his thoughts and might save a repetitive conversation (or spur a new approach to solutions).

The original conversations can be found at the link below for those curious.

http://www.reddit.com/r/Starmade/comments/2f07jc/this_is_how_planets_should_be_in_starmade/

But what about at least 3d mapping? Would solve a lot of problems without changing anything (that includes the shape), just how planets are rendered. I know round planets are bad, but with the current ones, without 3d mapping you see the core before you see the planet. And it would also take a very good computer to render a whole planet.

 

[Valiant70]

[Reposting a repost here; but this is a pretty active debate and i'm not sure if all of you would of seen this. Hopefully it will help the debate / new generation of ideas.]

Spoiler: Schema's response

I think Schemas words on this (originally on reddit) should probably be pasted here for all to see. It gives a pretty good overview of his thoughts and might save a repetitive conversation (or spur a new approach to solutions).

The original conversations can be found at the link below for those curious.

http://www.reddit.com/r/Starmade/comments/2f07jc/this_is_how_planets_should_be_in_starmade/

I actually had an idea that could solve most of the issues associated with such a system. I didn't think all of it up myself - it's essentially a compilation of my and other's ideas into one coherent system.

Spoiler: My idea compilation

I think the best course of action in the case of a planet overhaul is going to be some combination of the many ideas displayed here.
This would require a lot of work and coding and take a long time to implement, but in my opinion it would be worth it. Planets really seem like an underused feature right now, and making them this amazing would cure that in a flash.

1. Increased realism of having far larger and far, far rarer planets (as few as three in a star system, and fewer star systems).
ADVANTAGE: Reasonable level of realism and makes planets more valuable.

2. Seed-based fast-generation to save data and save only chunks that a player has added blocks to. Generate ONLY the surface chunks unless something lands or the surface is disturbed by something like weapons fire or mining beams.
ADVANTAGES:

• Will not use much save data - in fact it may use less than the current system which generates entire planets and saves them!
• Ore is replenished when the area regenerates. This could be refined to delete/regenerate abandoned areas after all manmade blocks are removed. This fixes "Minecraft syndrome" where the world near the spawn area is slowly used up and turned into wasteland.

3. LOD compression to hide the lack of blocks in the distance while maintaining frame rate. Any distortions to blocks needed to conform to the sphere happen in this region beyond any loaded blocks. This could be configurable to just having the distance invisible or perfectly flat to help older computers.
ADVANTAGES:

• No need to generate surface when flying at high altitude
• Configurable to perform reasonably on all (starmade-worthy) machines
• Immersion

4. Angle relativity to planet surface (see my previous posts) with no gaps or overlaps between most segments. Ships can be obscured by the atmosphere from above and below (except on radar) to hide the abrupt transition from universe-relative to surface-relative angle from outside observers (angle remains the same for observers onboard a ship). A re-entry effect could be added so it doesn't look like a ship appeared out of nowhere.
ADVANTAGES:

• Immersion
• Fewer or no annoying overlaps or gaps to disrupt construction.
• No distortion of blocks

Spoiler: The post about angle relativity

Well, my idea was more to keep everything flat and square and have planet loading use some degree of relativity client-side. In other words, there would be no overlap! I suppose it wouldn't be too bad to have one awkward crack to jump over near each pole, but it would complicate the coding somewhat as the idea I had results in a completely different behavior from the way the current engine loads things.

What I had in mind is obviously really complicated and would require some major additions to the engine, but on the other hand the results would be really amazing. Remember that our own universe operates in relativity.

What I had in mind was more like this: each player sees the spot he/she is standing on as flat, and everything loaded as a continuous, flat square. The universe-relative angle at which the player stands is the same as if he/she were actually standing on a sphere, thus approximating the player walking on a sphere without block distortion! Relativity comes into play when two players are within visual range of each other. Each player sees all others on the surface as if they were standing on the same plane.

When a ship enters the atmosphere, a similar effect comes into play. The ship actually keeps its universe-relative angle and tracks the surface as if the point directly under it were flat. Players see the ship's angle as if it had the same angle relative to their own plane as it has to its own. In other words, everyone sees the ship as having the same angle to the surface while it is within the atmosphere.

Again, this is complex and difficult to do, but I think it is feasible. Whether or not Schema wants to put THAT much work into the engine to make it work is the question. The issue still remains what exactly to do at the poles. Given the obvious issues, I personally wouldn't mind having a bit of weirdness at the transition between normal and polar areas. The poles could be one segment and overlap with non-polar terrain. However, if my idea is implemented, the overlap will be in a perfectly flat plane, meaning there's no need to hop over it!

TL;DR - everyone's client pretends the loaded part of the planet is flat, and each object close to the planet keeps track of its angle relative to the surface directly below rather than relative to the universe.

I'd really like to know if any of this is possible, as it is different from the software demo videos that have been posted. Planets wouldn't need to be thousands of square kilometers. Ten square kilometers would be slightly excessive. Five would be great. One would be okay.

 

[NeonSturm]

Don't miss my last post (got unfortunately at the end of last page)
I have thought a bit more about a cube-planet.

​

It just hits that level of detail that is currently rendered.

lowest-loaded = Blocks -> damages blocks.
lowest-loaded = Chunk -> damages chunk; Not generated chunks have an average HP value.
Or just make a crater in the high-map and modify the damage overlay colour for this part. This affects how lower detail is generated once visited.
lowest-loaded-detail-level = 16*16 Chunk (see above)

If you want exact orbital fire, you have to load the chunks by zooming in.

To see something in high-resolution from distance, you have to pay :
2D resolutionIncrease = (scanTime * (scannerPower)^diminishingReturns )
2D resolutionIncrease = (scanTime * (scannerPower)^diminishingReturns )^0.5

They are generated based on parameterized input from damage|resource|modification-overlays.

damage|resource|modification = 0..16 or 0..255 per "raster-unit"
The raster may store time of last visit and erase damage as result of earth-quakes or natural growing plants, ...
Craters may influence the distribution of high below the highmap, but the planet may regenerate from some damage.

Another idea would be to make the orbit >2km thus preventing ships from firing at the surface.

There could be ballistic fire which can only be fired at loaded blocks.

If you or an projectile enters/leaves the planet radius :

  float3 lp := lastPosition
  float3 cp := currentPosition
  float3 cpr := cp^2 - planetPosition^2 // current position relative to the planet
  ..enter if(( ~inPlanet && planet.radius^2 > cpr{x*x + y*y + z*z} ))
     // subtract sector rotation
     // divide through sector scale (*1/factor == faster *1*multiplier)
     lpr := lp^2 - planetPosition^2 // last position relative to the planet
     // multiply with sector scale
     // add sector rotation
  ..enter
  ..leave else if(( inPlanet && planet.radius^2 < cpr{x*x + y*y + z*z} ))
     // subtract planet rotation
     // divide through planet scale (*1/factor == faster *1*multiplier)
     lpr := lp^2 + planetPosition^2 // last position relative to the planet
     // multiply with sector scale
     // add planet rotation
  ..leave
    // commented out parts (green) are calculated when entering planet sectors
    // or not needed as scale will probably be 1.

Usually the glitches happen by dividing. Multiplying with the 1/factor value could help.
Else try to get the position of the planet relative to the ship by

1. NOT getting the planet in the ship's coordiante system
2. but the ship into the planet's coordinate system (same calculations as with projectiles fired at the planet)

Then you need to translate the ship's position and rotation with (-value) to the planet's position relative to the ship
2nd are calculations which don't produce glitches like a divsion does.
That should put the very same glitches on the planet position on your screen as it does on projectiles entering it, thus negating the effect of glitches.

As it is not reasonable to hit a static target on a rotating+moving planet orbiting a rotating+moving sun with all the gravity influences from other planets, moons and the universe, I think it is realistic to just ignore the ability to exactly hit from outside a planet's orbit (said orbit, not gravity sphere )
I hope this gives some new Input

I have thought a bit more about a cube-planet.

What it needs to make it nice.​

And I had the idea of a bumped cube.

You have 6 sides.​

Blocks are perfectly aligned.​

It is optimal to handle for a block based game.​

Now decrease the size of corner-blocks with a multiplier of about 0.85
. and increase the size of centre blocks with a multiplier of about 1.15

and you get very close to a sphere.​

The corner blocks could just have:

Planet Right : Top = EdgeBlock Right
Planet Top : Top = EdgeBlock Top​

- - - ↓ ↓
- \ ↓ T T ↓ /
- → X T T X ←
→ L L - - R R ←
→ L L - - R R ←
- → X B B X ←
- / ↑ B B ↑ \
- - - ↑ ↑

For a player it may look like:
↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓ ↓
T T ↓ ↓ R R ↓ ↓ T T ↓ ↓ R R ↓ ↓ T T
T T X X R R X X B B X X L L X X T T​