I’ve been using the terrain branch for a little while now. On my workstation it feels like the generation of the displaced geometry tiles is a bottleneck for performance. e.g. when comparing to no-terrain. I have lots of cpu cores but not many appear busy. Is it possible to have more web workers processing tiles in parallel for this job?
Also, wrt [0] I’d like to add votes for…
‘Allow imagery detail to increase independent of increasing terrain detail’ . It would be great to decouple these.
‘Client-side (approximate) level-of-detail control.’ assuming this would allow e.g. control of how finely terrain gets tesselated based on client hardware etc.
‘Show terrain in Columbus view.’ In terms of UX it could be like looking at one of these [1]
Kevin or Scott can speak to the number of web workers used, and I’m sure provide more details to my comments below.
‘Allow imagery detail to increase independent of increasing terrain detail’ . It would be great to decouple these
This is the long-term vision for sure. In the short-term, the plan is to at least tessellate areas without terrain using the ellipsoid model so the imagery is able to refine. We need this for an app we are in mid-stride on (app details to become public in about a month).
‘Client-side (approximate) level-of-detail control.’ assuming this would allow e.g. control of how finely terrain gets tesselated based on client hardware etc.
This is to control screen-space error, which is a speed/quality trade-off. Although I see the property in CentralBodySurface, it doesn’t look like it’s exposed yet.
Currently, we do not tessellate terrain beyond the true data, e.g., apply fractals; however, it’s not out of the question for the future. Is this what you are asking about?
‘Show terrain in Columbus view.’ In terms of UX it could be like looking at one of these [1]
We also need this for the app we are working on. In general, we think Columbus view has a lot of potential given its coolness factor, and we have yet to fully exploit it. If I can put words into Kevin’s mouth, he assures me it is not hard (however, it is not trivial either; for example, things like horizon culling need to be revisited, and horizon views in general have the potential to be troublesome). We’re hoping to have it in December.
I’ve been using the terrain branch for a little while now. On my workstation it feels like the generation of the displaced geometry tiles is a bottleneck for performance. e.g. when comparing to no-terrain. I have lots of cpu cores but not many appear busy. Is it possible to have more web workers processing tiles in parallel for this job?
Currently we use just one web worker to tessellate terrain tiles. It’s possible to use more, but I haven’t looked closely at what would be involved. One problem is that the web browser doesn’t give us a way (to my knowledge) to learn how many cores a machine has. That’s unfortunate, because 4 workers tessellating terrain on an 8 core machine is very reasonable, but on a 2 core machine it’s going to cause performance problems.
One way we can avoid this issue in the future is to download pre-tessellated tiles from the terrain server instead of heightmaps that need to be tessellated on the client. We’ll probably end up doing this eventually anyway in order to improve visual quality, reduce memory usage, and decrease GPU vertex load.
‘Allow imagery detail to increase independent of increasing terrain detail’ . It would be great to decouple these.
I’m actually working on this today.
‘Client-side (approximate) level-of-detail control.’ assuming this would allow e.g. control of how finely terrain gets tesselated based on client hardware etc.
As Cozzi mentioned, you can adjust the (semi-private) screen-space error property in CentralBodySurface. That might give you something close to what you want. If you try it, let me know how it goes.
‘Show terrain in Columbus view.’ In terms of UX it could be like looking at one of these [1]
Definitely on the to-do list, but as Cozzi said, we probably won’t get to it for another month or so.
