Links

Discussion about the development of the Assembly workbench.
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Links

Postby DeepSOIC » Fri May 05, 2017 6:17 pm

Another problem.
getSubObjects is disastrously slow.
Example.
1. Load project:
instance-of-body.FCStd
(9.59 KiB) Downloaded 17 times
2. Run this:

Code: Select all

for i in range(100):
   f = App.ActiveDocument.Body.getSubObject("Face1")
It takes about 7 seconds on my laptop, on debug build.

For comparison, I tried:

Code: Select all

for i in range(100):
  f = App.ActiveDocument.Body.Shape.Face1

for i in range(100):
  f = App.ActiveDocument.Body.Shape.getElement("Face1")

for i in range(100):
  f = App.ActiveDocument.Body.Shape.Faces[0]

for i in range(100):
  f = App.ActiveDocument.Body.Shape.Faces[0].copy()

These run instantaneously, even if copy-pasted to console all at once.
realthunder
Posts: 1541
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Postby realthunder » Fri May 05, 2017 7:09 pm

DeepSOIC wrote:Another problem.
getSubObjects is disastrously slow.
I have not tested link on Body yet. But this slowness is most likely due to the fact that it uses TopoShape.transformGeometry function to support scale operation. I can optimize it to use simple placement cascade if no scale is required. I am surprised that OCC didn't check it.
Try Assembly3 (latest version 0.11) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Links

Postby DeepSOIC » Fri May 05, 2017 7:46 pm

realthunder wrote:But this slowness is most likely due to the fact that it uses TopoShape.transformGeometry function to support scale operation.
Oh yes it may be. At least, transformGeometry should be avoided as much as possible because of its nasty habit of thransforming everything into bsplines, planes and line segments included.
wmayer
Site Admin
Posts: 15747
Joined: Thu Feb 19, 2009 10:32 am

Re: Links

Postby wmayer » Fri May 05, 2017 8:00 pm

DeepSOIC wrote:
wmayer wrote:To me it looks like the famous z-fighting problem.
Yeah, looks like it. But I know that selected points should get elevated, to eliminate that very problem. Was that removed?
The elevation of the points is still there and was only done to simplify the picking of points vs. lines. However, since all points have a higher z value the z-fighting isn't solved.
wmayer
Site Admin
Posts: 15747
Joined: Thu Feb 19, 2009 10:32 am

Re: Links

Postby wmayer » Fri May 05, 2017 8:30 pm

DeepSOIC wrote:
realthunder wrote:But this slowness is most likely due to the fact that it uses TopoShape.transformGeometry function to support scale operation.
Oh yes it may be. At least, transformGeometry should be avoided as much as possible because of its nasty habit of thransforming everything into bsplines, planes and line segments included.
I wonder why there is a scaling implemented at all. It was always said by many experienced users that performing a scale operation in CAD is in general a bad thing and since FreeCAD is a parametric modeller you should adjust the parameters instead. See also:
https://forum.freecadweb.org/viewtopic. ... 341#p10245
https://forum.freecadweb.org/viewtopic.php?t=7271
https://forum.freecadweb.org/viewtopic.php?t=3342
https://forum.freecadweb.org/viewtopic. ... 1&start=20

The problem with tranformGeometry is that the underlying geometry is always converted to B-splines independent of the actual transformation, i.e. also for the identity matrix. Now with having only B-splines in a part object a can of worms is getting opened:
  • Boolean operations are not very robust with B-splines
  • Some functions expect canonical geometries and won't work with B-splines.
realthunder
Posts: 1541
Joined: Tue Jan 03, 2017 10:55 am

Re: Links

Postby realthunder » Fri May 05, 2017 8:39 pm

