If you have even one vertex, it won't work. At a vertex, three or more polygons join at angles to one another. Voxels cannot join at angles to one another. If they do, they're not seamless. They're like the dodecahedron planets. If you're wanting to make the sphere large enough to make these angles between the voxels negligible, it's just going to be too big. On top of that, you'll have the issues with blocks getting bigger off the surface and smaller underground. Voxels really only work on a flat map. All 3d map approaches require the voxels to become non-cubic or to have seams between segments, else render things in a way that they are not.
My approach does not create a sphere or a 3d figure of any sort. It creates a flat map, and renders part of that map tangent to a part of a curved surface for each client. It's like Minecraft where each client handles which chunks it can see (on a flat map) and which ones it asks the server for.
The "sphere" is a texture seen from orbit, and it is the shape of the entry point into this environment. It is not the shape of the map. The map is not shaped like a sphere. It is flat, allowing voxels to exist on it as perfect, seamless cubes.
In short, the map I propose is not a sphere because it cannot be both a sphere and an undistorted voxel map, but it is presented in a way that makes it feel and function like a sphere.
I think I get what your problem is. You think that the voxels need to be perfect cubes. They don't. In fact for this you don't want that. The surface furthest out from the planet core is going to be slightly larger. This is purely dealing with the generated surface.
To build a building you could select say a field of these surfaces and set them so that they are on the same plane. This giving you a modified area for building. You know sort of like you do in real life when you level an area before building something.
To put this in better perspective. Earths radius is 6,371,000 meters. So if you made a 1 meter block you couldn't detect the difference between the size of the top of the block and the bottom of the block by just looking at it.
You would have to dig a long ways down to be able to visually determine the difference in size of blocks over a million meters. I don't seen a need to allow digging beyond few hundred meters down.
To make use of this you select a large number of these and assign them as a field giving them a level surface shared between the top of all of them. You could then build with perfectly square voxels on top of that to build buildings and such.
So yes the planet voxels are not perfectly square they don't need to be though either.
I think I get what your problem is. You think that the voxels need to be perfect cubes. They don't. In fact for this you don't want that. The surface furthest out from the planet core is going to be slightly larger. This is purely dealing with the generated surface.
To build a building you could select say a field of these surfaces and set them so that they are on the same plane. This giving you a modified area for building. You know sort of like you do in real life when you level an area before building something.
To put this in better perspective. Earths radius is 6,371,000 meters. So if you made a 1 meter block you couldn't detect the difference between the size of the top of the block and the bottom of the block by just looking at it.
You would have to dig a long ways down to be able to visually determine the difference in size of blocks over a million meters. I don't seen a need to allow digging beyond few hundred meters down.
To make use of this you select a large number of these and assign them as a field giving them a level surface shared between the top of all of them. You could then build with perfectly square voxels on top of that to build buildings and such.
So yes the planet voxels are not perfectly square they don't need to be though either.
Yes you could do it on a 1okm planet. The only disadvantage to the smaller planet is that voxels will be fore visibly different in size top to bottom. However even on a 10 Km planet the difference would be 1 meter top and .9999 meters bottom roughly.
Using the build plane/ field would allow building on any size planet.
That said why limit myself to 10Km
I'd rather do it on a planet that is larger than that. Earths radius is 6371Km Why would
It isn't as if you have to store every single voxel for the planet you store only the ones that change or the ones that are added and their position relative to the planet. You only generate what you are seeing and near surrounding areas so when you move it doesn't pop.
Yes you could do it on a 1okm planet. The only disadvantage to the smaller planet is that voxels will be fore visibly different in size top to bottom. However even on a 10 Km planet the difference would be 1 meter top and .9999 meters bottom roughly.
Using the build plane/ field would allow building on any size planet.
That said why limit myself to 10Km
I'd rather do it on a planet that is larger than that. Earths radius is 6371Km Why would
It isn't as if you have to store every single voxel for the planet you store only the ones that change or the ones that are added and their position relative to the planet. You only generate what you are seeing and near surrounding areas so when you move it doesn't pop.
Why limit? I'm not sure full-scale planets fit Starmade's theme. In any case, I doubt it'd be very fun to play on a planet where you would land and never find another person. Starmade seems to favor interaction a bit more than that. We'd have to get a word from one of the devs to be sure about this, but I conjecture that full-scale planets are not a goal for starmade.
What if two people build two 1km^2 cities 1 km apart, then decide to connect the two with a road? There will be problems unless the plate is joined. Ok so we join the plates and make a 1x3km plate. Now the plate is about 1/10 the circumference of the planet. Now some kid thinks it'd be fun to build a road clear around the world and back, so he starts building. Halfway done, the plate is sticking out into space 90* out of phase with the surface on both sides.
In the case of my model, none of these things would cause any problems. Yours works better for full scale planets in some ways, while mine works better when constructions take up a non-trivial amount of a planet's surface as would likely be the case in Starmade.
Why limit? I'm not sure full-scale planets fit Starmade's theme. In any case, I doubt it'd be very fun to play on a planet where you would land and never find another person. Starmade seems to favor interaction a bit more than that. We'd have to get a word from one of the devs to be sure about this, but I conjecture that full-scale planets are not a goal for starmade.
What if two people build two 1km^2 cities 1 km apart, then decide to connect the two with a road? There will be problems unless the plate is joined. Ok so we join the plates and make a 1x3km plate. Now the plate is about 1/10 the circumference of the planet. Now some kid thinks it'd be fun to build a road clear around the world and back, so he starts building. Halfway done, the plate is sticking out into space 90* out of phase with the surface on both sides.
In the case of my model, none of these things would cause any problems. Yours works better for full scale planets in some ways, while mine works better when constructions take up a non-trivial amount of a planet's surface as would likely be the case in Starmade.
First, off it is a game. It already simulates technology we don't currently have. It wouldn't be hard to assume you have a life/ science detection system. Right now you could take off to the outer edged of the galaxy and it could be quite some time before anyone finds you if ever.
As to the 2 cities roads could be built with little issue between the cities. you could even convert the land between the two cities to another field and connect the cities.
Think about what you could do if your blocks could be used for building both in the field plane and outside. We already discussed you couldn't visually see the difference in the blocks and there wouldn't be a gap between those in the plane and those outside. So all that would happen is when you step outside the vertical plane building area your blocks get put down aligning to the blocks around it.
In short just think of everything as using two types of voxels.
1. is the one used to fit in with the planet.
2. is a standard cube voxel used inside build areas, space craft,stations,asteroids...
First, off it is a game. It already simulates technology we don't currently have. It wouldn't be hard to assume you have a life/ science detection system. Right now you could take off to the outer edged of the galaxy and it could be quite some time before anyone finds you if ever.
As to the 2 cities roads could be built with little issue between the cities. you could even convert the land between the two cities to another field and connect the cities.
Think about what you could do if your blocks could be used for building both in the field plane and outside. We already discussed you couldn't visually see the difference in the blocks and there wouldn't be a gap between those in the plane and those outside. So all that would happen is when you step outside the vertical plane building area your blocks get put down aligning to the blocks around it.
In short just think of everything as using two types of voxels.
1. is the one used to fit in with the planet.
2. is a standard cube voxel used inside build areas, space craft,stations,asteroids...
Like I said, this works fine if the planets are full scale because no one will build anything that covers a non-trivial portion of the surface (no normal player will be able to build halfway around the planet). Two cities 10km apart could join with no issues. If the devs want to make planets astronomically large like that, they may choose this method over mine, or they may not. Who knows? Personally I wouldn't want to write the code to deal with two building areas that end up colliding, nor would I want to play in an area where players caused that or where they might cause that. I chose a model that is ideal at smaller scale because I thought it unlikely that Starmade's sectors would be expanded to the size of Earth to accommodate a planet that size.
There are two reasons I would prefer 10km-scale planets over astronomical ones. In my opinion, 10km-scale planets would be more fun for starmade because there is a greater opportunity for interaction on the surface. Starmade is its own universe which may have its own physical laws provided they make sense and resemble the real world (we already have jump drives after all). I think I would enjoy multi-kilometer planets more than I would astronomical ones. It's a gameplay decision.
The other reason is that after a certain point, adding more size to the planet adds very little to its value. A 10km diameter planet would still have more surface area than the world of a typical Minecraft server. In my opinion, that's enough. I don't see a purpose to having more on ONE planet. Even 10km wide might be a whisker on the excessive side if you compare it to a Minecraft world.
If Schema is interested in making seamless planets, the devs will choose between multi-kilometer and full-scale planets based on player input, design choices, and the flavor they want to give the game. I suspect kilometer scale is closer to the intended flavor, but who am I to say?
Yours and mine are two different models created with two different situations in mind and are difficult to compare or apply to a similar purpose. Mine works at full scale, but is strange because the distance to the equator is significantly different in different directions. This is a small price to pay at 10km scale because the distances aren't large. Yours works at 10km scale, but only if no one builds too big. This isn't much of an issue at full scale because no one can build anything big enough to cause strange things to happen.
Like I said, this works fine if the planets are full scale because no one will build anything that covers a non-trivial portion of the surface (no normal player will be able to build halfway around the planet). Two cities 10km apart could join with no issues. If the devs want to make planets astronomically large like that, they may choose this method over mine, or they may not. Who knows? Personally I wouldn't want to write the code to deal with two building areas that end up colliding, nor would I want to play in an area where players caused that or where they might cause that. I chose a model that is ideal at smaller scale because I thought it unlikely that Starmade's sectors would be expanded to the size of Earth to accommodate a planet that size.
There are two reasons I would prefer 10km-scale planets over astronomical ones. In my opinion, 10km-scale planets would be more fun for starmade because there is a greater opportunity for interaction on the surface. Starmade is its own universe which may have its own physical laws provided they make sense and resemble the real world (we already have jump drives after all). I think I would enjoy multi-kilometer planets more than I would astronomical ones. It's a gameplay decision.
The other reason is that after a certain point, adding more size to the planet adds very little to its value. A 10km diameter planet would still have more surface area than the world of a typical Minecraft server. In my opinion, that's enough. I don't see a purpose to having more on ONE planet. Even 10km wide might be a whisker on the excessive side if you compare it to a Minecraft world.
If Schema is interested in making seamless planets, the devs will choose between multi-kilometer and full-scale planets based on player input, design choices, and the flavor they want to give the game. I suspect kilometer scale is closer to the intended flavor, but who am I to say?
Yours and mine are two different models created with two different situations in mind and are difficult to compare or apply to a similar purpose. Mine works at full scale, but is strange because the distance to the equator is significantly different in different directions. This is a small price to pay at 10km scale because the distances aren't large. Yours works at 10km scale, but only if no one builds too big. This isn't much of an issue at full scale because no one can build anything big enough to cause strange things to happen.
While I respect your opinion you seem to have missed the point. Planests quite small could still be made with little issue.
Think about the math. If you draw a line from the surface to the core you have the radius. Then if you step along that line in 1 meter increments the change is very small. You would have to make very small planets for it not to work. Even at just 1k 1 block only looses 0.1 cm top to bottom. At 10K it is 0.01cm ...
The build area and transitioning between it could be done extremely easily. The only thing the build plane/field would do is ensure the surfaces inside those area share the same plain. Thus land connecting to it uses the exact same vertices. Essentially it builds a box above that.
There is only two checks in the code that is needed. That would be are you building on the planet surface or is it in a build box.
If you are building on the planet surface code uses vertices to determine voxel shape. If in build box or not on surface of planet use standard voxel shape.
I think you do like 90% of the programmers I have taught over the years you make it far to complicated in your head.
While I respect your opinion you seem to have missed the point. Planests quite small could still be made with little issue.
Think about the math. If you draw a line from the surface to the core you have the radius. Then if you step along that line in 1 meter increments the change is very small. You would have to make very small planets for it not to work. Even at just 1k 1 block only looses 0.1 cm top to bottom. At 10K it is 0.01cm ...
The build area and transitioning between it could be done extremely easily. The only thing the build plane/field would do is ensure the surfaces inside those area share the same plain. Thus land connecting to it uses the exact same vertices. Essentially it builds a box above that.
There is only two checks in the code that is needed. That would be are you building on the planet surface or is it in a build box.
If you are building on the planet surface code uses vertices to determine voxel shape. If in build box or not on surface of planet use standard voxel shape.
I think you do like 90% of the programmers I have taught over the years you make it far to complicated in your head.
It is something to be considered if the transitions from surface to building box can be smoothed out that much. As a player, I'm not sure I would like to deal with the building boxes though. I know it can be done, but I don't care for it on planets of a scale we're likely to see in Starmade. I'm too much of a neat freak with blocks and I might want to build a rail tram clear around the planet. What I'm saying is, both models have trade-offs because no model for putting voxels on the surface of a sphere can be truly perfect, and I prefer the specific tradeoffs that the parallelogram map offers in this case. I'm not trying to put down you idea. In fact I would prefer yours over mine on full-scale planets. However, I like mine better for planets of non-astronomical sizes. I'm not worried about tall things. I'm worried about things that stretch around the planet.
It is something to be considered if the transitions from surface to building box can be smoothed out that much. As a player, I'm not sure I would like to deal with the building boxes though. I know it can be done, but I don't care for it on planets of a scale we're likely to see in Starmade. I'm too much of a neat freak with blocks and I might want to build a rail tram clear around the planet. What I'm saying is, both models have trade-offs because no model for putting voxels on the surface of a sphere can be truly perfect, and I prefer the specific tradeoffs that the parallelogram map offers in this case. I'm not trying to put down you idea. In fact I would prefer yours over mine on full-scale planets. However, I like mine better for planets of non-astronomical sizes. I'm not worried about tall things. I'm worried about things that stretch around the planet.
The idea is you use which ever build system is best for what you are building.
The tram system is a perfect example. While it passes through the city you would want it level with the blocks in the city. As it exits the city it would switch to the normal world blocks. By doing that it would give a smooth contour around the planet. The only change would be in if you changed elevation for some reason. Since you are using the vertices for the blocks on the world coordinate system it means the blocks will align regardless.
Maybe, I can rebuild my previous work using opengl 3.3+ and make a demo. Not sure how long that is going to take though with my other projects.
OK, so here's the model I have for allowing interaction between outside space and the two-triangle/parallelogram map. I'll cover this in two sections: How it works, and how to make it feel right.
How it works:
There is no block distortion
Spatial distortion occurs within the planet sector to increase immersion
Making the planet appear round is done with rendering tricks by inserting objects into triangle space at an angle that makes them feel like they kept their same angle from outside. This transition is somewhat comparable to entering a rotating planet sector but more complicated.
Crossing the boundary is something like this. You have to get from cubic space to a sector shaped like two of these:
To do that, you have to determine the position at which the ship will enter this sector. Here's how I would do it, although there may be a better way:
Take two angles relative to the sector center to determine the craft or projectile's position on the projected/illusory sphere.
First pick the hemisphere the craft will enter based on entry angle/position. From the horizontal angle, draw a line to the equator. The craft will enter along this line. To determine where, compare the ratio of the vertical angle to 90* and go that fraction of the line's length "up" toward the pole. Translate this position into a position in the double-triangle sector and the ship/projectile enters at this point.
The angle at which a ship enters should feel as though angle relative to the planet does not change at the moment it crosses the boundary. I'm not sure how to work the math for that right now. It would take me too long to figure out and Schine would probably have to come up with a more program-friendly way to do it.
As you advance downward, the surface will begin to load.
Making it feel right:
Now we've made it across the sector boundary. Making that part feel right is as simple or complicated as rendering the planet in front of you as a "ghost image" of a sphere, textured to look like the actual surface of the planet. Some tricks will have to be used to project things onto this surface at a more-or-less consistent size, but I expect that is quite doable.
Now this is a little odd. We're flying around a "sphere" but there's no difference in the distance based on altitude. Either this can be left as is, or ships can be made to fly more slowly relative to the surface the closer they are to the sector boundary. There's one more problem. We appear to be flying around a sphere, but another ship that just flew into the opposite side of the planet appears directly in front of us... ??? That's no good. I know there's some complicated stuff here, but the end result needs to be that the ship looks like it's on the opposite side of the ghost image when it's on the opposite side of the planet map (help! I need a mathematician!).
From here, we begin entering an area of special relativity. As we descend, the "ghost" planet appears to approach below until we hit the atmosphere. After entering the atmosphere, the planet appears flat and terrain loads below. A radar blip on the opposite side of the planet now appears directly in front or behind or wherever depending on the shortest line to it. In other words, it now appears to be where it actually is on the flat map.
Ultimately, all distortions are done by rendering and a bit of alteration of weapon shot trajectories when fired within the sector and above the surface. Alternatively, if an aiming reticule for "leading" aim on a moving target is introduced, this becomes easier as weapons don't really have to fly straight. The aiming reticule can put put the the real location and shots can be seen curving out of sight around the planet due to gravity. That would be strange for beams, though. On the other hand, beams hitscan so as long as there's line of sight past the planet, the beam could just be rendered as a straight line from weapon to target from all reference points.
There may be other ways of doing it, but I recommend using a line of sight check around the pseudo sphere to decide sensor range. This would be determined from the highest altitude and the range would be retained down to the surface... I hope that wording makes sense.
One final problem arises: planetary bombardment. When weapon fire comes in, the chunks to be hit must be loaded to make damage calculations on their blocks. It's not a problem if there are people near the surface and that part of the surface is already loaded, but bombarding previously unloaded chunks could get REALLY CPU intensive on the server side if not coded carefully. Here's what I suggest:
Ignore any shot or spray of shots that wouldn't even destroy one block. Assume such small weapons fire cannot penetrate the atmosphere.
Queue up shots flying toward an area of the surface. Every few seconds, load up the needed chunks server-side and register hits as the CPU has time to do so.
Do not load the "hit" chunks to the client of course, as the client isn't close enough to need them. If it were, they would be loaded already.
To make it look right client-side, add small explosion or fire effects to the pseudo sphere texture. These should appear at approximately the time weapons fire might have hit the surface if the queue hadn't "grabbed" it.
As I'm an inexperienced coder and have little knowledge of the engine, I have no way of knowing how well any of this will perform, but I think it is a reasonable conjecture that it could be made to work. I'll restate this one more time: all distortion should be handled by rendering and special entrance/exit algorithms for the sector. This is many times better than trying to squish a polyhedron into a messed-up sphere.
The points labeled N and S are north and south poles.
When entering the sector, something like this will happen:
A similar process would find longitude based on angle from the meridians.
Nothing happens to the walls of Santa's house. They are a square on a flat map. Client-side the part of the world you're standing on is perfectly flatand square as I described above. You're dropped onto the sphere and a section of the flat map loads under you feet tangent to the sphere. As you walk, the angle of the flat segment changes, remaining tangent to the sphere directly under your feet.
EDIT: I just realized that this gives two equators, the "torus world" described in that video. I'll have to do some more re-thinking.
Why? This discussion is fascinating, I even understand some of it.
I think if we let the 2 of them go at this long enough, we will get the perfect solution, and then Schine just needs to implement it.
Why? This discussion is fascinating, I even understand some of it.
I think if we let the 2 of them go at this long enough, we will get the perfect solution, and then Schine just needs to implement it.
Or rather, we'll get two good solutions with different tradeoffs and Schine will choose and implement the one they prefer, which is likely what will happen now if the devs consider either of these solutions feasible.
It seems like some people find the ideas here to be somewhat over their heads. If there's anything unclear or hard to understand, feel free to ask and I'll explain my thoughts on the matter.
Is(I assume it is)the massive number of cubes and all their data what makes large planets so laggy?
What makes them difficult to make work at all is the geometry, though.
Even if it could work, a bigger problem is just that it could become too big. At speeds people will travel at(150 speed setting, x2 for overdrive, = 300), will you be able to load it all? And will you be able to interact ideally with players?
I do agree about planets getting dwarfed by ships being a problem, my third mining ship on my newest save(quite a bit of hollow space to make a grid of salvagers, with a shell made out of rock) was just too big in comparison with the plate(r31 I think?).
I play with default planets and have to wait like 30 seconds/a minute to load, but it's okay once I've loaded(loading screen without the screen, lol).
Gameplay problems of huge planets is another problem.
If Schema had had all the time in the world(which he does NOT, lol), I would be giddy having non-block and block planets of all shapes and sizes. But, we probably won't.
Having some non-block planets the size of Earth might be nice, so long as we can interact seamlessly(shooting/mining/building).
TLDR; With some shortcomings, maybe big(but perhaps non-cube) planets sound like they might be viable. I'm no programmer.
This might cause inherent gameplay problems, however.
What can't be loaded at that speed would be simulated with a texture or low-poly mesh. It'd be OK. That part is just a matter of "Does Schine like the possibilities and want to make it happen?"
If I understand your question, planets would ultimately be the same deal as the rest of the universe. Despite all the funny stuff going on in the backend, the experience would ultimately be almost indistinguishable from actually landing on a sphere.
Yeah, I've noticed this too and I think that's mostly because:
A bit too much planet is trying to load at once. We shouldn't need more than 0.25 square km of voxel surface at once per player, but the game currently creates the entire planet at once.
The underground is generating when it doesn't need to.
The engine is in alpha so maximum generator optimization is not yet possible.
To solve that I think the game should:
Use a low-poly mesh or flat texture instead of rendering voxels in the distance.
Generate only the visible surface unless someone starts digging.
Take a lot of time optimizing when the engine nears completion. (I know this is probably a pain for our favorite dev team, but I'm afraid optimization is something you don't see enough of in modern software.)
Only one of the dev team with knowledge of the engine and possible changes to it can give us an idea how effective these improvements would be.
Is(I assume it is)the massive number of cubes and all their data what makes large planets so laggy?
What makes them difficult to make work at all is the geometry, though.
Even if it could work, a bigger problem is just that it could become too big. At speeds people will travel at(150 speed setting, x2 for overdrive, = 300), will you be able to load it all? And will you be able to interact ideally with players?
I do agree about planets getting dwarfed by ships being a problem, my third mining ship on my newest save(quite a bit of hollow space to make a grid of salvagers, with a shell made out of rock) was just too big in comparison with the plate(r31 I think?).
I play with default planets and have to wait like 30 seconds/a minute to load, but it's okay once I've loaded(loading screen without the screen, lol).
Gameplay problems of huge planets is another problem.
If Schema had had all the time in the world(which he does NOT, lol), I would be giddy having non-block and block planets of all shapes and sizes. But, we probably won't.
Having some non-block planets the size of Earth might be nice, so long as we can interact seamlessly(shooting/mining/building).
TLDR; With some shortcomings, maybe big(but perhaps non-cube) planets sound like they might be viable. I'm no programmer.
This might cause inherent gameplay problems, however.
There are faster methods of generating surfaces and planets than what is used here. The biggest problem that this system has is LOD isn't really put to use. IT has for all intents and purposes 3 states the state the planet is in when nothing but the core is loaded. It has a storage of all the blocks on each plate and renders some times partial amounts of those depending on your distance.
A faster method would be to create a base surface call it the mantel that and you can't dig below this point. Then generate a high map field that is able to be pushed to used with LOD and then you could render when close enough the actual cubes and not before hand.
This allows you to render various amounts of detail based on distance and you could even factor speed in to reduce polygon count because less detail would be visible.
As for determining what is below ground you could do that as it is exposed.
There are a number of good resources for people wanting to learn something about the topic. http://vterrain.org/
Is a good place to start.
If you have Earth-sized planets, you might not be able to find/fight other players in a reasonable manner, and you might have way too many resources.
1KM diameter or so might be fine. And one gigantic planet near the core of each galaxy might be cool too.
Others would probably have more ideas why we don't want planets to be 10KM wide.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
