FreeCADView Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0001520 | PartDesign | Bug | public | 2014-04-26 20:32 | 2015-12-15 13:18 |
| Reporter | tempr | Assigned To | ickby | ||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Platform | PC | OS | Windows Ultimate | OS Version | SP 1 |
| Product Version | trunk | ||||
| Target Version | trunk | Fixed in Version | 0.16 | ||
| Summary | 0001520: Mapping a sketch to a face of a solid gives unexpected results | ||||
| Description | Mapping a sketch to a face of a solid changes its set orientation (work-plane) and rotates the user view | ||||
| Steps To Reproduce | 1. Open the attached file 4. Switch view to top view if it already isn't set that way 2. Edit the sketch Sketch002 to take note of its work-plane 3. Make the TestSolidPad object visible 4. Select the top face on the TestSolidPad object 5. Map the sketch Sketch002 to the selected face 6. Observe the change in the work-plane of Sketch002 and the change in the user view | ||||
| Tags | No tags attached. | ||||
| FreeCAD Information | |||||
|
|
|
|
|
I forgot to add my build info here it is: OS: Windows 7 Platform: 32-bit Version: 0.14.3389 Python version: 2.6.2 Qt version: 4.5.2 Coin version: 3.1.0 SoQt version: 1.4.1 OCC version: 6.5.1 It also happens on this unofficial build: OS: Windows 7 Platform: 32-bit Version: 0.14.3343 (Git) Branch: libpack Hash: 8dcb8f68cf17ef152d34d226d7699c98c5bb59fb Python version: 2.7.6 Qt version: 4.8.5 Coin version: 3.1.3 SoQt version: 1.5.0 OCC version: 6.7.0 |
|
|
SS are here (search for this text): "0001520 before:" http://forum.freecadweb.org/viewtopic.php?f=8&t=6400&start=20 |
|
|
I can confirm this bug in the version below. If you click on the top face of testsolidpad in the above file and then click new sketch it rotates the view...if you click on "topview" while in sketch edit mode it rotates the sketch 90 degrees, then if you click on poly line tool, the horizontal and vertical auto constraints display icon is rotated 90 degrees... OS: Ubuntu 14.04 LTS Platform: 64-bit Version: 0.14.3476 (Git) Branch: master Hash: 3ceb840f5dc1570a6b1d7cdb2295f7f1becf33b6 Python version: 2.7.6 Qt version: 4.8.6 Coin version: 4.0.0a SoQt version: 1.6.0a OCC version: 6.7.0 Plainly a bug in trunk and important but can be worked around so I think the urgency is overstated. Urgent and major.....? |
|
|
Well, as i have already commented on the 0001519 bug entry: "IMO, that option should be taken away from the reporters. :) To be honest, in most cases I didn't know what to put there. Since this was a bug in a part of the program that was supposed to be precise with no margin for error (constraints), I have marked it as major. And I agree, it isn't a show stopper." (this was regarding the 0001519 bug) (and below about the 0001520) "About the other bug (0001520) i still believe it is a highest-priority issue (it doesn't crash but...) as I have noticed while doing a revisit - it changes the work-plane of the mapped sketch completely (to something non-existant, invalid). It also happens if you try to create a new sketch on the selected face. I would mark this one as a show stopper." I also noticed the things with constraints not working "properly" on my revisit but I believe that all further problems arise from creating that invalid YX plane when the map to sketch command is used. Fix that and everything else should be working as it should. Pay attention to the coordinates icon in the bottom part of the screen and it should all be clear. (It can be seen in the SS I have supplied) Workaround is just awkward. It stopped me from working further on that aspect of my model. I would have to accept that invalid YX work plane as something valid and adjust to that, and "make" it work. Also I didn't proceed to test this but who knows if all things would work as expected? I noticed that I couldn't change the position, angle or any other value using the data tab on the mapped sketch and the values there were very weird: -0.00 x position, -0.00 y axis. I also noticed these error messages in the report window after trying to set horizontal/vertical constraints on the mapped sketch: "Updating geometry: Error build geometry(0): Both points are equal Invalid solution from DogLeg solver. Updating geometry: Error build geometry(0): Both points are equal Invalid solution from LevenbergMarquardt solver." |
|
|
> 6. Observe the change in the work-plane of Sketch002 and the change in the user view To be honest I do not even consider this as a bug. 1. When you map an existing sketch to a face then from now on the sketch looses its old placement and accepts that of the support face with respect to it its local coordinate system. 2. It's true that the perspective in the view changes. But did you also notice that it shows the sketch exactly the same way as before? IMO, it would be more annoying if the perspective stays but the sketch flips because for more complex sketches you first have to check how it changed and move it back manually. |
|
|
|
|
|
There is something weird happening here for sure. I have also noticed similar glitches while playing with my test project. I think there is some error in the coordinate system code (or it should be reworked to make it more user-friendly). Regarding your comments: "To be honest I do not even consider this as a bug." It still seems like a rather large bug or flaw in the code to me since the user could want to copy/paste some sketch and apply it as a mapped sketch somewhere else within the same or some other project, for example. 1. I understand that this is the way it should work. But it doesn't work as it should (IMO). 2. Yea the sketch remains the same but the coordinate system gets shuffled, not just the "view perspective" (check the coordinate sytem icon before and after - X becomes Y and vice versa). And I can't get it back to the correct orientation so it is very annoying, I would have to remake every sketch from scratch when using that feature (ignoring the weird workplanes that contradict the global work plane doing so). Every time I try to manipulate the sketch (as a workaround) so it corresponds to its original position in relation to the global workplane (not to restore the original workplane as that seems impossible), the changes I make get reversed as soon as I exit the edit mode or click on something else. I have attached a reworked version (Test44.FCStd) of the original file where I experimented more with this issue. Every sketch is made on one of the available workplanes (XY XZ YZ) and they are then extruded (pad) to make the three TestSolidPad objects with the same dimensions. Sketch002 is made on the XY plane as in the original file, but it is reworked so the errors are more easily spotted. Try map to sketch on the three TestSolidPad objects and observe the results. Proper results only when the workplanes of the mapped sketch and the sketch used to make the object match (TestSolidPad2). IMO, the problem is in the placement of the sketch plane. It gets manipulated so it "fits" the selected face but the algorithm doesn't pay attention to the sketch orientation in relation to the global coordinate system. How to fix this: implement a check for matching coordinates (X, Y or Z) when mapping a sketch and adjust/rotate the mapped sketch in relation to that using the global coordinate system as a reference (X remains X, etc.). Object / Sketch being mapped / Match ------------------------------------- XY / XY / XY XZ / XY / X YZ / XY / Y XY / XZ / X XZ / XZ / XZ YZ / XZ / Z XY / YZ / Y XZ / YZ / Z YZ / YZ / YZ P.S. I suspect I found another related bug while experimenting with sketch mapping, I will report it when time permits. |
|
|
I think freecad does this the correct way. A mapped sketch inherits the coordinate system of the face it is mapped to. I understand this is not ideal for the kind of workflow you want to use (copy and map sketch at multiple places). But note that your proposed method does not work in all occasions:wha if the sketch gets mapped to an arbitrary sketch plane with normal (1,1,1)? Also what happens if you rotate the underlying feature, would the sketch be reorientated? The resulting code would be highly confusing for users as everytime something different happens. Another very important issue is, that this would break the normal part design workflow. If you draw on a face you want to draw relative to that face. Now if the sketch would not inherit the face's coordinate system and you change/transform the underlying feature, the second sketch would move in relation to the mapped face. Now that would be extremly confusing and very annoying. You need to stay the x and y axis relative to the face. A sketchs location must be fully defined on the mapped face, there is no way around it. And inheriting the local coordinate system is the only way to make this work for every possible change. About the rotating view: I think it is important that the sketch y axis points upwards (and x to the right) when you go into edit mode. That is how a normal coordinate system looks like, that is what I suspect happens when editing the sketch. Remember that this feature is for working in local coordniates, therefore it is unimportant where you are looking at in globals. Your workflow is currently not well supported by part design, you should use part tools if neccesary or wait for the updated part design implementation with working planes, as those can be made fixed to global axes and not only to the part. |
|
|
This is intended behaviour and won't be changed |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2014-04-26 20:32 | tempr | New Issue | |
| 2014-04-26 20:32 | tempr | File Added: test4.FCStd | |
| 2014-04-26 20:34 | tempr | Note Added: 0004579 | |
| 2014-04-26 21:40 | tempr | Note Added: 0004582 | |
| 2014-04-27 15:18 | jmaustpc | Note Added: 0004586 | |
| 2014-04-27 15:18 | jmaustpc | Priority | urgent => normal |
| 2014-04-27 15:19 | jmaustpc | Product Version | 0.13 => trunk |
| 2014-04-27 15:19 | jmaustpc | Target Version | => trunk |
| 2014-04-27 16:47 | tempr | Note Added: 0004588 | |
| 2014-04-27 16:48 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:48 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:49 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:49 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:50 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:55 | tempr | Note Edited: 0004588 | |
| 2014-04-27 16:59 | tempr | Note Edited: 0004588 | |
| 2014-04-27 17:05 | tempr | Note Edited: 0004588 | |
| 2014-04-27 17:05 | tempr | Note Edited: 0004588 | |
| 2014-05-20 17:26 | wmayer | Note Added: 0004707 | |
| 2014-05-22 04:45 | tempr | File Added: test44.FCStd | |
| 2014-05-22 05:26 | tempr | Note Added: 0004722 | |
| 2014-05-22 05:27 | tempr | Note Edited: 0004722 | |
| 2014-05-22 05:27 | tempr | Note Edited: 0004722 | |
| 2014-05-22 05:28 | tempr | Note Edited: 0004722 | |
| 2014-05-22 05:29 | tempr | Note Edited: 0004722 | |
| 2014-05-22 05:31 | tempr | Note Edited: 0004722 | |
| 2014-05-22 05:33 | tempr | Note Edited: 0004722 | |
| 2014-05-22 14:30 | ickby | Note Added: 0004724 | |
| 2014-05-22 14:37 | ickby | Note Edited: 0004724 | |
| 2014-05-22 14:41 | ickby | Note Edited: 0004724 | |
| 2014-05-22 14:49 | ickby | Note Edited: 0004724 | |
| 2015-05-19 05:45 | ickby | Note Added: 0006147 | |
| 2015-05-19 05:45 | ickby | Status | new => closed |
| 2015-05-19 05:45 | ickby | Assigned To | => ickby |
| 2015-05-19 05:45 | ickby | Resolution | open => no change required |
| 2015-12-15 13:18 | yorik | Fixed in Version | => 0.16 |
