Battle of 3D Rendering Stacks: CesiumJS, VTS Geospatial or iTowns?
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 295 | |
| Author | ||
| Contributors | ||
| License | CC Attribution 3.0 Germany: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43307 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
| |
| Keywords |
FOSS4G Bucharest 2019276 / 295
15
20
28
32
37
38
39
40
41
42
43
44
46
48
52
54
57
69
72
75
83
85
87
88
101
103
105
106
108
111
114
119
122
123
126
129
130
131
132
137
139
140
141
142
143
144
147
148
149
155
157
159
163
166
170
171
179
189
191
192
193
194
195
196
197
202
207
212
213
214
215
216
231
235
251
252
263
287
00:00
StatisticsVideo gameQuicksortPolygon meshSpacetimeBeta functionVisualization (computer graphics)Software frameworkPlug-in (computing)Social classSemantics (computer science)1 (number)Library (computing)Goodness of fitVirtual machineVirtualizationComputer configurationFocus (optics)Stack (abstract data type)2 (number)Game theoryPhysical systemAugmented realityCartesian coordinate systemINTEGRALPoint (geometry)Pairwise comparisonStreaming mediaVector spaceEndliche ModelltheorieOpen sourceWeb pageCore dumpNeuroinformatikVirtual realityMappingForm factor (electronics)Real numberData fusionProjective planeMereologyFront and back endsConnectivity (graph theory)Artistic renderingWeb 2.0Client (computing)Logical constantDifferent (Kate Ryan album)Motion captureMachine visionHypermediaExecution unitSimulationDigital photographyView (database)DataflowTwitterRow (database)Normal (geometry)Lecture/Conference
04:45
Line (geometry)FluxPoint (geometry)Vector spaceStack (abstract data type)Uniform resource locatorService (economics)Product (business)QuicksortStreaming mediaMultiplication signSoftware testingCASE <Informatik>CuboidTesselationProjective planeResultantWave packetGastropod shellInformationContext awarenessOpen sourceEndliche ModelltheorieRepetitionWeb pageData managementForm (programming)Zoom lensNumberMobile WebMereologyEvelyn PinchingCodePresentation of a groupImplementationDisk read-and-write headAuthorizationConfiguration spaceGame controllerInheritance (object-oriented programming)Core dumpUniverse (mathematics)TwitterScripting languagePairwise comparisonMatching (graph theory)Visualization (computer graphics)Computer hardwareDifferent (Kate Ryan album)Software repositoryProxy serverBlock (periodic table)Discrete element methodHookingSlide ruleLevel (video gaming)Web applicationData conversionPlastikkarteFile formatDialectoutputLecture/Conference
11:03
View (database)Configuration spaceStack (abstract data type)CodePairwise comparisonSoftware repositoryParameter (computer programming)Line (geometry)Drop (liquid)Structural loadCodeSoftwarePoint (geometry)Proxy serverLevel (video gaming)Physical systemBefehlsprozessorBitPolygon meshDifferent (Kate Ryan album)Server (computing)Object (grammar)Cartesian coordinate systemTesselationResultantTexture mappingMultiplication signSemiconductor memoryComputer fileImplementationDebuggerCASE <Informatik>Frame problemMetreGraphical user interfaceWeb pageService (economics)Demo (music)NumberVector spaceEndliche ModelltheorieProcess (computing)Zoom lensVideoconferencingTotal S.A.Data managementTunisUtility softwareMereologyLecture/Conference
17:22
HypermediaFamilyLevel (video gaming)Semiconductor memoryPoint (geometry)MeasurementProcess (computing)Hand fanUsabilityMetreFundamental theorem of algebraInternet service providerProxy serverTesselationHeat transferLoop (music)MereologyInformationMultiplication signGoodness of fitCASE <Informatik>Digital photographyDirection (geometry)NumberProjective planeMemory managementStress (mechanics)Vector spaceParameter (computer programming)Overlay-NetzBefehlsprozessorConfiguration spaceVolumenvisualisierungPartial derivativeBitFile formatSoftware developerLecture/Conference
22:33
Web 2.0LaptopMobile appPairwise comparisonBefehlsprozessorMobile WebConfiguration spacePresentation of a groupMereologyComputer hardwareVirtualizationEndliche ModelltheorieArtistic renderingVisualization (computer graphics)Object (grammar)Functional (mathematics)Social classVector spaceStreaming mediaOffice suiteMathematical optimizationWeb browserLibrary (computing)Multiplication signTesselationVideo gameExtreme programmingDatabaseBus (computing)SpeciesNumberHydraulic motorLecture/Conference
27:44
Lecture/Conference
Transcript: English(auto-generated)
00:07
So, my name is Ladislav, I'm from Melon Technologies, and in this talk I'm going to do some sort of battle of 3D renderings techs, cesium.js versus VTS Geospatial versus iTowns.
00:23
So first, what the Melon Tech is about, this company I come from in 3D mapping business. We have main project which is called Vatstena, it's a real computer vision and deep learning driven reality capture pipeline, basically takes aerial imagery using standard photogrammetry
00:44
turns them to geometric reality and increasingly more return them using machine learning to some sort of semantic reality. The second project, like main focus of this talk is the VTS Geospatial, which is basically a 3D data fusion virtual landscape streaming and rendering system or framework or ecosystem.
01:04
Basically, you take all those 3D models and DEMs, orthophotos, vector data, basically everything, it fuses them together and it allows you to stream them to various clients across different devices, form factors and systems.
01:23
We have WebGL based JavaScript client for VAP, we have C++ client for desktop, and we also have the Unity plugin. So, yeah, come on in, come on in, if you are there, still come on in, there's some space in the front row, yeah.
01:44
I have enough place around here, so good point, cool. And we get more airflow also, okay. So what are the applications of VTS Geospatial?
02:02
It can be virtual reality or augmented reality, some interactive simulations, maybe gaming with the Unity plugin for example, or of course, Geospatial 3D mapping. So what's the aim of this talk or core of this talk?
02:21
We shall have a look on what are the options for 3D Geospatial data rendering, so at least the ones we came across and were forced to learn something about and so on. We shall have a look how you work with those three rendering stacks we discovered.
02:42
We do some performance comparison based on some basically standard or not standard, but like constant example, constant data, and we will talk about interoperability between those rendering stacks. So first, what are the first options for 3D Geospatial data rendering?
03:04
Probably the first things that comes to mind is cesium.js, who doesn't know cesium.js here? Yeah, either people are shy or everyone knows, good. So it's an open source JavaScript library for world class 3D globes and maps, at least
03:22
that's what the web page says. It's very feature rich, and it has a very large community and quite good support. When I, myself, did the examples, I got very nice support on the forum, or beta on the forum, or GitHub. From that point of view, it was a kind of pleasant experience.
03:44
Then you have our VTS Geospatial, which is open source and maintained by Mellon Technologies. It's an integrated system for 3D virtual landscape streaming and rendering. The entire stack is open source, so that includes both front-end and back-end components.
04:03
The back-end components, it's soluble through a single. And it was from the very start, it was designed to be very lightweight and very fast because the front-end, as it was developed, it was developed as part of a big project for one client, and the aim was that the front-end will be basically facing the normal user.
04:27
So, and usually users, not the geospatial people, are not used to waiting. So you just have to be fast and lightweight. And it's also suitable for the big data, that was another requirement.
04:42
The third option we have is iTunes. A web framework written in JavaScript for visualization of 3D geographic data and precise 3D meshes. I think it's from, and I'm not really sure it's from either the German or French University. No, if anybody knows, just correct me.
05:01
French University, okay, cool. It's based on 3JS, inheriting many of its features like post-processing, controls, working with 3D models, and so on. So it's a pretty nice kind of small project, we'll find out later, but otherwise it's pretty nice.
05:25
So compare these 3D stacks because they are very, very different, at least feature-wise. So we need to pick some, basically, test case. So we want to pick a test case that is, I would say, reasonably ambitious.
05:44
So we won't just render a globe with orthophoto, that would be just a waste of time. So we are aiming for something more interesting, and on the other hand, we don't want to push it so far that we'll just throw away all the stacks
06:00
because just one can fulfill all the requirements and so on, so we need to find some golden way. And also we want to make sure that we work with, all the stacks we work with are almost the same data.
06:20
So basically, as an example, we picked a sort of basic 3D smart city web application. It's basically a global DEM with a 3D city model in 3D dials format overlaid with a vector layer of parcels, with vector numbers, with parcel numbers.
06:40
So we want to display the parcels, those are the blue lines, and we want to display the numbers, we want to display the 3D model, we want to browse it and see how the stacks will do. Yeah, so that's just a wrap-up of what we are working with. A true 3D city model, a global terrain imagery for context, vector parcel information.
07:05
The result or what we attain with the stacks should be as fast as possible because some of the stacks may have some like hooks and glitches and so on, so we shall see if we can work around them, and of course we want the result as fast as possible.
07:21
So here's a short disclaimer, of course I'm one of the authors of VTS Geospatial, so there's no way this is not going to be totally skewed towards VTS Geospatial. So just a heads up, I'm not either cesium.js or iTown's pro user, so basically we just got with cesium guys and tried to do as best as I could,
07:45
but I cannot guarantee it's like the really best possible implementation. So this comparison will be inevitably biased, so take it with a pinch of salt, or this whole basically comparison project is on GitHub, you can just fork the repo,
08:03
there is a self-contained webpage where you have all the examples in different stacks, so you can try it either on your own hardware or you can try to reconfigure it and so on.
08:20
So for example you can see if you can squeeze more performance of various stacks. So that's the GitHub repo URL in case you want to take a picture or whatever, I will give the slides on Twitter after the presentation.
08:44
So how do you work with the three generating stacks? Basically how do we configure or make this example happen in those stacks? So let's start with data ingredients. So we'll have a city model in 3D tiles format because all three stacks,
09:02
cesium is of course native to 3D tiles, VTS geospatial can convert 3D tiles on the input to some format we use, and iTunes also say they can use 3D tiles. So we pick the 3D tiles format, we'll need a global DEM and imagery,
09:21
we'll take from a Czech bureau of, I don't know the exact name now, but just download the GeoJSON with parcel information, and that's about all regarding the data. How do we configure this all in VTS geospatial? It's just like from a train configuration fast overview,
09:44
I won't go into technical details. Basically you encode the city model into VTS style set using this tool that's part of the package you install with VTS geospatial. You configure the global DEM and imagery to be used in VTS map proxy
10:01
that can be done as Andrei said in the first talk of this block. For example using the map proxy setup resource script, or we will use the terrain or imagery available off the shelf from Melomtech.
10:20
You can basically do this yourself with your own data, there are no glitches or hooks. And we will basically convert the parcel information from GeoJSON into MBTiles using the open source tool from Mapbox called TipKanoi,
10:43
because VTS can stream like tiled vector data, and map proxy, VTS map proxy, that's one of the VTS geospatial servers, takes care about, because of course all the vector data are just 2D,
11:01
there are no heights associated with them, so you need to add heights to each point, so this is what map proxy takes care of on the fly. Basically if you go to GitHub repo there are all the details about the configuration.
11:22
How we configured this in Cesium, Cesium uses 3D tiles natively so that's fine. Here, because we don't actually want to use Cesium ion, because it's like paid service, it's not open, so instead we will use again VTS map proxy to serve Cesium terrain,
11:41
which does basically the same as the Cesium ion does, it's just completely open source. And we'll configure the map proxy to serve TMS imagery, that's again the tiling the Cesium uses. And here we actually will pre-height code all the data, because Cesium of course it can do height coding on the front end,
12:03
but when you pull a few megabytes JSON of points there, it will take some time, it won't be too much usable, because it will be very slow, like when you move it will load new terrain and it will re-height code all the points that fall into this tile.
12:24
So we'll do a favor to Cesium in this way and just pre-height code all the data, so it can just render them as they are. Or if you have the smaller files that would be the case, you would go for the front end height coding.
12:43
Yes, so that's basically what I said. Height code is JSON 2.3 tiles, city model, terrain, imagery, all tied up or bundled in the JavaScript application. So for the iTowns there was a bit of a bummer, because through it looks that it supports 3D tiles,
13:02
I think it supports only the 3D objects actually, it doesn't support yet the continuous mesh. So this was the best thing we could attain with iTowns, and that's basically where we stopped, because we already burned a lot of time there. So it's just basically black untextured mesh,
13:23
so the textures I think are not yet implemented and we didn't dig anymore into that, because we don't know the system and it was very tough. So basically iTowns effectively dropped from this comparison. Too bad, but it probably was bound to happen or something like that. So the performance comparison.
13:43
Here maybe I'll switch quickly to the GitHub, where you can see both, where you can see, here is basically the GitHub repo, here you have the webpage,
14:02
and here you have like VTS implementation and czoom.js implementation. So VTS implementation, we have network, that's good. So it loads the city, it loads the vectors, and here you go. czoom is kind of the same experience,
14:24
the network will not give some glitches. So again it loads the tiles, loads the vectors, numbers, and it will display the lines. So I'm actually a bit proud of myself, I made it look really similar in both systems because it was like weeks of work.
14:42
You know, no one will praise me for that, I have to praise myself. So yeah, and basically here what we did, we just fired up the Chromium's performance monitor in like the console and watch the FPS
15:00
when you move the map, watch some memory consumption and so on. So we got some results that I'm going to present. I think it's very nice, you can try that, it behaves kind of in very similar fashion with the differences I'll mention
15:21
when we get to the performance comparison. So yeah, that's the live demo, definitely go there, try that. And so this is what we got from Chromium performance monitor basically.
15:42
The VTS geospatial, basically none of the stacks will run on 60 FPS once you pour in some solid data. So when you move the map in case of VTS geospatial, the frame rate drops to like 35, the CPU consumption goes basically up to
16:04
nearly 100% when you move, but when you stop the CPU drops and everything gets as you should or as you would expect. The JS heap, I'm not really sure what this parameter means, but I don't think it just relies
16:20
to total consumed memory, but it's probably like how big is the JS heap? Okay, so it's 75 megabytes, and when I tried what's the actual RAM consumption through just HTOP utility, when you basically turn on the initial view and when you turn the tab off,
16:41
so it's something like 800 megabytes. When we go to the cesium, it gets kind of interesting. When you are moving, the FPS actually drops down to 15, which is kind of like half of what VTS geospatial does. The CPU consumption is also a little bit higher,
17:01
and the main difference is that the CPU consumption actually stays very high even if you don't move the map. I actually tried to dig more into this, and it turns out that cesium has some parameter that will allow you to basically stop rendering when you are not moving the map.
17:22
And that works if you may just turn the lights off. Great. And it works well until you pour in the vector data. It somehow turns off this parameter and will continue rendering on and on,
17:42
and the fan will just spin up. You know the story, probably. Also, the JS heap is somehow higher, and the HTOP measurement, again, is somehow like double the memory we use. So that's like the hard numbers I got.
18:02
If I should interpret them or give some very personal... I'm not sure if I want to do that. Okay, basically, like a conclusion. If I was doing some really small pet project,
18:25
I probably wouldn't have a problem to go for cesium because it really has lots of features, and I can get some help. If I'm going to do something big or worse, like user-facing, I would probably stick with VTS geospatial.
18:43
And in the end, the very last thing about the interoperability... We have still like two minutes. Because there are some silver lining to these terrible numbers. So we have 3D tiles, which is a pretty nice format,
19:04
and it's already widely supported or gained enough traction to be widely supported in commercial photogrammetry engines, including ours, Vatstena, and many others. So that's, in this case, it's like a good transport format.
19:22
Though it has like only partial support in iTunes, but I don't think it's actually like 3D tiles fault. And this little nice thing about VTS Map Proxy actually working as a cesium terrain provider. So if you are, for some reason, trying to go big with cesium
19:41
and you have some fundamental problems with cesium ion, so basically you can go with Map Proxy, which does the similar job, if you are not afraid to set it up in your own configure. So that may be a way to go for you.
20:00
So that's probably everything I wanted to say. We are quite on time. That's nice. And if there is anybody who can still talk after the last evening's party and has some questions, so I'll be happy to answer them. Okay, here's the first question. If you could add TerraJS to the check.
20:23
Yes, because they use cesium engine and they have better performance because they stopped the loop to re-render stuff. So I think it might be more interesting to check that instead of just pure cesium. Yes, that's a good point.
20:41
You all heard it because you had the mic. That's cool. I don't need to repeat it. That's a good point. I ran across the TerraJS just basically when I browsed this year's talk, so it's new information for me. Otherwise, I would include it, definitely. I would say it's already partially answered
21:03
by including the cesium because it still runs on the cesium, and I guess that turning off the loop is just the parameter like render whatever false or something like that, which does the job when you don't have the vector data or at least to my knowledge,
21:21
or I don't know if they fixed it already. Here's another question. I'm one of the Terrier developers. As far as I can tell, unfortunately, even using Terrier, cesium does struggle a bit
21:40
with vector data. So I was wondering, when you were developing this and experimenting, did you get a chance to compare performance when you didn't have that vector overlay on top? Yes, so if I did get a chance to compare the performance
22:02
if I didn't have the vector overlays, I think at one point I did turn it off, but I think with the general FPS, it was kind of the same, just the CPU basically got nicely.
22:23
It actually still was around 5-10% when you didn't move the map, so it was definitely better, but still it wasn't this kind of zero-ish as with VDS geospatial. So that's what I can remember. I probably can't get more into detail because I don't remember it.
22:41
Another question? Okay, there. Do things work and how's the performance on mobile devices? The question was about the performance on mobile devices.
23:01
Regarding cesium, I think it's still a front-end library, so you will run it on mobile device just through a browser, at least to my knowledge. When you go to VTS geospatial, you can also run it in VAMB browser, but running it on mobile through WebGL,
23:21
you will really not get the optimal performance, but VTS has native C++ library, so you can write the apps on mobile, like natively using the C++ library, so that would be the way to go with VTS geospatial. With iTowns, I think it's still on the web with Three.js,
23:44
so that's, again, the similar issue. Okay, there was a question?
24:02
Okay, so the question was, like, performance is one thing, and what about the functionality? Yeah, that's why I picked performance comparison, because, like, not that we, like, lack the functionality. For example, the VTS geospatial has, like, tons of geographical functionality
24:22
based on the vector data. Like, Cesium can't even actually stream vector tiles, at least to my knowledge. I'm not sure if they already support it. I think there was a ticket for that. I'm not sure how far they get. But with VTS, you have these, like, tons of cartographical functionality.
24:43
Andrei had, like, two talks about that. And, of course, like, Cesium has many features. Like, you can basically play with all the objects that you have in memory, but it comes with this cost, basically. And it may come with this cost also
25:02
when you don't actually, like, use those features, which is kind of... I would say it's not optimal behavior. Like, I like the approach, like, pay for what you use, don't pay for what you don't use, so that's it. But I definitely give it to Cesium that it has more, more, like, features
25:22
on the, like, playing with the rendering and so on. So, yeah. What is the configuration? Okay, so the question was, what is the hardware configuration
25:42
where I did test... I did it on this very, very laptop. I think it has... I'm not sure if it has integrated... It probably doesn't have integrated GPU. It's, like, eight gigabytes of RAM, and I'm not sure about the CPU now,
26:00
but it's some kind of, like, higher-end laptop. So it's not desktop, but it's high-end laptop. But it's not, like, this office desktop or office laptop. I think it's, like, the upper class of the hardware. Okay, any more questions? I'm not sure if we have some time.
26:20
Yeah, we have to... Probably not. Not sure, not sure. So if there are... Okay, so maybe one last question. I was wondering why you didn't include NASA WebHerbin, the API, in this comparison. I know that you cannot visualize 3D city models
26:42
with NASA WebHerbin, but it is one of the prominent examples, I believe, among the virtual globe APIs for web. So the question was, why didn't we include NASA WebWorldland? So it's mostly, as you said, like, it doesn't support 3D,
27:01
and it's, like, the major part of the presentation for us. So, like, we... As I said, like, we could make an example, like, just...
27:27
I never used the NASA WebWorldland, so I can't really tell, so I'm sorry in that. Okay, so thank you for your attention. I'm sure we are just on time, so thank you.