wmayer wrote:I wonder why there is a scaling implemented at all. It was always said by many experienced users that performing a scale operation in CAD is in general a bad thing and since FreeCAD is a parametric modeller you should adjust the parameters instead. See also:
https://forum.freecadweb.org/viewtopic. ... 341#p10245
https://forum.freecadweb.org/viewtopic.php?t=7271
https://forum.freecadweb.org/viewtopic.php?t=3342
https://forum.freecadweb.org/viewtopic. ... 1&start=20

The problem with tranformGeometry is that the underlying geometry is always converted to B-splines independent of the actual transformation, i.e. also for the identity matrix. Now with having only B-splines in a part object a can of worms is getting opened:
  • Boolean operations are not very robust with B-splines
  • Some functions expect canonical geometries and won't work with B-splines.
Oh, these look bad. The reason for adding scaling is because coin 3D scaling is a cheap operation. Well, I originally wanted VRML scaling in order to support KiCAD's legacy components. Adding that to FC VRML view provider is easy. Then I think why not add it to my link, then all linked object gets scale for free. But apparently model data scaling is not. So, any better way to handle this then?
Try Assembly3 (latest version 0.11) along with my custom build of FreeCAD at here.
And if you'd like to show your support, you can donate through patreon, liberapay, or paypal
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Links

Postby DeepSOIC » Fri May 05, 2017 8:54 pm

Uniform scaling works fairly well, see implementation of Draft Clone:

Code: Select all

                        if sx == sy == sz:
                            sh.transformShape(m)
                        else:
                            sh = sh.transformGeometry(m)
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Links

Postby DeepSOIC » Fri May 05, 2017 8:58 pm

I don't have a clear idea on why would one want to use scaling in instances. On the other hand, having mirroring built-in might be handy. But again, not necessary.

If you drop scaling, the whole thing becomes much more streamlined, as it becomes completely covered by placement API.
wmayer
Site Admin
Posts: 15747
Joined: Thu Feb 19, 2009 10:32 am

Re: Links

Postby wmayer » Sat May 06, 2017 12:34 pm

DeepSOIC wrote:Uniform scaling works fairly well, see implementation of Draft Clone:

Code: Select all

                        if sx == sy == sz:
                            sh.transformShape(m)
                        else:
                            sh = sh.transformGeometry(m)
Although it's true that there is also a less radical transform algorithm implemented in OCC which doesn't change the underlying it also has to be used with care. Just look at the following minimal example:

Code: Select all

mat=App.Matrix()
mat.scale(3,3,3)

cube=Part.makeBox(10,10,10)
cube.Face1.Tolerance # => 1e-07

cube.transformShape(mat)
cube.Face1.Tolerance # => 3e-07

cube=Part.makeBox(30,30,30)
cube.Face1.Tolerance # => 1e-07
As you can see the scaling also affects the tolerance of a shape and this can lead to serious problems because it could break the topology of the part while when changing the parameters instead the tolerances don't change at all. See also: http://opencascade.blogspot.de/2009/02/ ... de_09.html
User avatar
DeepSOIC
Posts: 7600
Joined: Fri Aug 29, 2014 12:45 am
Location: Saint-Petersburg, Russia

Re: Links

Postby DeepSOIC » Sat May 06, 2017 2:10 pm

wmayer wrote:As you can see the scaling also affects the tolerance of a shape and this can lead to serious problems because it could break the topology
Actually, it's exactly the opposite in this case, IMO.

The purpose of tolerances is to provide some margin against imprecise nature of floating-point numbers. And the precision of double is a constant fraction of the number's magnitude, about 2e-16.

If I make a cube 100km in size, the tolerance of double comes close to the precision::confusion. If I add a couple more orders of magnitude, the parametrically generated cube will break (assuming it keeps the fixed tolerance all the way up to this large a cube). Well maybe it won't break as-is, but it will break as soon as it gets rotated for example. Because endpoints of its edges will be mismatched beyond the tolerance.

In contrast, scaling the tolerances proportionally to the size of the cube will not cause topology breakage. That is, scaling behaves correctly and is less dangerous.

Now on to trying this in FreeCAD...