Autodesk Forge has a nice feature known as section hatches. This feature fills out (or caps) parts of the model that is cut out by the section plane with a hatch pattern. You can see this in action below, when a z-plane cuts across the building:
The addition of hatches helps the viewer to see which parts of the model are cut out.
However, there is a problem with section hatches on some models, such as this:
The left part of the building is wrongly covered by the hatch and there are some weird triangulation problems on the right. This could happen when the meshes in the model is not 2-manifold.
Starting with Forge Viewer v7.35, there is a new option to turn off section hatches. It is located in the Configuration tab under Settings.
When you turn off section hatches, you still get the clipping, but without the potential artifacts:
You can also programmatically enable this behaviour by calling:
As usual, Unreal’s demo are always super impressive. New features in Unreal Engine 5: unlimited polygon, real-time global illumination. Other than realistic animation, these are like the holy-grail of real-time graphics. We’ll have to wait till 2021 to see if they can deliver these in actual production.
The following images are not 3D renders. They are screenshots from the actual real-time demo.
Nanite virtualized micropolygon geometry frees artists to create as much geometric detail as the eye can see. Nanite virtualized geometry means that film-quality source art comprising hundreds of millions or billions of polygons can be imported directly into Unreal Engine—anything from ZBrush sculpts to photogrammetry scans to CAD data—and it just works. Nanite geometry is streamed and scaled in real time so there are no more polygon count budgets, polygon memory budgets, or draw count budgets; there is no need to bake details to normal maps or manually author LODs; and there is no loss in quality
Activists created a digital library in Minecraft. There are some criticisms about the practicality of this movement, but you cannot deny that the library building is very impressive – the designers have put a lot of thought into each “wing”.
Reporters Without Borders created “The Uncensored Library” within “Minecraft” as what it calls a “loophole to overcome censorship.” The digital library in an open “Minecraft” server has articles and information that has been censored in many countries, but is accessible through the game.
OneMap3D is envisioned to be “Asia’s first, open-source 3D nationwide map”.
OneMap 3D (sic) will enable users to orient themselves in a three-dimensional representation of the real world, empowering them to navigate around identifiable landmarks, walkways and even void deck spaces. OneMap 3D will first be launched to developers by the end of 2020.
Full disclosure: we are enrolled in OneMap3D Developer Programme and are bounded by the NDA. The following content does not reveal anything that is forbidden by the NDA.
It appears that earlier articles use the term “OneMap 3D” and recent ones “OneMap3D”. For consistency we will use the term “OneMap3D”.
In 2014, Singapore announced the launch of the Smart Nation Initiative, of which Virtual Singapore is a key feature. One of the products of Virtual Singapore is the island-wide 3D map of Singapore. Today, the custodian of this 3D map is the Singapore Land Authority (SLA), and the platform in which this data will be available is called OneMap3D.
This article primarily focuses on the comparison of 3D model available on Google Maps and OneMap3D. Other aspects such as API capabilities etc are not explored.
Google Maps 3D
When Google Maps was launched, the world of digital mapping was introduced to the masses. It began with making tile-based maps accessible through the browser. Then Google acquired a company called KeyHole and took over the product to be launched as Google Earth, a desktop application. Google Earth was its foray into interactive 3D mapping – fulling Neal Stephenson’s vision in a round-about way since the original KeyHole application was said to be inspired by the author’s novel.
Nowadays, the line is blurring between Google Maps and Google Earth since the former is capable of showing 3D content as well. On your modern desktop browser, just turn on Satellite mode and if the area happens to have 3D content it will be shown. Singapore is lucky enough to have this feature enabled for a large part of the main island. Our comparison will be based on the 3D content available through Google Maps.
OneMap3D is envisioned to be the upgrade from the existing OneMap service provided by SLA. By enrolling in the OneMap3D Developer Programme, we are given access to 1) 3D building models, and 2) API to access 3D models.
The 3D building models are provided in CityGML version 2 format. For those who are unfamiliar, “CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models.”. It is both an OGC as well as an ISO standard.
The tools for processing CityGML are quite lacking unfortunately, as commercial support is not high. For the purpose of this comparison, we will import CityGML files into 3DCityDB, and export it out as a COLLADA file.
At this zoom distance, both models in Google Maps and OneMap3D look quite good. It may not be apparent, but the water tanks on the rooftops for OneMap3D are modelled separately.
For a more articulated building, OneMap3D clearly shines. One can see small features such as the cross on the rooftop and words on the facade can be read.
Google doesn’t reveal how its 3D mapping content is constructed but one can try to guess. One FAQ for Google Earth – which probably shares the same data sources as Google Maps – says that imagery collected includes “satellite, aerial, 3D, and Street View images” from “providers and platforms”. The fusion of all these data into a model should be largely automated and powered by their proprietary algorithms.
Based on how 3D contents are streamed in Google Maps, they should be using some form of progressive mesh techniques.
OneMap3D models are based on buildings and each building is provided as a CityGML file. The likely data sources include LiDAR, aerial photography, site survey, official building footprint, etc. It is apparent that the models are handcrafted through some modelling software and converted to the designated format.
As with most things, there are pros and cons to either modelling approaches. Here is a non-exhaustive comparison:
Colors/textures can be inconsistent
Textures can look repetitive
Sharp even when zoomed in
Subject to human errors
Small features can be seen
Ground-level details can be seen
Consistent look and feel
“Melted building” syndrome when close-up
Scalable to large areas
Edges are not straight
Building not separated from terrain mesh
Shadows are not removed
More OneMap3D Examples
OneMap3D represents the herculean effort of creating and maintaining an up-to-date database of 3D building models for the whole of Singapore.
Google Maps approach on the other hand, allows it to scale to potentially any city in the world. And it will only get better with newer data acquisition techniques and algorithms.
Beyond 3D representation, however, OneMap3D’s models also contain rich semantic information that allows it to be used in different types of applications, eg. computing roof surface area. And since buildings are standard 3D assets, they can be used in various types of 3D applications such as VR, gaming, rendering etc. There are clearly pros and cons of either approach and we are excited to see the types of applications that OneMap3D will bring when it officially launches end of the year.
Edit: Contact me if you would like to know more about converting OneMap3D data to other commonly used 3D formats.
Someone implemented the same 3D scene using different API/frameworks. Interesting from a learning point of view. But as someone commented in HN, some implementations could be made to look the same given enough effort.
This repository contains multiple implementations of the same 3D scene, using different APIs and frameworks on various platforms. The goal is to provide a comparison between multiple rendering methods. This is inherently biased due to the variety of algorithms used and available CPU/GPU configurations, but can hopefully still provide interesting insights on 3D rendering.
This is a really cool idea – a good mashup of old retro game artwork and 3D printing. The author of this website has written an editor that takes in 8-bit sprites from various directions, and produce a working file that can be used for 3D printing.
There’s just something tangible about physical objects that makes them so appealing.
Abstraction is good for developers, right? Why else would you be programming in high-level languages like C++, Go, Python instead of assembly language? Well, it turns out the situation is not so straightforward for game programming.
In terms of graphics programming, after years of high-level graphics API, the trend has been to go as close to metal as possible (Apple’s Metal, OpenGL reborned as Vulkan, and now DX12). This article does a very good explanation of why this is happening.
In a way, this is a manifestation of the break-down of Moore’s law – at least in terms of clock-speed improvements. Games are among the most demanding type of applications in terms of performance, and for years we have been riding along the wave of “free” performance thanks to Moore’s law. In case you haven’t noticed, the party has ended. That, combined with increasing performance of the GPU, means we can no longer get free performance from CPU alone. Someone has to do the work to manage the GPU+CPU dichotomy and ensure that the “pipeline is full” so as to speak. Thankfully game engines are now taking on that role, but the graphics API needs to allow them to have full access to the low level capabilities.
Hint: it’s exciting. Expert Peter “Durante” Thoman takes a technical deep dive into the promising potential of DX12.
Some of you might know that COLLADA was not supposed to be used as an end-format in itself (like say OBJ) but more as a interchange format. To quote Wikipedia,
COLLADA was originally intended as an intermediate format for transporting data from one digital content creation (DCC) tool to another application.
It was meant to solve the difficulty of using digital assets across different tools. For example, if I scanned a 3D point cloud and processed it in Geomagic, I want to be able to use the result in say, 3DS Max for further work. 3DS Max obviously cannot open Geomagic files, so most of the time, the DCC artist have to figure out the intermediate format that’s supported by both software, and use that as a mid-point to bridge the gap. That is, instead of A->B, you go through an intermediary X, via A->X->B.
While it sounds logical, it usually doesn’t work in practice. First of all, 3D formats are not like image formats, which are fairly standard except for headers, compression etc. You can get pretty good results in image format conversions. Even though you might get some loss in image quality, the result is usually fairly acceptable.
Once you go into 3D, lo and behold, the problem size explodes. There are many types of mathematical models for 3D representation – polygonal, point cloud, parametric, volumetric, etc. Even within one representation you have tons of parameters. Each software chooses how it wants to use and interprets those parameters, and it varies widely from software to software. The result is that moving digital assets across software is a pain. In fact companies exist to sooth those pain (Right Hemisphere, Okino).
Sony Computer Entertainment, being a game company, must have faced a lot of such issues. The solution it created was COLLADA, to fill the missing X that plagues the industry. In 2004, it generously donated COLLADA to the community. The competing format back in the days was X3D, the successor to VRML. X3D was mainly driven by the academia, and did not have the kind of backing COLLADA has. It happens that Google Earth was looking to introduce support for 3D models around that time. Previously, it could only support imagery and terrain data. By a stroke of luck COLLADA was adopted as the native 3D format – even though it’s actually an interchange format. SketchUp soon followed, in a somewhat clever move – it was acquired by Google shortly after. By then, Autodesk and the rest of the big boys were on-board and the rest, as they say, is history.