precise-properties function way faster than properties function
Created by: reiniervandijk
Quoting YADD for brep object:
"properties .... Returns the approximate area, volume, and barycenter (center of mass) for the brep. These are computed with tessellation techniques, which may be less precise than the analytic techniques used in precise-properties, but should be faster to compute and exhibit more stability."
However, my experience tells that this is absolute not true for most breps (except perhaps a box-solid). Consider:
(define-object blend-sample (base-object)
:objects
((box :type 'box-solid
:length 10 :width 20 :height 15)
(blend :type 'blended-solid
:display-controls (list :color :blue)
:default-radius 3
:brep (the box))))
Then try:
> (make-self 'gdl-user::blend-sample)
#<gdl-user::blend-sample @ #x27b0741a>
> (time (the blend properties))
; While compiling #'(:internal (:anonymous-lambda 184) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 6.396041 sec user, 0.000000 sec system
; cpu time (gc) 0.000000 sec user, 0.000000 sec system
; cpu time (total) 6.396041 sec user, 0.000000 sec system
; real time 6.391000 sec (100.1%)
; space allocation:
; 1,317 cons cells, 15,576 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
(:area 1058.0302322356551 :volume -2688.485700513146 :barycenter #(4.624379521278622e-8 -1.7689643795993214e-8 4.7812516743011945e-8))
> (time (the blend precise-properties))
; While compiling #'(:internal (:anonymous-lambda 185) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 0.280801 sec user, 0.000000 sec system
; cpu time (gc) 0.000000 sec user, 0.000000 sec system
; cpu time (total) 0.280801 sec user, 0.000000 sec system
; real time 0.273000 sec (102.9%)
; space allocation:
; 70 cons cells, 1,184 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 0), minor: 0 (gc: 0)
1058.0352607385712
2688.5042009812973
2688.5042009812973
(:area-static-moments #(-4.8989093613727164e-5 2.1550662467006987e-5 -3.6839482398947886e-5) :area-moments-of-inertia
#(45373.564825689886 15113.217009644091 28017.912378078006) :area-products-of-inertia
#(-5.661023038829527e-4 -1.8689825015688562e-4 3.1346315859082097e-4) :area-second-moment-about-coordinate-axii
#(43131.129387722096 73391.47720376788 60486.781835333975) :volume-static-moments #(-3.238828467146959e-4 -1.1071887268114139e-4 4.421746052652778e-5)
:volume-moments-of-inertia #(81217.79700024093 19928.14881472922 44950.66790316432) :volume-products-of-inertia
#(-0.002875729270495866 0.004025920538448073 0.0015461265159991131) :volume-second-moment-about-coordinate-axii
#(64878.81671789356 126168.46490340521 101145.94581497014))
Observe that precise-properties is around 25 times faster here than the properties function. The ratio might be even worse for other breps (but I hope this single example makes the point clear). There are occasions in which the ratio might be in the order of precise-properties being 1000's of times faster (returns almost instantaneous).
As the documentation is misleading and the behavior is really not as expected, I consider this a serious issue. Further investigation into why the kernel (or the interaction with it) results in such behavior, is desired. Moreover, from a performance standpoint 6.4s for such a straight-forward brep is quite worrying.
Imported comments:
By genworks on 2015-01-30 23:10:03 UTC
moving to internal tracking list.