tirsdag 12. mai 2015 22.07.54 UTC+2 skrev Patrick Cozzi følgende:
Hi Hyper,
> which also assumes that 3D buildings are working with the same tiles as terrain data.
I don't anticipate using the same tiles or tiling scheme as terrain. For example, if we take into account building density and the complexity of individual buildings, we can come up with non-uniform subdivisions that are more optimal than the traditional uniform subdivision used by a vanilla quadtree. I'll write some tech articles in time.
I totally agree. In my experience building models require a less rigid partitioning scheme than terrain tiles.
I believe your czml files relatively easily can be extended to handle large volumes of buildings and other similar objects by introducing view dependent hierarchical loading (and un-loading of areas gone out of scope). It should be relatively easy to develope programs for partitioning large city models into a set of compact blocks, and at the same time the very same structure can easily be hand edited for handling smaller projects. Something like KMLs NetworkLink/Region system could be an inspiration.
I wonder how you handle the situation when a model file is referenced several times like the trees in Kevins Taipei demo? Are the models loaded or copied for each time they are referenced or is the same model used each time? Is the scenegraph a real graph with shared sub-graphs or is it only a tree structure? The ability to use shared models efficiently is crucial for handling large volumes of similar objects (like a forest) with a few variations of prototype objects.
In Kevins demo I also noted that the depth sorting of semi transparent objects apparently didn't work properly; some trees further away where drawn on top of closer trees. But really, objects using silhuette textures like tree models should not be handled like traditional semi-transparent objects, but as opaque objects with an alpha-test shader!
The Seattle demo also does not account for terrain, but this is something we will account for in the final version. It could be done offline as a preprocess or at runtime. There are tradeoffs for either that we need to think through.
Very important! I believe you should have an opening for both (like KMLs altitudeModel: relativeToGround and absolute) actually. Precomputed terrain heights are most efficient, as you don't need to evaluate the terrain models runtime, and should be used for larger projects, but for smaller projects (when the hassle of finding terrain elevations in a GIS is greater than the performance loss) it can be very convenient! When computing terrain height runtime one should also remember that the terrain you have when the bulding is loaded is probably a reduced resolution version, and the elevation shold be re-evaluated as more details are loaded.
I wonder how you handle the situation when a model file is referenced several times like the trees in Kevins Taipei demo?
Cesium already has a cache to avoid loading redundant models. However, for trees in particular, I think we can take it much farther by using WebGL 2 instancing so, for example, we can render many trees in the same draw call.
In Kevins demo I also noted that the depth sorting of semi transparent objects apparently didn’t work properly; some trees further away where drawn on top of closer trees.
If that demo was just loading glTF models, then Cesium was using whatever render state was defined in the model, which could be a standard translucent setup as you mentioned.
as opaque objects with an alpha-test shader!
Agreed. I think we will still run into issues like #2130.
thank you for the update on 3D buildings in Cesium! This is definitely a great amount of work.
We are a team within Chair of Geoinformatics, Technische Universität München, Germany (https://www.gis.bgu.tum.de) and would like to share our developments in the similar direction.
We have been working actively towards web based visualization of 3D city models represented according to the CityGML standard (http://www.citygml.org/) issued by Open Geospatial Consortium (OGC). We have developed a web based 3D client based on Cesium and Google Earth viewers, which allows interactive 3D visualization and exploration of large scale 3D city models. As a pre-processing, the CityGML files are imported into our open source 3D geodatabase 3DCityDB (http://www.3dcitydb.org/). 3DCityDB comes with a powerful KML/COLLADA exporter, which allows creating a tiled set of KML files for the entire city. The city model in the form of tiled KML files can be explored and interacted with, on the web client. In relation to the Cesium globe, we would like to share with you our developments, which support
3D building geometries and textures (in the form of glTF models)
Hi Patrick - this is amazing! Looks really nice, especially, mouse-over and mouse-click highlighting.
Does it also support textured models (like https://youtu.be/n6xQCIF1MxI)? As I understand, the buildings have model material’s diffuse property as cartesian colors in Cambridge example, which can be replaced by another cartesian color for highlighting. However, in case of diffuse property as texture (like in our YouTube link), we are struggling to replace with another color to produce highlighting effect. We are not able to replace texture with a color property.
This is great! Streaming/Protrayal 3D services are the way to go for visualising large amount of 3D content.
We are looking to use cesiumjs to do a prototype of a virtual campus for National University of Singapore. We have about 200+ buildings with rooftop details in 3D from full LiDAR scan and aerial photogrametry; trees, elevation, roads, and other spatial datasets and layers from topo survey. May I know where can I get more information/tutorials on how we can create and consume the Binary glTF 'tiles' ourselves? Anyone from Cesium that may be interested to include the NUS campus as a demo is welcome to discuss!
Regards,
Raymond Huang | GIS Manager
National University of Singapore
Some months ago I tried exactly the same approach with the same dataset you tested (was for the web3d contest, I m right?)
However, although your approach is theoretically correct in order to get collada files to be converted in batch with the collada2gltf tool, the main limitation is constituted by the texture atlas automatically generated by the 3d citydb exporter tool (each texture atlas contains a lot of unused information)
Do you have managed this issue? Have you solve it?
next week I will perform some other tests with this approach....
Thanks for the interest. For more on Binary glTF, see this discussion. The tiling scheme is still under development. I’ll update this thread once it is stable-ish.
Also, we would be happy to include your work on the demos page of the Cesium website. Let us know when you are ready.
“Buildings are grouped together into tiles to reduce the number of network requests and WebGL draw calls.”
This means many buildings are grouped together into a single .bgltf file? or they are still individual bgltf file for each building, but grouping them into a single .czml file?
This means many buildings are grouped together into a single .bgltf file?
Yes.
There are tradeoffs, of course, between batching server-side and batching client-side. For our current datasets and uses cases, batching server-side has been a good approach.