Okay, hello everyone, and welcome to my presentation about all of them to vote.
The free D-Renderer for OpenStreetMap Data.
OpenStreetMap does not need an introduction anymore, it's been featured in the maturity
of talk in this room today, but because most people still interact with OpenStreetMap through
a 2D map as a primary user interface, it might come as a surprise that OpenStreetMap is
fully capable of all the power rings, 3D maps, and to do that, it needs a bit of software
to actually convert this inherently to the data model into 3D models, and OpenStreetMap is
exactly a piece of software that can do that for you.
To figure out what OpenStreetMap does exactly, I think it's a good idea to start with
the input side.
On the input, we are using OpenStreetMap data, and I'm using buildings as an example
to explain how exactly that works, because if you are familiar with the OpenStreetMap data model,
you will also know that the geometry in OpenStreetMap is really just 2D points and 2D lines,
and there's not really any 3D geometry in their natively.
Instead, the 3D part comes in with tags, with attributes that are added to the geometry,
which may add information such as a building side, a building's number of levels, and
that's where the set dimension comes in.
This also means that to actually get a 3D model out of this, you need software that
understands all these different tags that can be applied.
For buildings, or parts of buildings, this might also include the building's color,
the building's material, or the shape of the roof, taken from a catalogue of common roof shapes,
and putting that all together, let's get some pretty recognized the building shapes
despite OpenStreetMap's 2D data model.
The same logic applies to pretty much everything else that's in OpenStreetMap.
That includes simple indoor tagging to represent the inside of buildings.
But also, for example, roads and hundreds of other types of objects, some of which people
added with the intention of having them shown on a 3D map, but most of which were just
added for other reasons, but can never the last be used to improve the visual appearance
of a 3D scene remarkably.
When we talk about adding OpenStreetMap data to it, there are many different ways of storing
and transmitting OpenStreetMap data, and OTHM to work supports a pretty large subset of those,
and for different use cases, you might want to prefer different methods.
And just to be clear, when I say I'm using OpenStreetMap data, that means data in the OpenStreetMap
data format.
If you want to render, for example, historical data, or even fictional data for some
fantasy cities that you just made up, you can also do that as long as your stores that data
in the OpenStreetMap data format and then feed that into OTHM to work together 3D model.
Okay, let's move on to the output side.
The output consists of 3D models, but 3D models are again stored in a large number of
formats, of which OTHM to work supports individual model files in OBJ and GLTF format.
Image is rendered from the 3D models, 3D types, more on that later, and interactive scenes.
First, let's talk a bit about GTF, because that's really the format you should choose if you
don't have any specific preference, because it supports larger subset of features from OTHM
to work, that is most of OTHM to work can do, will support, will be supported by an expert
to cheer it up.
It's an open standard for 3D models and tons of engines and editing tools into 3D
ecosystem supported, so if you want to have your OTHM 3D models in Blender, for example,
that's easily possible by just exporting FGTF and importing into Blender.
When working with GTF, OTHM's words have a few nice features such as support for binary
GTF or compressed output, the choice to have a single file containing everything that needed
for the 3D model or showing texture separately, and the option to have various kind of post
processing steps applied to your 3D model.
One use case for GTF export is to have 3D tiles.
That's when you want to have 3D model of an area that's too large to store everything in a
single file, and the most popular way to address that problem is to have a regular grid where you
slice, you're seeing into a square-like shapes that can be posted together to form a larger area.
And OTHM provides easily generate them for you, just gives the bounding box or set of bounding
boxes you want 3D tile for, and it will generate them all.
The most popular standard for 3D tiles is the 3D tiles standard, and again OTHM to
write supports the necessary extra files in addition to the model to make it compatible with
that standard with the current exception of not supporting the more modern feature of implicit
per wood tiles yet, but that's a work in progress at the moment.
If you want to try out those 3D tiles, there is a demo for some countries, unfortunately
in charge of Germany or Switzerland at the moment, available on the OTHM to work at website,
but I would recommend doing that with a laptop or desktop computer because I haven't put much
effort into tuning in from OTHM yet.
Okay, after input and output, let's look at how we actually use OTHM to work, because there's
more than one way to do so. Specifically, there are several ways that we will now look at one by one.
The first is to have a 3D tile server. That's like with the examples that I mentioned before,
the demos that featured on the website, you have a server that calculates the 3D models,
and you have one or many clients which download these models in order to show a 3D world.
This means the calculation, the conversion from OTHM streetmap data to models happens on the server,
but surrendering, so you think some real-time acceleration in graphics hardware happens on the client machine.
You can, however, also run OTHM to very detail locally or on your own server,
and if you want to do that in a way that can be scripted, you might want to use the command line interface.
The command line interface exposes most functionality of OTHM to world, and it uses some sense of
default so that, for example, if you want to convert some OTHM data to an image or a single 3D model,
that only takes an input and output parameter for the converts up command, but of course,
if you want to, you can also control all sorts of things such as a camera angle by adding additional
parameters to that command. Command-line scripting works across many platforms, but
if you are using OTHM to world on a machine that has travel support, you could also use it
as a software library directly in some software running on the JVM, by using the
name or gradal packages that are available for the purpose, and which are documented on that URL.
I am currently 95% complete to also offer a library interface for
JavaScript running entirely in the browser, so at that point, you will be able to do the conversion
from OTHM data to 3D model entirely in a browser client and will no longer need any server
if you don't want to. That's also a desktop client, which is a pretty old feature of OTHM
for world. It's useful if you prefer having a graphical interface over using a command line interface,
and it's also very useful if you are editing open street map data locally, for example,
this chosen or a similar editor, and want to have a preview before you upload the data to the server.
But for this particular use case, I am also currently working on editor integrations,
which essentially gives you a 3D preview directly in your open street map editor.
This example is using a modified version of the urban i3D plug in with an OTHM to world back end,
but I am also working on potential integration for other open street map editors to make it
as easy as possible for a large subset of the OTHM community to contribute 3D data.
This work on editor integrations is currently being supported by the prototype fund,
which is an open source support initiative by the German Federal Ministry of Research, Technology,
and Space, so let me say thank you for funding me to work on that.
Okay, so we've looked at the input output and user interface, so as a final part of this presentation,
I would like to take the opportunity to look more closely at a few of the steps that happen
in between the input and output. So what kind of things does OTHM provide actually have to do in order
to produce those 3D models? The first one is to look a bit at AFF, which in my writing here includes
tech-driven models. Tech-chairs are present in pretty much every 3D model, and as a use of OTHM
to world, you don't really have to bring your own OTHM to world shifts with a large collection of
tech-chairs and a default style that you really only need to edit if you want to have your own look,
otherwise it can just use a default tech-chairs. It has tech-chairs that are after images,
back to images as well as some that are generated at program runtime. For example, text on traffic
signs will only be generated at runtime in order to not need a single tech-chairs file on your
computer for every potential tech that might appear on a traffic sign somewhere in the world,
so it just generates the tech on that particular sign value runs program.
It's a port tech-chairs not just for the color of the object, which is the most common type of
common tech-chairs, but also for all the other types of tech-chairs which are used with
physically-based rendering. If you don't know physically-based rendering, that's not a problem,
but it's a common way to essentially simulate the interaction of light with 3D models in
modern graphics engines, and it's also supported by the GTF standard, so to make full use of those
abilities, OTHM to world, also support these other types of tech-chairs, which describe a
material properties, other than just the color of the material for a more realistic visual appearance.
For performance reasons, it combines some of these into a single tech-chairs, so that you don't
have that many of them. For some features, it's not easy to find readily available tech-chairs
on the internet somewhere and not everyone is a graphic designer, so OTHM to world also has the
ability to generate those tech-chairs from geometry automatically by just placing a virtual camera
in front of the object and creating the texture. Because some engines do better with a small number
of large tech-chairs on the other way around, OTHM to world can, optionally, all the combined
many tech-chairs into a few larger ones with a so-called tech-chairs at last. It's case tech-chairs,
so that they fit neatly onto geometry, and yet that brings us at the end of the part about
tech-chairs, and then to before us, that assets also include 3D models. So for the most part, OTHM
to world create the 3D models during one time from OTHM street map data. But some kind of features
you might actually rather want to model by hand or download from some side, for example,
in the scene the car models are obviously not from open street map. It's not updated that often
that we move a note every time someone moves a car, so instead those assets randomly placed,
and we can supply models of cars through the map style and randomly values a color as well.
But the external models don't just allow us to show these kind of generic models such as cars.
They also allow us to fetch models from the 3D model repository, which is another open data
project which allows us to have 3D models shared by users and linked with OTHM street map.
One potential use case is landmarks, such as the iFitower. OTHM does allow mapping 3D buildings
to some extent, but there's a limit to the level of detail you can express with just notes and
ways. So when you go beyond that limit, you can use 3D models and OTHM towards we place them
in the right location in your 3D world. The second feature spotlight is much shorter,
but I wanted to have a quick look at real-time performance and level of detail.
So OTHM's world does also details that add some extra bits to a scene such as like ballads,
traffic signs, bicycle packings, then lots of more details that have a significant
performance cost if you have too many of them. So the usual trick to give us that is to have
a high level of detail for areas close to the camera and a low level of detail for everything else.
And to enable that technique, OTHM toward can export a scene at different levels of detail,
depending on what the user asks for.
And finally, something I also find interesting, the way OTHM towards deals with objects that
are connected to each other. Often in open street map, you have things that are just
discrete objects. So there's one point that represents a weight bar of kit,
another point that represents a street lamp. And so they are entirely distinct objects.
But in the real world, sometimes you have a weight bar's kit that attach to the street lamp.
And you can describe that fact in open street map. And if someone describes it in open street
map, I also want to support that information in OTHM toward. So the weight work is,
I have so so called attachment connectors, which is just a point in this case on the weight bar's kit,
that wants to connect to some other object nearby. And if it finds an object of a suitable type,
the attached object is just moved and rotated such that it fits smoothly onto the other object.
And you get the appearance of a seamless model despite the fact that open street map had two
separate notes next to each other. This can be used for many other things too.
Like for example, there's a traffic sign attached to the street lamp as well.
Maybe there are solar panels attached to the roof of a building. Maybe there's a rooftop parking
on top of the building. Maybe there are objects such as billboards attached to a building's voice.
Maybe there are objects such as tables inside a building that are placed on top of the
earth, a second or third floor of the building. Maybe there are objects on the bridge and
object below a bridge. And you want to object above the bridge to attach to the bridge so that
there are higher absence of one's below it. And many things like that can all be described with
this attachment connector concept. Again, with the goal to make the mode out of open street map data,
when converting it to speedy models. Yes, that brings us to the end of my presentation.
Please have a look at Oatham to Verge. And if you have any questions,
either of them right away or get in touch with me at the conference or through digital context channel.
Thank you for attention and looking forward to your questions.
Hello, thank you for your presentation. I have a question regarding the library you use and
the sense that you choose to use a barbell on that yes for the ring. Why you choose to use this?
Why not to use 3GS directly? I'm not sure. Why did you use Babylon JS?
Is that the 3GS?
So, they would both work pretty much equally well for that use case. I mean, I already have ready
made 2GF models and both are able to load 2GF objects and play them in a scene. It's really
out of just a few hundred lines of charge script, most of which is boilerplate, though it was
down to personal preference. It works with both of them and, yeah, if you want to use 3GF to
end the Oatham to Verge model, that works perfectly fine of them.
I'm yes. So, Oatham to Verge output GATF5 and that youth case and for GATF load up for 3GF,
I feel that you feel it compatible. Thank you so much for the talk. What is your kind of policy
on porting to other programming languages so that they can take advantage in the same way
of the library elements? Like you said your point in porting to JavaScript is their opportunity
like port to Python or GoLang to be able to provide the same OSM to 3D model conversion.
So, so far, I've only done it if I could have a single code base that is automatically converted
to other platform. In the JavaScript case, that works through TVM, which is a Java to JavaScript
or web assembly compiler. So, essentially, I want to avoid the situation where the port would
diverge. I've got your free to port it yourself, but in that case, it would then be more like a
fork. Yeah, it's going to ask would you be open to me or someone else porting to a different
programming language? So, I'm trying, I've also have the goal of supporting at least Android
of value, which should be relatively easy. Python is probably harder, essentially an external
or native dependency. And then my other question, when you said about the models connecting to one
another, a common way of tagging the footpaths, pedestrian paths next to a road, or like the
pavement is to have it as a separate way. Does it handle that correctly like matching up the
fact that the pavement of the road might sometimes be tagged on the road itself and sometimes might
be tagged as a separate way running parallel to it? I've not been able to handle
separate limit footways in a robot version yet. So, if you tag them on the way, it works,
you get just a curve that is a few centimeters high and then you get the side walk seamlessly
attached to it. If it's a separate footways and you get separate ways next to each other and
whether they line up depends on whether the width is accurate, which is almost never if. I do have
a work, a proof or concept implementation of area highway support, which would also essentially
be easily extendable to that use case because it works on basically shooting rays outward
until it hits an edge that ends the road and then you would at least get seamless transitions
between the sidewalks and the Fenterway. Thanks so much. How does a generic 3D tile server handle
you had textures that had like reflectivity defined? How do you, because
do like does like Google Maps ingest that information when deciding how to render it?
So, in my case a 3D tile server works pretty much as in the 3D tile standard,
which is basically just a tile system that has TFF files as it payload.
So, anything that's supported by TFF or TFF extension can also be inside a 3D tile.
I believe Google Maps, I mean, I've not looked at their implementation but I don't think they have
exactly the same concept and that at least Google Earth had some iterative refinement thing,
which are loads a cause version of the geometry and then increasingly detailed measures added
into that object that more involved than what I do which is essentially just a file that's downloaded
as a single unit and then at that point replaced with a high level of detail tile of the same
location but it's at this creeps that between low level of detail, high level of detail.
So, it's up to the client basically. It's pretty much up to the client.
Yes. I mean, if you export these extra C-thium 3D tiles compatible tiles that
often then it adds a few other bits of information like about the maximum allowed
error and things like that. So, at that point it, you should behave like C-thium in order to have
a standard item implementation.
Some more questions?
No, we've got a question.
Thank you for the presentation.
I mainly wanted to ask about the requirements when it comes to hardware, how accessible it is to
what's going to happen. What are the capacities? You need in your laptop in order to
be able to navigate seamlessly.
Mostly depends on, I mean, you can tune it with, like, unit distance and a few other parameters.
So, I think the most important level to have, like, how far away do you still show objects
and how high is the texture resolution? If there's a low enough then it should also work on
laptop with integrated graphics or otherwise lower specs.
I also have this JavaScript implementation and to do that I also wanted it to work on mobile devices,
which is even harder to give it and it works excellently for individual object or small areas.
The part why the demo doesn't work is that the demo actually loads data quite far away and that
box down the performance too much from a mobile device. But if you don't do that and just
focus on, like, a few buildings or so then it should work on most hardware out there.
Thank you. And if I understood well, you have two ways of doing it, either you choose the bank
of features of little details or you can add your own texture or your own detail, right?
So, essentially, I'm privileged takes parameters for the level of details that you want,
which will then result in quarter or finer grain output and it also lets you essentially add
a matte dial that replaces some of all of the textures that is used by default.
I mean, you could use that to use lower resolution textures in which case it would also have
a performance impact or you could do it if you wanted to look differently to have your own
like visual style and your different texture to achieve it.
It's up to you to make it know that it's for example, Paris and not Berlin, for example.
Well, as I showed the different ways of using the software,
on the command line, you would pass in some kind of latitude or longitude or tile numbers,
which are other just the way of defining a location on the earth, with a free detail client,
you usually have clients that have some search field or something where you type the name of the
location you want to go to. So it depends on the user interface, but it always lets you control
the location in some way. I hope that hopefully I've not come to me after the talk.
So I have another question you said about being able to selectively choose the models that might
be replaced the standard OSM data like use the example of the Eiffel tower. How exactly does
that configuration selection work? Does it happen in a configuration file for OSM to world or does
that happen as tags on the object? Would you be able to do that for custom buildings that aren't
necessarily a known landmark? Both options are possible. So first there is a tag for specifically
this 3D model repository, which some people use inside open street map to add a link to a 3D model.
If you enable that feature on OSM to world, it will replace objects that have this tag with
data from the 3D model repository. You can additionally, in your local OSM to world configuration file,
assign 3D model to particular open street map ideas. So you can say I want node
1,353 to be replaced with the model that's at my model.tf part location on my computer and then
it will use that Eiffel. Is there a contention about using the open model repository inside of open street
map data? Because that feels like it clatters up data a lot of objects. At the moment the
model repository has so few objects that the problem hasn't had written yet. I guess if at some
points there are a thousand millions of models and three community would have to do that. But at
the moment it's so rare compared to like we can meet your comment links or Wikipedia links,
which number is the million that I don't think it has shown up as a problem on many people
3D. I might add some blades of grass to the open model repository. Any more questions?
Well, if not, then we go. Have you had any experience with loading the models into
mapping libraries? So I'm assuming this works with something like CZM, because it's probably pretty
well first in handling models, but not the mapping libraries, I don't know,
not the rest brings to mind. And so I did a prototype of meshing it up with my plea for one.
They have some kind of how to in the documentation of using, I think it was published as
may have been featured as well, to eventually mix up this well, essentially vector tie-based
thing with additional 3D models. And yeah, as a prototype, I essentially hacked in my 3D
tie if you enter that and it works. But at that point, not really a mableeper feature, but yeah,
you're using mableeper to end one part of the scene and then do by hand some extra code that
loads the 3D models into that same scene. So it's not a native 3D tie support, but you can make it work.
You're just sort of loading 3D models into mableeper basically.
Yeah. And if you have that logic, I mean, the 3D tie logic is pretty simple, it's essentially
load in the current location and when you move to where you delete the one that falls off the edge
of the bird and load the new one. So thank you.
Good time for another question. Anyone? If not, then I think we should thank the speaker again.
And that's the end of the bedroom. Thanks very much for coming. See you next year.