(Ok so, there was about 20,000 posts that were posted between the time when I began writing this and now. And if I keep trying to keep up, I'll never post this.. So, don't be surprised if a few posts aren't mentioned in there!)
@OP:
Yes, I also think the planets are somewhat disappointing. But mainly because of the plate edges.. I keep falling in-between them, and they prohibit building relatively large underground structures. Not to mention when you're building planetbound "hovercrafts", crossing the plate to plate boundary is a nightmare XD
But about your suggestion, there is the issue with planets with little to no atmosphere, like moons, which were confirmed a while ago. And, isolating planets partially might be a solution, but it would disrupt the flow of the game significantly, and pose issues for people wanting to bombard bases from orbit, and etc.. So I don't think isolating planets like that would be such a good idea..
Probably that a good chunk of planet issues could be mitigated by making them bigger though. But that worsen some existing problems and bring others.
Large planets orbits (300+) overlaps into nearby systems because systems are too small. And of course the performance issues. Having fewer systems in the universe in exchange for larger systems would be a sensible tradeoff for the first issue IMO. Nobody is going to live long enough to explore all those stars anyways..
Figuring out the cause of the immense performance drop linked to planets would be a must though. Its apparently the CPU being the bottleneck, and on client side mainly. I setup a server on another computer, and looked at CPU load on both computers when coming close to and generating planets for the first time. The result was that the server had a mild CPU hit for a couple of seconds ( Phenom 955 X4 + 4GB DDR2), while the client ( FX-8320 3.5ghz + 16GB DDR3 + GeForce GTX 550Ti ) had a constant CPU hit whenever it got within a certain distance of the planet
Perhaps you're newer than my better judgement tells me you are, but I would recommend you first read
this very old thread by Schema himself on why planets are the way they are (FYI that thread is older than the implementation of dodecahedron planets, which is why it does not mention them)
There is no feasible way to make planets seamless. Check the link I provided at the beginning of this post and you will see why.
That's a neat link !
And that idea he used to turn the planar planets into a sphere looks like its pure genius ! I'm curious about what he was having so much issues with. He didn't give any real specifics sadly..
I wonder what trick he used too? It can't be a simple render target onto a sphere, since we can see things from the side against the starry backdrop at the top of the planet..
And I beg to differ, there are ways to pull off something like that.
I've seen a lot of crazy things being implemented in the face of engine restrictions. For one, the way the Source engine mod Eternal Silence does to have both space battles in a big environment, and FPS segments aboard ships and stations, bypassing the small map size limit of the engine. They literally shrunk the player and his ship once he'd get out of a ship hangar! And the opposite when he'd get back in. And the transition was seamless really, no way to tell you were being teleported from one box to the other, and that your ship model changed!
But I digress.
Back to the spherical planets. Texture mapping, something that has existed for decades now in most 3D game engines and 3D software, does the very same thing that would be needed to make a planet like this. Its quite possible Schema just dismissed the approach at the time, because it seemed too complicated for nothing when there were other quicker alternatives probably.
For instance, if you take a sphere in a 3D environment and apply a texture to it, its exactly that. The texture is a plane(the actual planet), the object is a sphere(the "faked" planet).
There's a lot more that can be done with this. For example, its possible to map relief to a specific point on a sphere, by using bump/height maps, normal maps, etc..
The math behind this is pretty "simple", and very commonly used. The map is in a specific 3d coordinate system u/v/w, the sphere in another x/y/z. So you just use a matrix to convert from one system to the other the corresponding vertices from the u/v/w system to vertices in the x/y/z system. And there you are.
You'd probably want an interface for tracing rays and hulls down to the planet's surface. Coordinates of the ray's impact point would get translated to the plane's coordinates, for things like weapon shots and etc.. This could also be used to determine what chunks and blocks are visible.
As for the magnifying artifacts, submitting anything getting within range of the planet to a similar effect, would suffice. It would require some thinking depending on how LWJGL handles that. I'd assume the code for anchoring objects getting near a planet to the planet's local gravity could also be used as a vector to handle this effect, and the transition in-between.
Or, isolating the planet inside a box with render targets on each inside faces would allow to conserve more control on coherence with the surroundings of the planet. Handling occlusion culling on the seams when digging might be a bit tricky though, but nothing obviously infinitely complicated AFAIK. Might require some hacks..
You probably should also watch this video from SIGGRAPH 2007 :
Its a demo of the tech behind the planet engine of the game Spore. Basically, its a plane mapped to a sphere.
Loading planets is not that difficult a thing to do. I get perhaps you might be stuck with a toaster computer (I presume that's what motivated you to make this thread) but that doesn't mean everyone else should be forced to play the game to the same performance expectations as what you're wanting here. Lower your raylightcalc values and segment rendering numbers and you will be just fine with planets. If it's still too laggy you just need to get a better computer, and stop playing on servers with such large planets.
The thing is, you can turn down your graphics settings to the minimum, and your game will still choke. Especially with ice planets. Its because its not a graphics issues in itself. The CPU appears to be the bottleneck everytimes.
In comparison, I got a 8 core AMD FX-8320 3.5ghz with 16 GB of ram DDR3 and a GeForce GTX 550 Ti. The CPU stays at 75% load, and the chunks load and unload like crazy. I got everything set to the minimum, no shadows, fast dynamic lighting enabled, atmosphere shader disabled, vierw distance 1500 (default), and even system rotation disabled (planets don't rotate).
As a result, I go near a red planet, and I got 128 FPS, instead of the 240 I get everywhere else (I locked framerate at 240), but the game still chokes. The chunks keep loading and unloading like crazy. Its not an isolated incident either. Performance issues are mentioned everywhere, especially in steam reviews from random people.
It tends to get better after spending a while on the planet, but it can come back, when going back to space. It tends to affect only planets past a certain size too. The tiniest ones don't seem to cause issues on my end.
Besides that, I'm still not sure what triggers all this..
There is no solution. That's what I'm trying to tell you.
I wouldn't say that.. Personal incredulity does not constitute a fact. You should nuance that, because it sounds awfully like a fallacy.
You know, StarMade is actually impossible. A voxel based game of that scale ? Unthinkably inefficient!
Coded in Java at that! True lunacy !
That's pretty much what you'd have heard a few years ago...
Its like people that thought we'd never get to space.. And to say some still think we never did..
If planets that large were able to work just fine, i'd be all for it. But they don't. So i'm against implementing them.
We'll just have to see what the devs do. If they find some sort of soplution that allows StarMade to do this easily, then I would definitely support pursuing this.
Doesn't implementing larger planets require that the devs make them work ?
Thus... you're.. really ok with it ?
You want what is not feasibly possible. But I do admit that if it WAS possible, it would be interesting. But the data and processing limitations on our modern-day computers and the nature of what you're asking for is something too stressful for the game to bear.
[...]
I don't, and here's why. It's because I've learned to be fairly content with how StarMade planets are. They're large enough as they are. You can say you want to see 5-kilometer-wide planets, but that's purely based on your own personal desire, and your mere desire is not a good enough reason for implementing such such a performance-costly mechanic. The drawbacks vastly outweigh the benefits on this.
Pardon the assumption, is it possible you'd like to have some of those things in the game, but since you're more or less "white knighting" the devs, you won't allow yourself to ? :/ (It seems like a pretty common thing going on around here though.. Especially in the suggestion sub-forums..)
Because, I doubt the devs really care if people makes suggestions that are completely out of the realm of possibility. They probably welcome it if anything. They didn't even put any measures to disallow that.
From my own experience, suggestions are used more as a grabbag or somewhat like a brainstorm. Not to mention, they're not obligated to implement anyone's idea as-is.
So, really, nobody should be afraid of restraining themselves on that topic really.
Now, while I do not agree with several things Valiant said, and while you brought some good points, you're extrapolating a lot on your end, making claims about the game's capacity to be optimized that you have no ways of truly backing up.
For example:
[...]Because I can tell you right now that no amount of optimizations could ever make something like a sector-sized planet function comfortably and efficiently on StarMade.
First, that could be potentially easier to handle, because less of the planet would be drawn at any time, and less of the planet would fit in the screen, thus you're not dealing with things almost on the other side of the planet that are barely visible. Then, more classical approaches for managing, and smoothing out view distances become viable, because the planet has a more considerable size.
Besides, if that doesn't work, a sector with a single huge planet could be optimized to lend itself better for this. Optimization can be pushed a lot more on very specific cases with little variations.
Secondly, nobody can truly guess how much optimization can be done (other than the very obvious), without access to the source code directly and giving it a try. Even what the devs say is not necessarily accurate. Because, its quite possible the devs have better things to do than optimization right now, or perhaps they don't have the know-how to make that call accurately, or maybe the devs just didn't come across the "inspiration" yet.
Optimization is a funny thing. You can push things extremely far if you want, writing straight into actual x86 assembly if needed.
For example, there's the demoscene which is almost entirely focused on optimizing the crap out of their code and reducing the size of their executable further than anyone would dare consider possible. Having a massive 3D environment run from a 4kb executable is nothing short of black magic !
And on the CPU side of things, when you write a program, especially in Java, you'll almost always end up with some redundant, or useless processing being done, within a certain measure.
