Skip to content

Conversation

@bragostin
Copy link
Contributor

BRepBuilderAPI_MakeWire::Add(const TopTools_ListOfShape & L) offers the option to accept a list of shapes directly as argument:
Adds the edges of <L> to the current wire. The edges are not to be consecutive. But they are to be all connected geometrically or topologically. If some of them are not connected the Status give DisconnectedWire but the "Maker" is Done() and you can get the partial result. (ie connected to the first edgeof the list <L>)
Following this I modified the assembledEdges in shapes.py to be able to provide a list of unordered edges to BRepBuilderAPI_MakeWire. This way, when the list of edges is generated by another function, there is not need to make them consecutive.

BRepBuilderAPI_MakeWire::Add(const TopTools_ListOfShape & L) offers the option to accept a list of shapes directly as argument:
"Adds the edges of <L> to the current wire. The edges are not to be consecutive. But they are to be all connected geometrically or topologically. If some of them are not connected the Status give DisconnectedWire but the "Maker" is Done() and you can get the partial result. (ie connected to the first edgeof the list <L>)"
Following this I modified the assembledEdges in shapes.py to be able to provide a list of unordered edges to BRepBuilderAPI_MakeWire. This way, when the list of edges is generated by another function, there is not need to make them consecutive.
@codecov
Copy link

codecov bot commented Dec 13, 2019

Codecov Report

Merging #237 into master will increase coverage by 0.04%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master     #237      +/-   ##
==========================================
+ Coverage   94.86%   94.91%   +0.04%     
==========================================
  Files          18       18              
  Lines        4190     4226      +36     
==========================================
+ Hits         3975     4011      +36     
  Misses        215      215
Impacted Files Coverage Δ
tests/__init__.py 93.75% <ø> (ø) ⬆️
cadquery/occ_impl/shapes.py 89.6% <100%> (+0.13%) ⬆️
tests/test_cadquery.py 99.01% <100%> (+0.02%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update e69b2f8...42c35b7. Read the comment docs.

@jmwright
Copy link
Member

@bragostin @adam-urbanczyk What would you guys think about printing a warning when the status is DisconnectedWire? Is it practical to do that?

If some of them are not connected the Status give DisconnectedWire but the "Maker" is Done()

Users often have trouble when they're using a set of points and a joint isn't connected or the wire isn't closed. It would be nice to have some indication that they need to look at their points again unless they meant for things to be disconnected.

@jmwright
Copy link
Member

I'm not saying it needs to happen in this PR, but looking ahead, implementing warnings like that would be nice for users.

1 similar comment
@jmwright
Copy link
Member

I'm not saying it needs to happen in this PR, but looking ahead, implementing warnings like that would be nice for users.

@bragostin
Copy link
Contributor Author

@jmwright @adam-urbanczyk would a simple print('BRepBuilderAPI_MakeWire() Status = ', wire_builder.IsDone(), wire_builder.Error()) be enough?
As I understand the documentation, if the wires are not connected it will not throw an exception but return a partial result.

@jmwright
Copy link
Member

@bragostin That sounds good to me. It's just something to keep the user from having to guess what's going on if things don't work as expected.

@adam-urbanczyk
Copy link
Member

@bragostin looks good but I'd propose to use warnings.warn i.s.o. print

@bragostin
Copy link
Contributor Author

@jmwright @adam-urbanczyk I am just discovering the module warnings.warn. Would something like

if not wire_builder.IsDone():
    w1 = 'BRepBuilderAPI_MakeWire::IsDone(): returns the construction status. BRepBuilderAPI_WireDone if the wire is built, or another value of the BRepBuilderAPI_WireError enumeration indicating why the construction failed = '+ str(wire_builder.IsDone())
    w2 = 'BRepBuilderAPI_MakeWire::Error(): returns true if this algorithm contains a valid wire. IsDone returns false if: there are no edges in the wire, or the last edge which you tried to add was not connectable = ' + str(wire_builder.Error())
    warnings.warn(w1)
    warnings.warn(w2)

be ok?

@jmwright
Copy link
Member

@bragostin I think that looks fine.

@bragostin
Copy link
Contributor Author

I am not familiar with using github yet and I am obviously doing something wrong here, any idea what it is?

@adam-urbanczyk
Copy link
Member

What do you mean @bragostin ?

@bragostin
Copy link
Contributor Author

Well, 2 checks were not successful:
FAILED: codecov/patch — 60% of diff hit (target 94.86%)
FAILED: codecov/project — 94.76% (-0.11%) compared to acf363d
PASSED: continuous-integration/appveyor/pr — AppVeyor build succeeded
PASSED: continuous-integration/travis-ci/pr — The Travis CI build passed

@adam-urbanczyk
Copy link
Member

Yes, indeed: codecov is complaining about test coverage decrease. If you feel like you could add a test that triggers the newly implemented warning.

@bragostin
Copy link
Contributor Author

@adam-urbanczyk I just did add a test that triggers the warning and the 4 checks are ok now.

@bragostin
Copy link
Contributor Author

I have improved the test TestAssembleEdgesWarnings.py so that it returns only a warning and no error.

@jmwright
Copy link
Member

@adam-urbanczyk Do you want me to go ahead and merge this?

@bragostin
Copy link
Contributor Author

Sorry I did a mess, I forgot to create a new branch for BRepOffsetAPI_MakeFilling, I put things back in order.

@jmwright
Copy link
Member

@bragostin The reason you're getting a conflict is because runtest.py was deleted recently as part of the upgrade to pytest. #236

@bragostin
Copy link
Contributor Author

@jmwright In the test_cadquery.py file I have added a test_assembleEdges function with 4 tests including consecutive and non consecutive edges. All checks have passed.

@jmwright
Copy link
Member

Thanks. Sorry you didn't get a heads-up about the test changes. Changes have been happening quickly and it's hard to keep track.

@adam-urbanczyk
Copy link
Member

@bragostin I think it looks good. Just take a look a the single comment I had.

@jmwright
Copy link
Member

@bragostin It looks like you addressed the comment from @adam-urbanczyk . Do you feel this PR is ready to merge? I looked it over again and I can't think of anything else that we're missing.

@bragostin
Copy link
Contributor Author

@jmwright I have been using this new assembleEdges function for 2 weeks now because it is a pre-requisite for the BRepOffsetAPI_MakeFilling implementation and I have not noticed any issue so far, and older models are still running correctly. So from my side it looks ok.

@jmwright
Copy link
Member

@bragostin Thanks for all your work on this. Looks like it's time to merge it.

When I get a chance I'll take a look at some of the other edge assembly related issues here in GitHub to see if this fixes them.

@jmwright jmwright merged commit 3cd466a into CadQuery:master Dec 25, 2019
@adam-urbanczyk
Copy link
Member

Thanks for the contribution @bragostin !

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