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

Feedback requested for adding choosable polygonizer #399

Open
wants to merge 3 commits into
base: master
Choose a base branch
from

Conversation

brycecovert
Copy link

I'm working on making it possible to choose which polygonizer algorithm to use. I do this because I'd like to use one of my polygons for navmesh pathfinding, and bayazit gives a much better result than ewjordan.

Right now, I've got the view component correctly updating the geometry, but I'm not certain about whether or not the PolygonComponent would need to store the polygonizer algorithm as well, in order for it to be persisted when saved and used when moving points/updating the polygon using the PolygonTool.

Is the correct approach to have a polygonizer field on the PolygonComponent?

Thanks,
Bryce

@coveralls
Copy link

Coverage Status

Coverage decreased (-0.008%) to 6.221% when pulling d4baca7 on brycecovert:master into aaf76b6 on UnderwaterApps:master.

@brycecovert
Copy link
Author

@azakhary @Sasun any thoughts on this?

@azakhary
Copy link
Contributor

I have mixed thoughts about this.

a) I was thinking that when you make yo polygon, you just make the "outline" (the actual polygon) and it's probably best to store it as is. Because it can be used for many different use cases. Sometimes you want to split it into many polygons, sometimes you want to split it to triangles for rendering, and so on, so it's up to end-user code to process it. And thus, editor should not poligonize anything.

b) But in contrary, currently editor is processing and poligonyzing, just using one algorithm, I was hoping to remove that completely (because see point a.) But on the other hand at this moment if we have one algorythm why not add the other.

I am not sure, I am gravitating that point "a" makes more sense, what you guys think?

@brycecovert
Copy link
Author

Makes sense. My primary use case for using overlap2d would be the ability to draw polygons for pathfinding, and I'd rather not have to write the convex-polygonization algorithm myself. I can see both sides of that -- on the one hand, maybe the editor shouldn't care how to split up the polygon. On the other, as a developer, having a tool that allows me to see the polygons allows me to visualize the best way to set up pathfinding.

Would it be crazy to add polygonization as an optional action on a polygon? That is, instead of polygonizing by default, have it be a boolean flag whether to polygonize, and then allow the user to select the method.

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.

3 participants