Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poly2tri #55

Merged
merged 6 commits into from May 26, 2013
Merged

Poly2tri #55

merged 6 commits into from May 26, 2013

Conversation

hjanetzek
Copy link
Contributor

Please review :)

Compared to jts conforming delaunay, poly2tri only adds vertices where necessary for triangulation so it results in much less vertices which reduces obj file size and less vertices to interpolate which should make it faster. Also the results look better on complex roof as the interpolation finds not the best segments sometimes (or there are none)

roof_poly2tri
vertices: 2266, faces: 3773

roofs_conforming
vertices: 3124, faces: 5203

http://city.informatik.uni-bremen.de/~jeff/dom8.osm

- test if ridge/edge lie on the boundary, pnpoly is not reliable in this case
  - this way single sloped roof can be defined by adding only one ridge on the outline
@hjanetzek
Copy link
Contributor Author

an update to the last commit:

/* join colinear segments, but not the nodes that are connected to ridge/edges

  • often there are nodes that are only added to join one building to another
  • but these interfere with proper triangulation. */ <- I mean correct height interpolation of the triangulation

visible at the center and left green domer

roof_merge_colinear

@tordanik
Copy link
Owner

First off: I agree with you that poly2tri's constrained "Delaunay" triangulation is often preferable to using the algorithms available in JTS, so I will eventually merge this.

What makes this a bit more complex is that I've actually experimented with that same library myself recently for a different part of OSM2World (SRTM terrain heights), and have therefore written my own wrapper code. This means I would like to take the time to compare our approaches and pick the best parts from each. I will probably will not get around to doing so before the end of next week, though.

By the way, a drawback I've noticed while working with poly2tri is that it is very touchy when it comes to the input. If the data it isn't perfectly prepared (filtering duplicate vertices and so on), it is prone to just crashing with stack overflows and stuff - which cannot even be properly caught like exceptions from JTS can. How successful have you been in reliably avoiding these?

@hjanetzek
Copy link
Contributor Author

I have seen this problem with poly2tri in another project but there I was using the default polygon triangulation. The big issue here was to figure out that TPoints with same coordinates need to be unique objects to make constraints work. It was just my last guess before I would have dropped that library and have used Triangle via jni.. To your question: no stack overflows so far :)

tordanik added a commit that referenced this pull request May 26, 2013
add poly2tri library and use it for roof triangulation
@tordanik tordanik merged commit d0c7701 into tordanik:master May 26, 2013
@tordanik
Copy link
Owner

I'm finally getting around to working on this again, sorry for the delay.

The poly2tri topic is not completely finished yet as I will have to merge my own code with yours. I may open an issue for this task once the code is ready for that; I hope that you will help out there a bit. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants