In one case the step is imported as nested blocks in another it isn’t.
What is the logic behind this?
UPDATE:
I noticed I have bad objects. What could be the reason an imported via STEP curve to become invalid?
Generally (poly)curves become invalid because they have segments shorter than the file tolerance. Explode/Join usually fixes them. Perhaps you can post one of the bad curves before fixing it…
1 Like
Here’s one
invalid_curve_from_step.3dm (57.5 KB)
Yep, Check tells you that right off…
Actually, this looks like it’s not a short segment, but rather that the start/end points do not correspond to within Rhino’s 0 tolerance - I guess that’s why exploding/joining fixes it, as then Rhino moves the points to correspond…
What does that mean? I don’t understand.
This seems an issue with the STEP importer. Isn’t it importer’s job to fix these?
I think the assumption is that in general the importer’s job is first and foremost to bring in the file’s data EXACTLY. If that data doesn’t suit Rhino’s needs or way of doing things then it is the Rhino modeler’s job to make it right. This could be done by requesting the original data supplier to fix it or by fixing it within Rhino.
Certainly it would be a great workflow within Rhino for the importer to have a “repair” checkbox which the user could invoke on a second import attempt after undoing the first.
Hi Ivelin.
The most likely answer to your first question is that one STEP file has its content represented as nested blocks and the other doesn’t. Without the files I can only guess.
For the second question, concerning a bad curve, the reason is simple. The data in a STEP file is often really bad, and does not always meet the STEP specifications. When imperfect data is read, we do our best to interpret what it was supposed to represent. Our importer has been evolving for over 20 years. Improvements happen when someone sends in a file that does not read in as expected. Your particular problem has not been submitted in the past so there was no attempt to fix it. The fix is probably very simple, and without seeing the file I can put in code to avoid creating a bad object, but it would be much better if you would submit your STEP file so I can see exactly what is going wrong. You can send it directly to me, chuck@mcneel.com.
1 Like
@ivelin.peychev I received the files. Thanks. One file has all of the curves collected in a single GEOMETRIC_SET entity. The other has an assembly hierarchy, which gets imported as nested blocks. I’ll figure out the bad curve objects by the end of the day. Thanks again for the files.
1 Like
Thanks for the effort @chuck
I put a fix for the bad curves into V6, but not the next service release. The next release of the V7 WIP should have it.
There are TRIMMED_CURVE entities as segments of COMPOSITE_CURVE entities in the file. I’ve never seen this combination before. These are curves together with 3D points that tell you which part of the curve to use. Adjacent curve segments will have identical trimming points where they come together, but that point may not be exactly on either curve. There is also numerical noise in the closest point calculation used to find the parameters for trimming. The fix was just to force the ends of the segments to match.
Thanks for the report.
1 Like
Thanks @chuck,
These are curves coming from a Catia v6 sketch and exported as step.
I have noticed in catia they use polycurves with b-spline segments could that be the issue? If I need to also report the issue to dassault support?
@ivelin.peychev I don’t think there’s anything wrong with the STEP file. It was just a combination that I hadn’t come across before, so there was no way to test my code with real world examples. It should be fine now. Please let me know if you find any other issues with STEP import.
Chuck
RH-57811 is fixed in the latest Service Release Candidate