Oh, so you just don’t know yet. When you set Albedo Tex or Height Tex for the planet while you have other planet in the scene, both change to those textures and start to rerender chunks as such when you move camera. At least on big planets, but I guess it happens on all.
Also noticed enlarging your demo planets without changing biome settings really doesn’t cause artifacts and doesn’t degrade performance. That’s a good thing to know. Maybe that’s why it seemed like we’re using different assets. This depends on settings then.
If I may, I’ll send you private message maybe tomorrow with some points that might be useful to consider in that global tex + biome approach.
Would send you a video of maybe quite impressive results, maybe even unique, but with a few visual errors/glitches that arise with some settings (global tex and biome). Even provide the scene if you’d want. If you’d be able to make this approach less glitchy while working on bigger planets would be great.
@Frpmta
I see, this is in a scenario where you have multiple planets very close to each other right? Like almost touching, where the LOD of each would be constantly updating. In this scenario you’re right, they would all be trying to update at similar rates to each other and slow the system down.
In one of the recent versions I added the SgtSphereLandscape.LodBudget setting, which allows you to more precisely limit the time spent updating LOD. So to fix your scenario it would be easiest to have a global Lod Budget manager that shares the total budget among all planets based on the camera proximity, and this would also be fairly easy to implement, so I’ll add it to the to-do list.
The contour you mention is caused by the downscaling of the clouds. In the Demo UI GameObject you have the Volume Manager GameObject and component, and you can set the Downscale value to 1 to eliminate this. If I can get the silhouettes to work nicely with downscaled clouds then that would be awesome, but it’s a little tricky to get it working in all scenarios.
@Eltharis1
Oh I see, now that is strange. I only tested copy + pasting multiple planet scenes together which does seem to work, but when you move and cause the LOD to update separately there is some kind of sharing of data that causes them to update with the wrong textures. I’ll fix it shortly. [Edit] I’ve now fixed this issue, and I’ll submit a fix.
Sure, feel free to send any videos or ideas you have!
Exactly, that’s the issue I have. Planets that are too close go crazy with LOD updating.
@Darkcoder1 Some people in the reviews are angry they reported these issues reported by me and @Eltharis1 long ago.
But in your defense, I’d say it is the fault of people using Reviews to report bugs believing that to be more efficient instead of coming in here I have noticed lately it often comes off as blackmail haha.
Yeah, I can’t be bothered to read reviews because they’re either 5 stars amazing or 1 star it sucks. I’d rather spend my time gradually improving this stuff. If Unity can have billions of dollars and a 7 month response time to basic requests then asset devs should get way more leeway xD Maybe I should make a Chat GPT bot that auto replies to everything and collates any issues to save me a lot of time, hmm.
Speaking of improvements, I managed to get overlapping clouds working pretty well. Clouds of other distant planets still disappear when entering clouds, but there isn’t much I can do without making the memory usage increase a lot per cloud:
Darkcoder, any chance in the near future you can implement a weather system? Rain, thunder, snow, etc?
I know it was proposed already, but what are the chances we’ll see light/godrays like in Star Citizen?
And as far as planet sizes go, couldn’t we just scale down our player/ships? Since it works much better on smaller scale planets, why we can’t just scale our assets down? Star Citizen actually uses very tiny (not real world scale) planets and moons. What is the maximum threshold until things get wonky (in KM)?
I had an idea for making the “massive floating objects” work with Planet Forge. From far away, load the old SGT planet until the player gets close and it unhides the Planet Forge planet in place of the SGT planet when the player gets close.
I’m encountering a strange problem. Whenever I use my own textures for a biome layer height map, the displacement doesn’t work.
Specifically I want to use a whole planet elevation map that I’ve generated. I’ve tried setting it to single channel: red, and enabling read/write. I’ve tried just swapping in the texture on one of the demo scene planets on a clean project, but it still generates a perfectly spherical planet (besides displacement on any other layers). The only difference I could think of is that the texture wasn’t square so I tried resizing it, but that didn’t work either.
I’m including an example of the kind of texture I’m using. It’s not one that I generated but a similar one, and I tried this one and got the same result.
Okay, I figured it out-- I wasn’t setting the format to R 16 bit. This is Planet Forge, btw.
In that case my other question is how do I set the size so that it wraps around the planet perfectly? I could set it as the height map on the Landscape object, but that doesn’t have an option for displacement, so I set it on a biome layer, but then I can’t figure out what size I should set it to so that a mercator projection wraps around the planet.
Never mind, displacement is working on the Landscape object, and that seems to tile the mercator projection seamlessly. It didn’t seem like it was working on my larger planets, but It definitely works in the demo scene.
One more thought about height maps.
I was looking through the source code and there’s a TopologyData struct that says:
“This struct allows you to load a height Texture2D into a height/slope RenderTexture for GPU use.”
If we could use render textures as input for height maps that would open up a lot of possibilities for generating terrain maps on the GPU. I’d love that feature.
Hey @Mulbin , what tool are you using for ultra large diameter planets? I’m trying planet forge, but I have the same problem: the ground resolution is very low. I’ve also tried the 5 layers, but it doesn’t work the way I want, i.e. with good ground resolution when the camera is zoomed in.
I think I know what you mean. With Terrain Planet I can get decent texture resolution at ground level, but not with Landscape. Landscape is much better at far and medium distances instead.
Will this be improved or are we doing something wrong @Darkcoder1 ?
@maximblake254
When the current feature set and water is more or less finished I will consider weather effects. I don’t imagine this will be in the near future though.
Light/god rays might be easy to implement, since for the clouds I had to change the way the atmosphere is calculated that makes it more in line with how god rays work. However, there are many far more important bugs/issues I need to address before I can look into this.
Sure, you can scale things down or use multiple cameras or some other tricks, but there are always tradeoffs. The biggest challenge with large planets is that Unity’s camera depth texture and shadow system (as far as I know) don’t use a reversed z buffer, so they kind of stop working beyond a certain scale range, so it doesn’t really matter how you scale things overall. The old SGT atmosphere is rendered with the planet surface mesh, so it intrinsically knows where the ground is and how to calculate the atmosphere’s optical thickness. Whereas the new sky + cloud system relies on the scene depth rendered by the camera, but since this is of limited accuracy it can break at certain scales.
@Frpmta
Yeah, I think the scene depth information in HDRP is using data from the previous frame, which causes the mountains to have this edge as you move or rotate the camera. I’m not exactly sure why that happens, but it’s something I’m trying to figure out.
Does this shaking occur for any cloud setting, or only when you increase the thickness a lot?
@adsilcott
Thanks, perhaps the code for 8bit textures is broken, I’ll check it out.
HeightData & TopologyData need Texture2Ds, because the planet surface mesh vertex positions are calculated on the CPU so there must be a CPU copy of the height data. You could always read the pixel data from your RenderTexture and turn it into a Texture2D, but this is very slow whereas the current implementation with Texture2D is basically instant.
@pepicogrillo
Terrain Planet is mostly generated on the CPU with doubles, so it was fairly easy to get it working at large scales. Planet Forge uses CPU + GPU (basically no doubles) and replies on scene depth, which makes things a lot more complicated. This will of course be improved, but there are still some more important issues like one final equator seam and cloud rendering issues that I need to fix first.
I have noticed lately it often comes off as blackmail haha.
