transformed-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 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.
(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:
(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.