-
Notifications
You must be signed in to change notification settings - Fork 25
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
utils_poly #46
Comments
should the prefix of these functions be consistent with the input..? (or the return?) |
If I remember well, poly was supposed to work on 2D polygons. for example utils_geom2D? or utils_vertex2D? |
regarding confusion in vertex class: |
i was too fast then in just renaming the methods to the new snake_case convention. but anyway, i think so far we did not use any of the methods inside of this module. we can also just hide its import in the init.py file and leave it there until we need it? |
Shall we close this issue? |
i would keep this a few more days as a reminder. we are still using the same structure in 0.4 but i'm thinking to make it a bit clearer. |
I was planning to move around some functions, that's why this was not yet renamed.
now there's some confusion as to what goes here and what goes in the utils_vertex.
The utils_vertex currently has the
vertex_
functions (add, subtract etc.)vertices_list_
functions (input is a v list)triangle_
functions (input is 3 vertices)then there's some functions with different inputs and questionable naming like
def vertex_offset_point(v1, v2, v3, offset1, offset2):
def vertex_line_line_intersection(a,b,c,d):
The utils_poly has some functions with vertex input, but a brand new prefix, like
normal_
def normal_edge_2d_non_unified(vprev, v):
plus a
construct_
function which normally returns meshes except in this caseconstruct_circle
should we clean this up? ideas?
The text was updated successfully, but these errors were encountered: