Sorry, I can’t say that much, as the rendering disappears always after it’s finished and I just see a blank canvas:
I used FF 20 and WebGL seems to work corresponding to the WebGL demos form Mozilla.
Maybe you can fix that?
I never heard about that company before, so excuse me, but who are you exactly?
And which Workflow, Data schema do you use?
This is a known issue in the post-process code we don’t know why sometimes the graphic driver returns a broken RenderTarget, you can try with this link http://map.f4-group.com/#postProcess.enabled=false (it deactivates the outline post-process)
It looks really impressive due to the lightning/shadows and interaction (animation, camera perspective, …). Great job!
So I checked the areas that I worked on (Rostock, Schwerin) and see that there seem to be small misinterpretations of the S3DB and that some tags arent’t recognized yet (materials, some roof shapes and orientation, …). Another problem seems to be clipping with overlaying building:parts. That can be even a modelling problem, but maybe this can be solved within the conversion automatically?
Currently I’m still suprised, that you come with this brilliant project, while a few devs already tried similar approaches but they didn’t finished yet. So please, give us some more details
I’m sorry but there is no chance to get the code source or models for free.
For performance reason we are not handling everything for now, this is a non exhaustive list:
buildings and roof color
roofs shapes (flat, pyramidal, hipped, gabled, pitched, dome, onion, mansard)
barriers (wall, fence and hedge)
forest, tree, tree_row
artwork (sculpture and statues)
chimney and nuclear water cooling
wind generators
fountains
cemeteries
lighthouses
power lines, poles and towers
…
I highly recommend, that at least the interpretation of buildings should be checked against the S3DB schema and compared to OSM2World and Kendzi interpretation. Otherwise, people might start (wrong) editing, if you roll out, because they expect the tags on the buildings to be wrong. After a short check, currently none of my multipart buildings look completely right.
My questions is, why didn’t you used one of the already existing converters, as OSM2World for example to create your vector tiles?
Concerning the question of kendzi, IMHO, your 3D object DB is derived from OSM dataset, thus it needs to be licensed under the terms of the OdbL? So I expect that Kendzi can take the models under the terms of OdbL?
P.S. Small note: Currently you lack osm attribution.
I’m definitly not a legal expert, but from my POV:
OSM dataset is ODbL and the base for that computation
It’s enriched with ‘magic’ (extruding houses, applying 3d markers, …)
this new dataset is combined and saved in a 3D database
If you reflect the complexity of the single objects, I (personally) would expect that the whole dataset (and so every single object that is complex enough) is licensed under the same terms. But maybe this is a good question for OSMF LWG, this is just my intuitive feeling
Actually the building models are created on-the-fly from raw osm2pgsql data on the client, which I find really impressive
Regarding your concerns; would you say one has to make a font freely available when creating tiles for a custom map style? I would think this is an analogous case here
We are not using a converter nor a ‘3D database’, the extruded stuff you can see on the map is computed client-side on the fly.
The osm copyright was displayed in the legal page but i just realized this page is not accessible anymore since the last UI refactoring (some heads will fall tomorrow…)
Concerning the “real” 3D models (the tree, the lighthouse, the Eiffel tower…) they were modelled in Maya and exported in a specific binary file format and so are property of our team.
Yes, very impressive. Worked out of the box on Firefox 15 the first time, although going back a few hours later, I’m no longer offered the choice to switch between 2D and 3D.
I love the fountains and trees. In Munich the river seems to be flowing the wrong way - is this a problem with the underlying ways?
Another aspect might be currently not within the S3DB specs: defaults
So kendzi/tordanik use yellow as basecolor for buildings. Even if your white looks really nice/modern we should try to unite the interpretations. Or no tool makes use of a default colour to show the user, that you need to specify everything?
For now we used 2 default colors for walls and roofs when they’re not specified with osm attributes, we specified a white/gray combo to get and architect sketch look.
I think the differences could come from our interpretation of building size:
total height (defined by ‘height’ or ‘building:height’ or (‘building:levels’*3 + ‘roof:levels’*3)). roof height (defined by ‘roof:height’ or ‘building:roof:height’ or ‘building:cullis:height’ or ‘roof:levels’*3 or ‘building:roof:levels’*3) wall height = total height - roof height [- min_height if specified]
In addition to that i think that the aspect ratio & camera fov differences between your rendering and our make the comparison quite hard.
EDIT:
I just found out that removing the polygons with id=209603824 and id=96820490 gives a mush better look for “Schwerin castle”.
It seems that these 2 buildings are only partly rendered in osm2world.
A understandable decision. Unfortunatly this is different from the way the dev community handles it currently, which can result in artifacts. In the case of the castle, it’s really yellow. If a building is white, I wether specify it with building:colour=white
For now, only S3DB is the only semiformal agreement of the most of the devs. The levels should be only considered, if there is no other height information. Usually it’s just to generate a texture of windows and we encourage users to use dedicated height values to describe the geometry.
This is somewhat true, but O2W (for what I can say) is highly customizable, so you explore areas in the same interactive way as within your client.
I guess you know, that tagging schemas are only semi-formal here at OSM. So you need to consider, how it is used in the wild. Thats why the 3D staff offered the demo areas and example files to show you, how the current interpretation should look like.
Sorry, I have no idea, what you removed
But please take care of the “we don’t tag for single renderers rule”.
I think, I have to correct you. You have defined ‘roof:height’ and ‘building:cullis:height’ as the same, but they are not! As seen on this wiki page the ‘building:cullis:height’ is the height of the top line of the wall just below the roof, not the height of the roof. I see it as the min_height of the roof.