search

kekscom / osmbuildings

OSM Buildings Classic 2.5D
http://osmbuildings.org
BSD 2-Clause "Simplified" License
505 stars 140 forks source link

Impact: Fix building occlusion #34

Closed bennlich closed 8 years ago

bennlich commented 11 years ago

Howdy! I just pulled the latest changes from the repo, and it looks like the z-indexes of some of my buildings are behaving strangely. I took a couple screen shots:

screen shot 2013-06-25 at 3 47 18 pm screen shot 2013-06-25 at 3 47 28 pm

Notice in the bottom image how the left teal building moves in front / on top of the shorter blue building. I hadn't fetched the latest repo in a while, so I'm not sure which commit is the culprit.

I also noticed that many of my buildings appear much taller than they used to.

I'll start looking at the new commits.

kekscom commented 11 years ago

Hi Benny, Unfortunately this is not really new. Though I fixed some z-ordering issues, problems are still present (and known). What I'm still looking for is a safe algorithm to determine the proper order of buildings. Its not as simple as it seems. I'm also considering a face-by-face algorithm but not decided yet. Any ideas are welcome!

Regarding size, depends on where the data is from. OSM, CartoDB, other? Ist height in feet? :-)

bennlich commented 11 years ago

Hey, Jan. Here's a picture of how the exact same dataset rendered before I pulled new changes:

screen shot 2013-06-26 at 1 03 27 am

The buildings are much shorter, and the occlusion seems correct (or is it maybe that the default transparency is just higher?) Also, the rooftops were automatically colored based on the walls. Here's what that same patch looks like in the latest version of OSMBuildings with the roofColor attribute added manually:

screen shot 2013-06-26 at 1 09 06 am

Did you make any recent(ish) changes to the z-ordering algorithm?

kekscom commented 11 years ago

Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).

Occlusion is the same, just noct that obvious due to transparency.

roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.

bennlich commented 11 years ago

Ah, k. Should height be specified in meters? It is a custom data set.

On Wednesday, June 26, 2013, Jan Marsch wrote:

Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).

Occlusion is the same, just noct that obvious due to transparency.

roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.

— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-20037074 .

kekscom commented 11 years ago

You can specify what you want, but the engine needs a base. As metric system is standard for OSM I've chosen this ;-) Just make everything a third.

-----Ursprüngliche Nachricht----- From: Benny Lichtner Sent: Wednesday, June 26, 2013 7:49 PM To: kekscom/osmbuildings Cc: Jan Marsch Subject: Re: [osmbuildings] Building occlusion (#34)

Ah, k. Should height be specified in meters? It is a custom data set.

On Wednesday, June 26, 2013, Jan Marsch wrote:

Regarding height: I've changed a correction factor which was not needed for OSM anymore. Looks like you are using a custom data source (probably height in ft).

Occlusion is the same, just noct that obvious due to transparency.

roofColor behavior changed from beeing like a bar chart towards more controlled building attributes. You now need to set it explicitly.

— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-20037074 .

— Reply to this email directly or view it on GitHub.

bennlich commented 11 years ago

Okay, coolio! Thanks for all of the prompt replies.

As for the z-ordering algorithm, my intuition is that the only way to do it safely would be face-by-face (assuming the alternative is building-by-building?). For example, if you have a donut-hole building inside of a donut building, the donut-hole could occlude part of the donut, and the donut could occlude part of the donut-hole.

kekscom commented 11 years ago

Perfect example. Face-by-face makes the code a lot more complex but ideally the drawing gains speed. I just need a point to start with...

-----Ursprüngliche Nachricht----- From: Benny Lichtner Sent: Wednesday, June 26, 2013 11:19 PM To: kekscom/osmbuildings Cc: Jan Marsch Subject: Re: [osmbuildings] Building occlusion (#34)

Okay, coolio! Thanks for all of the prompt replies.

As for the z-ordering algorithm, my intuition is that the only way to do it safely would be face-by-face (assuming the alternative is building-by-building?). For example, if you have a donut-hole building inside of a donut building, the donut-hole could occlude part of the donut, and the donut could occlude part of the donut-hole.

— Reply to this email directly or view it on GitHub.

kekscom commented 11 years ago

I added a quick fix for most occlusion cases. Please give it a try.

bennlich commented 10 years ago

Sorry this has taken me so long to get to, Jan! I'll give it a try soon.

On Thu, Aug 8, 2013 at 11:51 PM, Jan Marsch notifications@github.comwrote:

I added a quick fix for most occlusion cases. Please give it a try.

— Reply to this email directly or view it on GitHubhttps://github.com/kekscom/osmbuildings/issues/34#issuecomment-22378048 .

bennlich commented 10 years ago

Yes! The occlusion is much better! How'd you do it? I'll let you know if I find any more culprits.

kekscom commented 8 years ago

Honestly, a fix is unlikely anytime soon, if at all.