Real time 3D map using WebGL

There is the comparison between our rendering on this church (you can’t see the changes by yourself as the release server osm synchronization was down but i made a screenshot from our map on the dev version)

We got a differences on :

_ non squared pyramidal roof
_ height of the roofs yours seem to be slightly higher
_ our algorithm does not handle skillion for now (we should work on it soon)
_ the building on the right side is built with complex relation that we do not handle

I believe the interpretation of pyramidal roof for more than 4 corners is still under debate. I would vote for the ‘shed’ style that you have as it’s already the more common* use and for the squared-pyramidal style it is really hard to define how to apply it consistently.
(* http://overpass-turbo.eu/s/l6, imported to JOSM and compared to bing)

Do you scale height according to ground resolution in mercator projection (relative to latitude) ?

Yes, it’s using a proposed tagging. I’ll fix it to also use proper tags for S3DB when possible.

And because of that where was proposed in S3DB relation which group all building outlines and building parts. When relation exist it is trivial to render building correctly:

if relation exist and have members with building:part tag => render all building:part=* from relation
if relation exist and don’t have members with building:part tag => render all building=* from relation
if relation don’t exist => draw both.

Relation give some more benefits as they group all building members for selection or they can define common ground level for all bulging parts.

Currently as I known only Osm2World try to guest without relation which building outlines should be hidden. Many people tags for this render.

I try to make discussion here but it seams no one is interested in it. So as most application render it this way I will change it in next Kendzi3d release. In my opinion squared-pyramidal roof can be apply consistently as the same any other roof :slight_smile:

That´s true! Let´s talk together about it. Don´t change because some people don´t understand it.
Best regards,
Marek

Say, you have a pentagon outline, how to determine orientation of the pyramidal square? - Just my quick reply. We should move to another thread for this

@cmif4: I was curious how the postprocessing looks (It does not work on any linux machine I tried). Chrome webgl inspector shows that no UV buffer is bound for the texture plane. As a work-around changing
“vUv = vec2( uv.x, 1.0 - uv.y);” to " vUv = vec2( clamp(position.x * 2.0, 0.0, 1.0), clamp(position.y * 2.0, 0.0, 1.0) );" in common2D.vshader to translate position to uv coordinates makes it work here. I would suggest to check why the buffer is not created in the first place :). WebGL inspector also show lots of warnings when capturing a frame which might have to do why ground textures do not show on OSX (using chrome) http://pastebin.com/etN0yGEM

Thank you for this report,
i was already aware that my outline/ssao code was not working under Linux but the uv code you gave does not work on windows (it renders only 1/4 of the screen)

This works for me under windows

vUv = vec2(position.x + 0.5, position.y + 0.5);

But the real issue is that linux driver “loses” my uvs (on JS side they’re ok as i’m using the same kind of geometry plane for post-processes and ground tiles).
I got a similar issue with MacOs where fountain/smoke particles receive the normal instead of the vertexColor (with right values on JS side).
I now have a integrated GL debugger in the engine so i’ll have a Mac cleaning task in a few weeks

We’re now handling the scale factor from lat and got the same sizes as in kendzi3d.

We are working on round/gambrel roofs and we expect to get your building:part (pl)sql function working soon (tyvm for the tips).

this would work as well. Have you found the cause? Actually the shader compiler on Linux does its job properly and removes unused stuff from “depth” shader :wink:

Just tried on FF 21 & Chrome 27 with a Mac Mini and everything worked as expected.
2,5 GHz Intel Core i5
4 Go 1333 MHz DDR3
AMD Radeon HD 6630M 256 Mo
OS X 10.8.4 (12E55)

I need to find a Linux to reproduce the shader issues.

Ok, the issue depends on wheter the gl driver does strip unused attributes: When the postprocessing quad is initialized “depth” shader is the active material which does not use its “uv” attribute. That is why UVBuffer will not be created for the quad that should later be used by “outline” material, etc

changing material to something that uses uv before (first run of) update in postprocessing makes it work:

> this._quad.material = this._ssaoMaterial || this._outlineMaterial || this._bloomMaterial;
this._webGL.updateScene(this._scene);

Ty for investigating it (i was a bit busy on roof triangulation and real sun light direction this morning).

Btw i think that Linux driver is more optimized than windows one because my depth vertex shader is using uv but the linked varying was unused in the fragment shader (removed by some #define), i presume Linux driver looks for unused varying stuff on fragment shader and remove them.

Server has been updated a few min ago you should get PostProcesses working fine now

Hello and thanks for the feedback!
the building:parts are now removed from the building, and some data are inherited.
if you notice any glitch, please tell me and i’ll have a look.

Thanks for fixing this. Most areas seem to be ok :slight_smile:
There are minor bugs that might result from different defaults (roof angels, …) but they are minimal.

IMHO a nice last step could be to derive simple colors from the xyz:material tag. So brick is somewhat like orange/red, glass is blue, metal is grey, … . Maybe also using default colours as flat roof is grey and angled one somewhat red.
And if you have still time/fun you might add a default for building=garages (here in Germany 1 level buildings with flat roof with multiple doors for the cars)

Sorry, one more question:
I added yellow colour to all building (not part!) elements of the Schwerin castle, but it still appears in white. Isn’t the colour of parts derived from the building, or did it still need time to update the changes? (I edited yesterday afternoon)

Our osm-synchronization server was stopped for a few days so it’s a bit late. It should be synchronized again in 2 or 3 days.

It should now be in sync again.

I’m using ST_Intersects to determines if a part is in a building, but this leads to some parts having many building and i’m only keeping the last one (as returned by postgis), and this could make the part inherits unwanted attributes.
however using ST_Contains breaks some building too when the parts points are not snapped correctly to the building…

any advice as to what’s best ?

Where do you see this issue? I’m still working on my db functions for buildings.
Maybe this could work:

st_intersects(b, p) and not st_touches(b, p)   and st_area(st_intersection(b, p)) > st_area(p) * 0.99

or order by the st_area of intersection and pick the greatest.

BTW I tried to make the description of when to render the building outline more clear:
http://wiki.openstreetmap.org/wiki/Simple_3D_Buildings

It does not state to subtract building:part areas from building area, but this is what OSM2World does and I find it the most reasonable way to handle things:
http://wiki.openstreetmap.org/wiki/Talk:Simple_3D_Buildings#Too_complicated_description_of_building_outline_rendering

The issue Cactusbone was talking about is here but it’s not visibile anymore, i fixed it on osm side by tagging roof:shape=flat

As a picture is better than a complicated explanation look here : .

The building:parts from the white building between the blue and red one sometimes inherit from the blue/red roof:shape=skillion attribute because they got common nodes.

I think your

not st_touches(b, p)

should fix this.

I’ve added st_touches (thanks for that i didn’t know it existed) and 95% area check (great thinking here thanks again!), and i have not yet found another part to building error.

it can take up to 24 hours before buildings refreshes :slight_smile:

@Cactusbone, do you know what the issue with this building is? Or is rendering of the ‘building’ way still disabled when there are building:part inside?
http://map.f4-group.com/#lon=980249&lat=6997486&zoom=19&camera.theta=49.315&camera.phi=-167.2