gendl issueshttps://gitlab.common-lisp.net/groups/gendl/-/issues2015-03-31T02:17:10Zhttps://gitlab.common-lisp.net/gendl/gendl/-/issues/106negative volume for breps2015-03-31T02:17:10ZDave Coopernegative volume for breps*Created by: reiniervandijk*
All breps have negative volumes when computed with properties funtions. Replicate:
```lisp
> (make-self 'surf:box-solid :width 1 :length 2 :height 3)
#<box-solid @ #x28c4c3a2>
> (the properties)
(:are...*Created by: reiniervandijk*
All breps have negative volumes when computed with properties funtions. Replicate:
```lisp
> (make-self 'surf:box-solid :width 1 :length 2 :height 3)
#<box-solid @ #x28c4c3a2>
> (the properties)
(:area 22.0 :volume -6.0 :barycenter #(0.0 0.0 0.0))
```
**Imported comments:**
*By genworks on 2015-01-30 23:13:41 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/105precise-properties on brep should return plist2015-03-31T02:17:09ZDave Cooperprecise-properties on brep should return plist*Created by: reiniervandijk*
It seems counter-intuitive that the precise-properties function on a brep object returns multiple values, of which the primary return value is a single number. It would be better to return a plist (as primar...*Created by: reiniervandijk*
It seems counter-intuitive that the precise-properties function on a brep object returns multiple values, of which the primary return value is a single number. It would be better to return a plist (as primary return value), to enable the capture of all relevant properties at once, just like the properties function returns a plist. Now, a user (interested in multiple properties at the same time) would have to write multiple-value-bind or multiple-value-list statements to cache all properties for further reference. This would result in more boilerplate code and it would therefore be easier to skip this step at all. Moreover, what's in a name .... (that is, "properties").
**Imported comments:**
*By genworks on 2013-02-01 04:14:14 UTC*
To maintain backward compatibility, added a new slot `precise-properties-plist` which returns a plist. https://gitlab.common-lisp.net/gendl/gendl/-/issues/104precise-properties function way faster than properties function2015-03-31T02:17:09ZDave Cooperprecise-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 precis...*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:
```lisp
(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:
```lisp
> (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. https://gitlab.common-lisp.net/gendl/gendl/-/issues/103make-manifold? operation only on final boolean-merge please.2015-03-31T02:17:08ZDave Coopermake-manifold? operation only on final boolean-merge please.*Created by: reiniervandijk*
Consider a user creating a merged-solid from multiple breps (more than 2) and set:make-manifold? t. While doing so, he will get bummer! warnings about the make-manifold operation failing on all but the last ...*Created by: reiniervandijk*
Consider a user creating a merged-solid from multiple breps (more than 2) and set:make-manifold? t. While doing so, he will get bummer! warnings about the make-manifold operation failing on all but the last boolean merge (assuming the input breps proper of course). Logically, trying manifold operations on intermediate results makes little sense, since they will most likely have a non-manifold topology.
Two things:
1. Only perform make-manifold operation on last boolean merge
2. Consider the performance impact. Might you not slow down the whole process by asking the kernel to try this (unnecessary) operation every time?
Replicate:
```lisp
(define-object manifold-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(merged :type 'merged-solid :other-brep (the box :face-breps :list-elements))
(merged2 :type 'merged-solid :other-brep (the box :face-breps :list-elements) :make-manifold? t)))
````
And then:
```lisp
> (make-self 'manifold-sample)
#<manifold-sample @ #x281d9fb2>
> (the merged :bounding-box)
Merging ((:face-breps 1) :box) into merge object
Merging ((:face-breps 2) :box) into merge object
Merging ((:face-breps 3) :box) into merge object
Merging ((:face-breps 4) :box) into merge object
Merging ((:face-breps 5) :box) into merge object
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
> (the merged2 :bounding-box)
Merging ((:face-breps 1) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 2) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 3) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 4) :box) into merge object
Warning: Bummer! the make-manifold operation failed with code 1001
Merging ((:face-breps 5) :box) into merge object
Manifold Success!
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
```
**Imported comments:**
*By genworks on 2013-02-01 04:10:02 UTC*
This is fixed in current github in surf/source/boolean.lisp. (By the way, yes we will be adding an (update-gdl) option to pull from github, but for now you have to manually pull and load from github if you want early previews).
```common-lisp
gdl-user> (make-self 'manifold-sample)
#<manifold-sample @ #x368853d2>
gdl-user> (the merged2 bounding-box)
Merging ((:face-breps 1) :box) into merge object
Merging ((:face-breps 2) :box) into merge object
Merging ((:face-breps 3) :box) into merge object
Merging ((:face-breps 4) :box) into merge object
Merging ((:face-breps 5)
:box) into merge object, trying to make manifold...
Manifold Success!
(#(-1.0 -1.0 -1.0) #(1.0 1.0 1.0))
gdl-user>
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/102Why does my solid have 0.0 volume?2015-03-31T02:17:08ZDave CooperWhy does my solid have 0.0 volume?*Created by: reiniervandijk*
Okay, finally got my head around this after experiencing this problem multiple times. For a lot of boolean-operations (merging, uniting, etc.) where open faces are the input, the resulting brep will not be a...*Created by: reiniervandijk*
Okay, finally got my head around this after experiencing this problem multiple times. For a lot of boolean-operations (merging, uniting, etc.) where open faces are the input, the resulting brep will not be a true solid and have a volume of 0.0. The only way to get around this is to make another explicit 'manifold-solid with that former brep as input, since there are no :make-manifold? messages to set (with the exception of merged-solid). Only then will the new brep be a true solid (with 2 regions) with a real volume. I don't think the whole manifold story is well explained in the documentation, actually not at all. This is a serious issue right now.
Replicate:
```lisp
(define-object volume-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(merged :type 'merged-solid :other-brep (the box :face-breps :list-elements))
(united :type 'united-solid :other-brep (the box :face-breps :list-elements))
(merged-manifold :type 'manifold-solid :brep (the merged))
(united-manifold :type 'manifold-solid :brep (the united))
)
)
```
Then try:
```lisp
> (make-self 'volume-sample)
#<volume-sample @ #x27e80aea>
> (the merged :volume)
0.0
> (the united :volume)
warn? = t ;; <-- for what?
0.0
> (the merged-manifold :volume)
Manifold Success!
8.0
> (the united-manifold :volume)
Manifold Success!
8.0
```
I guess you see the pattern. This should definitely become clearer from documentation or warnings, because now user is just disappointed. Strange enough, the properties function does return values:
```lisp
> (the merged :properties)
(:area 24.0 :volume -7.999999999999999 :barycenter #(0.0 0.0 0.0))
> (the united :properties)
(:area 24.0 :volume -7.999999999999999 :barycenter #(0.0 0.0 0.0))
```
**Imported comments:**
*By genworks on 2015-01-30 23:08:06 UTC*
moving to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/101Why is my stitched-solid not working?2015-03-31T02:17:07ZDave CooperWhy is my stitched-solid not working?*Created by: reiniervandijk*
Includes a very strange behavior. Replicate with:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces :type 'su...*Created by: reiniervandijk*
Includes a very strange behavior. Replicate with:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces :type 'surface
:sequence (:size 6)
:built-from (the box (faces (the-child index)) :basis-surface))
(stitched :type 'stitched-solid :faces-in (list-elements (the clean-surfaces)))
(stitched-alternative :type 'stitched-solid :faces-in (list-elements (the box :faces) (the-element :basis-surface)))
(stitched-manifold :type 'manifold-solid :brep (the stitched))
)
)
```
Then try:
```lisp
move> (make-self 'stitching-sample)
#<stitching-sample @ #x2805a98a>
move> (the stitched regions :number-of-elements)
1
move> (the stitched-manifold regions :number-of-elements)
Warning: Bummer! the make-manifold operation failed with code 1001
1
```
Conclusion: one can not make a simple manifold solid with the ideal surfaces of a box!?!?
Then something more striking:
to follow soon, have to go
**Imported comments:**
*By genworks on 2013-02-01 02:21:46 UTC*
This is fixed in development and fix will be in next release. To preview the fix, please try:
```common-lisp
(in-package :smlib)
(defmethod make-stitched-solid-brep ((geometry-kernel geometry-kernel) &key surfaces proper-faces)
(declare (ignore proper-faces)) ;; flag -- use copy-faces to get the faces into the new brep.
(let ((brep (make-brep geometry-kernel)))
(dolist (surface surfaces) (create-face-from-surface brep surface))
(iwbrep-sew-and-orient brep)
(iwbrep-shrink-geometry brep)
brep))
```
Note: this example is internal lower-level stuff; nothing from above is supported for use in user code!
https://gitlab.common-lisp.net/gendl/gendl/-/issues/100Performance bogs down with huge sequences2015-03-31T02:17:07ZDave CooperPerformance bogs down with huge sequences*Created by: genworks*
Huge sequence will bog performance because of list operations during dependency tracking.
```common-lisp
(in-package :gdl-user)
;;
;; Submitted by Hermen de Jong of KE-works
;;
(define-object huge-box...*Created by: genworks*
Huge sequence will bog performance because of list operations during dependency tracking.
```common-lisp
(in-package :gdl-user)
;;
;; Submitted by Hermen de Jong of KE-works
;;
(define-object huge-boxes-sequence (base-object)
:input-slots
((number-of-boxes 100 :settable))
:computed-slots
((wall-width (floor (sqrt (the number-of-boxes)))))
:objects
((boxes :type 'box
:sequence (:size (the number-of-boxes))
:height 10
:width 20
:length 30
:display-controls (list :color :red :transparency .5)
:center (translate (make-point 0 0 0)
:right (* (rem (the-child index)
(the wall-width))
(the-child width))
:top (* (floor (the-child index)
(the wall-width))
(the-child height))))))
```
```common-lisp
gdl-user> (make-self 'huge-boxes-sequence)
#<huge-boxes-sequence @ #x25ab80da>
gdl-user> (the (set-slot! :number-of-boxes 20000))
nil
gdl-user> (time (progn (mapsend (the boxes) :center) nil))
; While compiling #'(:internal (:anonymous-lambda 51) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 11.716732 sec user, 0.000000 sec system
; cpu time (gc) 0.676043 sec user, 0.000000 sec system
; cpu time (total) 12.392775 sec user, 0.000000 sec system
; real time 11.031462 sec (112.3%)
; space allocation:
; 1,680,343 cons cells, 27,958,896 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 2585), minor: 4786 (gc: 2585)
nil
gdl-user>
```
**Imported comments:**
*By genworks on 2013-02-01 03:14:08 UTC*
Fixed with more efficient data structure in place of large dependency tracking lists:
```common-lisp
gdl-user> (make-self 'huge-boxes-sequence)
#<huge-boxes-sequence @ #x2527a892>
gdl-user> (the (set-slot! :number-of-boxes 20000))
nil
gdl-user> (time (progn (mapsend (the boxes) :center) nil))
; While compiling #'(:internal (:anonymous-lambda 52) 0) at top level:
Warning: Free reference to undeclared variable self assumed special.
; cpu time (non-gc) 1.288081 sec user, 0.000000 sec system
; cpu time (gc) 0.744046 sec user, 0.000000 sec system
; cpu time (total) 2.032127 sec user, 0.000000 sec system
; real time 1.843707 sec (110.2%)
; space allocation:
; 1,604,168 cons cells, 35,065,232 other bytes, 0 static bytes
; Page Faults: major: 0 (gc: 599), minor: 1041 (gc: 599)
nil
gdl-user>
```https://gitlab.common-lisp.net/gendl/gendl/-/issues/99Sequence elements not garbage-collected when number-of-elements is modified2015-03-31T02:17:06ZDave CooperSequence elements not garbage-collected when number-of-elements is modified*Created by: genworks*
(Please see code example from Issue #68)
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 1613 :new-free-oth...*Created by: genworks*
(Please see code example from Issue #68)
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 1613 :new-free-other 29936272
:new-used-other 119776 :old-free-cons 736 :old-used-cons 1029473
:old-free-other 33451536 :old-used-other 32475008)
```
```common-lisp
gdl-user> (dotimes (n 20) (the (set-slot! :number-of-boxes 20000))
(mapsend (the boxes) :center)
(the (set-slot! :number-of-boxes 10000))
(mapsend (the boxes) :center))
```
```common-lisp
gdl-user> (pprint (glisp:room-report))
(:new-free-cons 1019 :new-used-cons 6505370 :new-free-other 107370384
:new-used-other 72025632 :old-free-cons 514 :old-used-cons 19165857
:old-free-other 1371136 :old-used-other 211685968)
```
**Imported comments:**
*By genworks on 2013-02-01 04:04:41 UTC*
Fixed by enhancing dependency-tracking to track elements of sequences with respect to the sequence's number-of-elements.
```common-lisp
(make-self 'huge-boxes-sequence)
```
```common-lisp
gdl-user> (glisp:room-report)
(:new-free-cons 1019 :new-used-cons 1565 :new-free-other 231540304
:new-used-other 145248 :old-free-cons 483 :old-used-cons 1030745
:old-free-other 326332808 :old-used-other 32518200)
```
```common-lisp
gdl-user> (dotimes (n 20) (the (set-slot! :number-of-boxes 20000))
(mapsend (the boxes) :center)
(the (set-slot! :number-of-boxes 10000))
(mapsend (the boxes) :center))
```
```common-lisp
gdl-user> (glisp:room-report)
(:new-free-cons 1019 :new-used-cons 450260 :new-free-other 222520136
:new-used-other 5552744 :old-free-cons 236 :old-used-cons 1032011
:old-free-other 326276256 :old-used-other 32566560)
```
*By genworks on 2013-08-13 14:36:20 UTC*
This issue is being re-opened because the "fix" can cause a subtle issue in rare circumstances. A child object can become spuriously "orphaned" after doing a set-slot! --- that is, it will become unbound, and a new object will be instantiated on-demand, losing any bashing which happened in the child. The "fix" will be reverted in devo branch which will be merged into master branch for next release. https://gitlab.common-lisp.net/gendl/gendl/-/issues/98fitted-curve 2 points and 2 end-vectors gives wrong result2015-03-31T02:17:06ZDave Cooperfitted-curve 2 points and 2 end-vectors gives wrong result*Created by: reiniervandijk*
If user makes fitted-curve with 2 points as input and 2 vectors controlling directions at start and end, object falsely assumes a linear curve. Instead, a curve of degree 3 can be fitted that gives perfect r...*Created by: reiniervandijk*
If user makes fitted-curve with 2 points as input and 2 vectors controlling directions at start and end, object falsely assumes a linear curve. Instead, a curve of degree 3 can be fitted that gives perfect results. In the legacy ICAD platform I remember using this a lot.
Issue is in native-curve slot, this is the solution:
```lisp
(native-curve
(progn
(when (and (the vectors)
(member (the vector-type) (list :tangents :normals))
(not (= (length (the points)) (length (the vectors)))))
(error "For fitted-curve ~s, points and vectors must be lists of the same length.~%"
(cons 'the (reverse (the root-path)))))
;; RvD: new condition
(cond ((and (= (length (the points)) 2)
(the vectors))
(interpolate-curve
*geometry-kernel* (the effective-points) 3 (the parameterization) :vectors (the effective-vectors)
:vector-type (the vector-type) :interpolant? (the interpolant?)
:knot-multiplicity (the knot-multiplicity)
:tolerance (the tolerance)))
((> (length (the points)) 2)
(let ((degree-ok? (<= (the degree) (1- (length (the points))))))
(unless degree-ok?
(error "The degree of a fitted-curve must be less than or equal to the number of control points."))
(interpolate-curve
*geometry-kernel* (the effective-points) (the degree) (the parameterization) :vectors (the effective-vectors)
:vector-type (the vector-type) :interpolant? (the interpolant?)
:knot-multiplicity (the knot-multiplicity)
:tolerance (the tolerance))))
(t (the linear-curve native-curve)))))
```
Try now the following test object and see the result:
```lisp
(define-object fitted-curve-test (base-object)
:computed-slots
((points '(#(0.0 0.0 0.0)
#(1.0 0.0 0.0)))
)
:objects
((straight :type 'fitted-curve
:pass-down (points))
(works :type 'fitted-curve
:pass-down (points)
:vector-type :tangents
;;:degree 1
:vectors '(#(0.0 1.0 0.0)
#(0.0 -1.0 0.0)))
(works2 :type 'fitted-curve
:pass-down (points)
:degree 3
:vector-type :tangents
:vectors '(#(0.0 1.0 0.0)
#(0.0 -1.0 0.0)))))
```
**Imported comments:**
*By genworks on 2013-02-07 06:38:10 UTC*
There are actually several issues similar to this, where curve operations degenerate for curves with only two control points and/or degree of 1. Typically the problems show up with simple linear curves. For example the minimum-distance-to-curve function of curve will fail if one or both of the arguments is a curve with only two control points.
The workaround (as you refer to above) is to make an equivalent degree-3 curve with the missing control-points explicitly added. For linear-curves it is enough to make a b-spline-curve with the start and end control-points repeated, i.e. (start start end end).
We will leave this issue open until we have a general solution which makes the issue transparent.
*By reiniervandijk on 2013-02-07 10:16:19 UTC*
I understand. Beware though that I was not touching upon this general issue, but upon the current fitted-curve implementation that falsely makes a linear-curve object if there are 2 points given. It's about this part:
```lisp
(if (not (> (length (the points)) 2)) (the linear-curve native-curve)))))
```
I hope I made clear that there exists a perfectly possible input from the user where he/she gives only two points plus two tangency conditions. I personally wanted to use this feature to blend some curves between other curves, satisfying continuity. Hence, my message does not provide a work-around, but provides a solution to an issue in the fitted-curve object.
*By genworks on 2015-01-30 23:04:39 UTC*
moving to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/97transformed-solid rotation point of reference defaulted to #(0.0 0.0 0.0)?2015-03-31T02:17:05ZDave Coopertransformed-solid rotation point of reference defaulted to #(0.0 0.0 0.0)?*Created by: reiniervandijk*
Is transformed-solid working normally? I can translate geometry as expected, but rotation gives strange results, although I’m quite sure that I’m giving all the right inputs. Seems like the rotation point of...*Created by: reiniervandijk*
Is transformed-solid working normally? I can translate geometry as expected, but rotation gives strange results, although I’m quite sure that I’m giving all the right inputs. Seems like the rotation point of reference defaults to #(0.0 0.0 0.0), maybe you need to pass that input to smlib as well? Otherwise, work-around is to translate things back afterwards. To illustrate the principle, see attachment and look at both rotated boxes and compare. Clearly, the "box-rotated" object is not rotated around the center of the provide brep.
```lisp
(define-object transformed-solid-tests (base-object)
:objects
((box-at-origin :type 'box-solid :width 3 :length 4 :height 5)
(box-at-origin-translated :type 'transformed-solid
:brep (the box-at-origin)
;;:from-location (the box-at-origin :center)
:to-location (translate (the box-at-origin :center) :right 10))
(box-at-origin-rotated :type 'transformed-solid
:brep (the box-at-origin)
:to-orientation (alignment :rear (the (face-normal-vector :rear))
:top (rotate-vector-d (the (face-normal-vector :top))
10
(the (face-normal-vector :rear)))))
(box :type 'box-solid :width 3 :length 4 :height 5 :center (make-point 2 2 2))
(box-translated :type 'transformed-solid
:brep (the box)
;;:from-location (the box :center)
;;:from-location (the box-at-origin :center)
:to-location (translate (the box :center) :right 10))
(box-rotated :type 'transformed-solid
:brep (the box)
;;:from-location (the box :center)
:from-location (the box :center)
:to-orientation (alignment :rear (the (face-normal-vector :rear))
:top (rotate-vector-d (the (face-normal-vector :top))
10
(the (face-normal-vector :rear)))))
```
**Imported comments:**
*By reiniervandijk on 2013-08-09 08:15:14 UTC*
Any news on this issue? It is pretty clear at this stage that transformed-solid rotates around #(0.0 0.0 0.0) no matter what user provides as input center. In the meantime, I use a work-around:
```lisp
(define-object rotated-solid (brep)
:input-slots
((rotation-point (the brep :center))
(to-orientation (the brep :orientation))
brep-in)
:computed-slots
((built-from (the brep3)))
:hidden-objects
((brep1 :type 'transformed-solid
:brep (the brep-in)
:from-location (the rotation-point)
:to-location (make-point 0 0 0))
(brep2 :type 'transformed-solid
:brep (the brep1)
:to-orientation (the to-orientation))
(brep3 :type 'transformed-solid
:brep (the brep2)
:from-location (make-point 0 0 0)
:to-location (the rotation-point))
)
)
```
*By genworks on 2013-08-11 01:47:14 UTC*
This is currently an unfortunate limitation of transformed-solid -- indeed the orientation is always taken relative to the global origin (geom-base:+nominal-origin+).
Your workaround (moving the object to origin, applying transform, then moving it back) is reasonable, although it creates three times as many breps as should be necessary for this operation (but necessary in practice currently because of this limitation of GDL's transformed-solid primitive).
Our intention is to establish a boxed-brep primitive (to supersede transformed-solid) which will work analogously to boxed-surface and boxed-curve, with the orientation-center input, and which does not create superfluous breps in the process. Internally, this will require integration with additional smlib operations. This Issue remains open until the boxed-brep primitive is complete.
*By genworks on 2015-01-30 22:59:41 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/96trimmed-surface edges no uv-curve?2015-03-31T02:17:05ZDave Coopertrimmed-surface edges no uv-curve?*Created by: reiniervandijk*
A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
**Imported comments:**
*By genworks on 201...*Created by: reiniervandijk*
A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
**Imported comments:**
*By genworks on 2013-02-08 18:07:41 UTC*
Try the face of the brep of the trimmed-surface. I'm not totally sure about this, not at computer at the moment, will look at it as soon as possible.
On Feb 8, 2013, at 11:01 AM, reiniervandijk <notifications@github.com> wrote:
> A trimmed-surface has edges, however they miss a uv-curve representation. Weird, because the on-surface argument should obviously be the basis-surface provided.
>
> —
> Reply to this email directly or view it on GitHub..
>
*By reiniervandijk on 2013-02-08 18:21:00 UTC*
nope, also hasn't. Replicate with surf::test-trimmed-surface-3.
*By genworks on 2013-02-18 19:55:00 UTC*
Edges of a brep (or of a brep face) do have a uv-curve message. Note that that is a function (not a slot) and (as documented) you have to pass in the surface relative to which you want the uv-curve. This is because an edge can be shared by two faces (in a manifold solid) or more than two faces (in a non-manifold brep), so it is ambiguous simply to ask for the uv-curve for an edge.
With that said, we should be able to enhance the uv-curve message for edges of _face_ (as opposed to _brep_), because for each face, the basis-surface is not ambiguous. This Issue will remain open until this enhancement is complete.
*By AliAbedian on 2013-03-14 15:11:25 UTC*
I am trying to work with this uv-curve message, but I have some problems in visualizing the curve.
I am getting a curve as a result of calling that function but when I try to visualize it on tasty, I get such an error:
In # "trimmed-curve" (built-from #), u2 is not greater than u1. Cannot Trim. !!
Note that I am testing on a simple box-solid as follows:
```lisp
(test-brep :type 'box-solid
:length 30
:width 30
:height 20)
```
and the way I am calling the function is:
```lisp
(the test-brep (faces 0) (edges 1) (uv-curve (the test-brep (faces 0) basis-surface)))
```
or
```lisp
(the test-brep (edges 1) (uv-curve (the test-brep (faces 0) basis-surface)))
```
Both of these give the same error! ONLY when visualizing. So I should make a new curve out of that to be able to visualize it.
*By genworks on 2015-01-30 22:57:37 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/95recursive behavior in trimmed-surface face's face's face2015-03-31T02:17:04ZDave Cooperrecursive behavior in trimmed-surface face's face's face*Created by: reiniervandijk*
It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basi...*Created by: reiniervandijk*
It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basis-surface. But, that one is exactly the same. And so we can go on to the next brep in the tree and again and again. Is this behavior as marketed?
**Imported comments:**
*By genworks on 2013-02-08 18:46:06 UTC*
The face of the brep of the trimmed-surface should be identical object to the trimmed-surface itself.
Does it have a different object ID? If so, then perhaps this should be "fixed" so that it resolves to the same object.
On Feb 8, 2013, at 11:27 AM, reiniervandijk <notifications@github.com> wrote:
> It this logical? the trimmed-surface is a face. It's basis-surface is obviously potentially bigger that the trimmed region. However, the brep of the object has another face, this face on it's turn has a basis-surface. But, that one is exactly the same. And so we can go on to the next brep in the tree and again and again. Is this behavior as marketed?
>
> —
> Reply to this email directly or view it on GitHub..
>
*By genworks on 2015-01-30 22:55:24 UTC*
Moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/94stack overflow on brep :edges-sequence message2015-03-31T02:17:04ZDave Cooperstack overflow on brep :edges-sequence message*Created by: reiniervandijk*
stack overflow on brep :edges-sequence message.
Try:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces ...*Created by: reiniervandijk*
stack overflow on brep :edges-sequence message.
Try:
```lisp
(define-object stitching-sample (base-object)
:objects
((box :type 'box-solid
:width 2 :length 2 :height 2)
(clean-surfaces :type 'surface
:sequence (:size 6)
:built-from (the box (faces (the-child index)) :basis-surface))
(stitched :type 'stitched-solid :faces-in (list-elements (the clean-surfaces)))
(stitched-alternative :type 'stitched-solid :faces-in (list-elements (the box :faces) (the-element :basis-surface)))
(stitched-manifold :type 'manifold-solid :brep (the stitched))
)
)
```
And visualize for example
```lisp
(the (clear-surfaces 0) :brep :edges-sequence)
```
**Imported comments:**
*By genworks on 2015-01-30 01:28:43 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/93dependency tracking not working properly?2015-03-31T02:17:03ZDave Cooperdependency tracking not working properly?*Created by: reiniervandijk*
Consider these two objects:
```lisp
(define-object test ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :a (+ (the a) 1)))))))
(define-object test2 ()
:computed-slots
((a...*Created by: reiniervandijk*
Consider these two objects:
```lisp
(define-object test ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :a (+ (the a) 1)))))))
(define-object test2 ()
:computed-slots
((a 0)
(b (prog1 (the a)
(the (set-slot! :c (+ (the a) 1)))))
(c 2)))
```
In the first case, the dependency of :b to :a is lost. In the latter case, it still works. This seems an issue or please explain why it isn't. I encountered this when I tried to make a computed-slot in the tasty inspector remain :unbound forever, as to imitate a function that runs on every click again and again.
```lisp
> (make-self 'test)
#<test @ #x24d54b5a>
> (the a)
0
> (the b)
0
> (the a)
1
> (the (set-slot! :a 33))
nil
> (the (slot-status :b))
:evaluated
> (make-self 'test2)
#<test2 @ #x24d9c422>
> (the a)
0
> (the b)
0
> (the c)
1
> (the (set-slot! :a 33))
nil
> (the (slot-status :b))
:unbound
```
**Imported comments:**
*By genworks on 2013-02-12 15:22:16 UTC*
It is not, has never been, and probably never will be supported to call
set-slot! from within the body of a cached computed-slot.
This issue will remain open until this "feature" is better documented or
maybe even protected against by the compiler.
On Tue, Feb 12, 2013 at 10:03 AM, reiniervandijk
<notifications@github.com>wrote:
> Consider these two objects:
>
> (define-object test ()
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the (set-slot! :a (+ (the a) 1)))))))
> (define-object test2 ()
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the (set-slot! :c (+ (the a) 1)))))
> (c 2)))
>
> In the first case, the dependency to a is lost. In the latter case, it
> still works. This seems an issue or please explain why it isn't.
>
> move> (make-self 'test)#<test @ #x24d54b5a>> (the a)0> (the b)0> (the a)1> (the (set-slot! :a 33))nil> (the (slot-status :b)):evaluatedmove> (make-self 'test2)
> #<test2 @ #x24d9c422>> (the a)0> (the b)0> (the c)1> (the (set-slot! :a 33))nil> (the (slot-status :b)):unbound
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/75>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By reiniervandijk on 2013-02-12 15:40:58 UTC*
This answer is clear, but not really addressing the issue pointed out here. Then please consider
```
(define-object test3 ()
:functions
((foo
()
(the (set-slot! :a (+ (the a) 1)))))
:computed-slots
((a 0)
(b (prog1 (the a)
(the foo)))))
```
and try the same. If I read you correctly, a function is allowed to set-slot! something. I know we use it often here.
*By genworks on 2013-02-12 16:04:49 UTC*
Let's be more general here: it is not supported to do side-effecting within
the body of a cached computed-slot.
The above form implies a side-effect by calling (the foo), which is a
side-effecting function (because itself calls set-slot!), within the body
of the computed slot.
One practical effect of this is that it never makes sense to use progn,
prog1, etc in the body of a computed-slot. The computed slot is intended to
contain exactly one expression, and only to use the return-value of that
expression, and without side-effects. Although in the above example, even
without the prog1, if it were just
```
...
:computed-slots
((a 0)
(b (the foo)))
```
the principle would be violated because (the foo) is a side-effecting
function being called from within the body of a computed-slot.
On Tue, Feb 12, 2013 at 10:40 AM, reiniervandijk
<notifications@github.com>wrote:
> This answer is clear, but not really addressing the issue pointed out
> here. Then please consider
>
> (define-object test3 ()
>
> :functions
> ((foo
> ()
> (the (set-slot! :a (+ (the a) 1)))))
>
> :computed-slots
> ((a 0)
> (b (prog1 (the a)
> (the foo)))))
>
> and try the same. If I read you correctly, a function is allowed to
> set-slot! something. I know we use it often here.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/75#issuecomment-13438267>.
>
>
--
My Best,
Dave Cooper, Genworks Support
david.cooper@genworks.com, dave.genworks.com(skype)
USA: 248-327-3253(o), 1-248-330-2979(mobile)
UK: 0191 645 1699
*By reiniervandijk on 2013-02-12 16:32:48 UTC*
Alright. Do you feel this (rather important) aspect is clearly documented somewhere? It basically defines the main paradigm behind programming slots.
*By genworks on 2013-02-12 21:12:02 UTC*
It definitely needs to be documented in the new tutorial.pdf.
Moreover, your second example (with the indirect call to set-slot!) could never be picked up at compile-time. But, it will be possible to add a low-cost runtime check which will throw an error if an operation like this is attempted.
This Issue will remain open until the documentation is made clear, and the runtime check is in place.
On Feb 12, 2013, at 9:32 AM, reiniervandijk <notifications@github.com> wrote:
> Alright. Do you feel this (rather important) aspect is clearly documented somewhere? It basically defines the main paradigm behind programming slots.
>
> —
> Reply to this email directly or view it on GitHub.
>
*By genworks on 2013-02-18 19:46:03 UTC*
The development version of Gendl now throws a runtime Warning if a set-slot! is attempted anywhere (dynamically) from within the body of a cached slot.
Any opinion on whether this should be an Error instead of a Warning? Or it could be configurable between Error and Warning using a parameter such as *cached-side-effecting-behavior* (possible values of :warn, :error, or nil).
*By reiniervandijk on 2013-02-18 21:40:05 UTC*
The latter option would be best. Default to :error perhaps (because it's not supported) and give error message with cause and solution approach. Maybe also a explanation of how to set this setting in gdlinit. Are you not also using side-effecting in GWL base-ajax sheet, to register sheet-sections? In that case don't forget to locally bind parameter value to nil...
Verstuurd vanaf mijn iPad
Op 18 feb. 2013 om 20:46 heeft Dave Cooper <notifications@github.com> het volgende geschreven:
> The development version of Gendl now throws a runtime Warning if a set-slot! is attempted anywhere (dynamically) from within the body of a cached slot.
>
> Any opinion on whether this should be an Error instead of a Warning? Or it could be configurable between Error and Warning using a parameter such as cached-side-effecting-behavior (possible values of :warn, :error, or nil).
>
> —
> Reply to this email directly or view it on GitHub.
>
*By genworks on 2013-04-11 23:15:57 UTC*
In current codebase and currently released Genworks-GDL 1582 release candidate, this is Warning and not an Error. We have started receiving feedback from the field on it. For safety sake we will consider changing the default to be an Error, after most existing codebase have had a chance to be audited for the Warnings. The issue remains open until it is documented.
*By genworks on 2013-04-11 23:17:32 UTC*
The current version also allows for a keyword argument for set-slot of :warn-on-non-toplevel?
This defaults to t but if you have a case which you know is benign, you can do
(the ... (set-slot! ... :warn-on-non-toplevel? nil))
*By genworks on 2013-04-11 23:20:22 UTC*
One case where this is probably benign is when the bashee is in a separate tree (e.g. constructed with a raw make-object rather than as child :object). The runtime machinery can probably be made to detect these cases and automatically suppress the warning. But for the time being it will be necessary to use the :warn-on-non-toplevel? nil keyword argument in order to suppress warnings in these cases.
Note that the :warn-on-non-toplevel? keyword argument is not documented and subject to change, so any use of it in production code should be flagged.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/89cad-assembly not external in surf package2015-03-31T02:17:01ZDave Coopercad-assembly not external in surf package*Created by: reiniervandijk*
It's documented, visible in YADD, but not external? Isn't that contradicting?
**Imported comments:**
*By genworks on 2015-01-30 01:27:18 UTC*
It's still not officially supported, therefore unexported. *Created by: reiniervandijk*
It's documented, visible in YADD, but not external? Isn't that contradicting?
**Imported comments:**
*By genworks on 2015-01-30 01:27:18 UTC*
It's still not officially supported, therefore unexported. https://gitlab.common-lisp.net/gendl/gendl/-/issues/88[experimental] assembly-import misses object names2015-03-31T02:17:01ZDave Cooper[experimental] assembly-import misses object names*Created by: reiniervandijk*
When importing a step file, names for points and curves are properly extracted. However, names for breps (i.e. advanced-faces / open-shells in STEP) are not captured. Is this hard-coded on Gendl side or is i...*Created by: reiniervandijk*
When importing a step file, names for points and curves are properly extracted. However, names for breps (i.e. advanced-faces / open-shells in STEP) are not captured. Is this hard-coded on Gendl side or is it the SMLib reader that doesn’t extract that info?
It would be quite nice to have the breps names showing up properly, because I need that level of semantics to select the correct objects in a tree.
**Imported comments:**
*By genworks on 2015-01-30 01:24:40 UTC*
moved to internal tracking list.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/81check-continuity function on curve2015-03-31T02:16:59ZDave Coopercheck-continuity function on curve*Created by: reiniervandijk*
This returns nils, not expected.
```lisp
(define-object continuity-sample (base-object)
:input-slots
((curves (list (the default-1) (the default-2))))
:objects
((default-1 :type 'linear-c...*Created by: reiniervandijk*
This returns nils, not expected.
```lisp
(define-object continuity-sample (base-object)
:input-slots
((curves (list (the default-1) (the default-2))))
:objects
((default-1 :type 'linear-curve :start (the center) :end (translate (the center) :right 10))
(default-2 :type 'linear-curve :start (the default-1 :end) :end (translate (the-child :start) :right 5 :rear 5))
(curve :type 'composed-curve :pass-down (curves))
)
)
```
in REPL:
```
> (the check-continuity)
(:distance nil :angle 0.7853981633974484 :length nil)
```
**Imported comments:**
*By genworks on 2015-01-30 01:11:48 UTC*
moved to internal tracking list. https://gitlab.common-lisp.net/gendl/gendl/-/issues/80rational/integer number gives error in extended-curve object2015-03-31T02:16:59ZDave Cooperrational/integer number gives error in extended-curve object*Created by: reiniervandijk*
Try 1/3 value or try 1.
```lisp
(define-object extended-curve-sample2 ()
:input-slots
((distance 1/3 :settable))
:objects
((b-spline-curve :type 'arc-curve
:center (make-point 0 0 0...*Created by: reiniervandijk*
Try 1/3 value or try 1.
```lisp
(define-object extended-curve-sample2 ()
:input-slots
((distance 1/3 :settable))
:objects
((b-spline-curve :type 'arc-curve
:center (make-point 0 0 0)
:radius 1.5
:start-angle 0
:end-angle pi)
(extended-curve-G2 :type 'extended-curve
:curve-in (the b-spline-curve)
:distance (the distance)
:distance-type :relative
:continuity :g2
:display-controls (list :color :red))))
**Imported comments:**
*By genworks on 2015-01-30 01:10:58 UTC*
moved to internal tracking list.
https://gitlab.common-lisp.net/gendl/gendl/-/issues/79write-snapshot doesn't work2015-03-31T02:16:58ZDave Cooperwrite-snapshot doesn't work*Created by: reiniervandijk*
``` lisp
(define-object write-snapshot-test (base-object)
:input-slots
((a 2 :settable))
)
```
Then try:
```lisp
gdl-user> (make-self 'write-snapshot-test :a 5)
#<write-snapshot-test @ #...*Created by: reiniervandijk*
``` lisp
(define-object write-snapshot-test (base-object)
:input-slots
((a 2 :settable))
)
```
Then try:
```lisp
gdl-user> (make-self 'write-snapshot-test :a 5)
#<write-snapshot-test @ #x23b5f4aa>
gdl-user> (the (write-snapshot :filename "D:/test.gdl"))
; No value
```
And the output is according to:
```lisp
(in-package :gdl-user)
(write-snapshot-test)
```
**Imported comments:**
*By genworks on 2013-03-06 17:47:32 UTC*
This is fixed in github. Use the following to preview the fix:
```common-lisp
(in-package :gdl)
(excl:without-package-locks
(define-object-amendment vanilla-mixin* ()
:functions
((active-inputs
()
(let ((inputs (append (the (message-list :category :optional-input-slots))
(the (message-list :category :settable-optional-input-slots))
(the (message-list :category :settable-defaulted-input-slots))
(the (message-list :category :required-input-slots))
(the (message-list :category :defaulted-input-slots)))) result)
(mapc #'(lambda (slot)
(let ((contents (funcall (read-from-string (format nil "gdl-acc::~a" slot)) self)))
(when (and (not (member slot '(:%name% :%parent% :%aggregate% :%index% :$$tatu-object)))
(consp contents) (third contents))
(push slot result) (push (readable-expression (first contents) self) result)))) inputs)
(nreverse result))))))
```
https://gitlab.common-lisp.net/gendl/gendl/-/issues/77approximated curve not working2015-03-31T02:16:58ZDave Cooperapproximated curve not working*Created by: reiniervandijk*
Try the default example object approximated-curve-test and find the error:
!! This section threw error: iwcurve_approximatecurve failed. !!
**Imported comments:**
*By genworks on 2013-03-08 17:33:...*Created by: reiniervandijk*
Try the default example object approximated-curve-test and find the error:
!! This section threw error: iwcurve_approximatecurve failed. !!
**Imported comments:**
*By genworks on 2013-03-08 17:33:09 UTC*
This is a long-standing issue and will be fixed asap in our new release, which will include SMLib 8.6.1 (the current release has 8.5.1 which is now just about a year old, and has had recurring issues with approximated-curve).
*By reiniervandijk on 2013-03-08 17:37:51 UTC*
Okay. If these are long-term issues, where can a user find them? This
object is available in the YADD documentation without any side-notes.
Moreover, it worked for previous releases.
2013/3/8 Dave Cooper <notifications@github.com>
> This is a long-standing issue and will be fixed asap in our new release,
> which will include SMLib 8.6.1 (the current release has 8.5.1 which is now
> just about a year old, and has had recurring issues with
> approximated-curve).
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/genworks/Genworks-GDL/issues/91#issuecomment-14632471>
> .
>