[OpenSCAD] multmatrix expands the input matrix to 4x4?
nop.head at gmail.com
Thu Jul 4 03:13:53 EDT 2019
Rotate isn't the same as scale and translate. When operating on 2D objects
you only rotate around Z and that is catered for with rotate(45) which is
the same as rotate(45, [0, 0, 1]).
So there isn't as good a case for rotate taking a 2 vector. I think it
should be a 3 vector if it is passed a vector but then if you do that you
would say multmatrix should only take perhaps three or four 4 vectors.
I agree it is inconsistent but I don't see it as a big problem as it isn't
totally surprising and I don't find it hiding bugs. If you find something
is not rotating around say Z you look to see what you passed in the third
element and if you have only passed two you would see that.
On Thu, 4 Jul 2019 at 01:30, Ronaldo <rcmpersiano at gmail.com> wrote:
> Almost 3 years ago I started a thread, appropriately called " Clarifying
> behaviors <http://forum.openscad.org/Clarifying-behaviors-td18492.html>
> with the following motivation:
> > I see three possible behaviors in the evaluation of an expression by
> > OpenSCAD: it does what is expected, it does something surprising but
> > reasonable and it does something unreasonable. The last one is clearly a
> > bug. The first one is the normal case. My interest now is on the second
> > case: a reasonable surprising behavior. It is surprising when it
> > less common conditions that are not documented. Being undocumented make
> > them not eligible to be a feature and that is the issue.
> I have submitted 3 "surprising" behaviors to be clarified in that thread.
> Two of them were fully discussed and clarifying additions to the wiki were
> made. The third issue were not discussed and were forgotten: exactly the
> subject adrianv brought to light with this thread.
> To approach what would be a reasonable behavior for multmatrix(), I have
> made a comparison with what do other operators when their arguments have
> incomplete lists. And I have found very disturbing results.
> rotate() cube(); // equivalent to rotate([45,0,0])
> rotate([45,30]) cube(); // equivalent to rotate([45,30,0])
> scale() cube(); // WARNING: Unable to convert scale() parameter to a
> number, a vec3 or vec2 of numbers or a number
> scale([2,3]) cube(); // equivalent to scale([2,3,1])
> translate() cube(); // WARNING: Unable to convert translate()
> parameter to a vec3 or vec2 of numbers
> translate([2,3]) cube(); // equivalent to translate([2,3,0])
> As scale() and translate() are used for both 2D and 3D objects, they accept
> 2D or 3D vectors and nothing else as parameter. But rotate(), which is also
> used for 2D objects, behaves in a form similar to multmatrix(), fulfilling
> the missing parameter components with 0. However, rotate is not as
> complacent as multmatrix when the parameter has dimension greater than 3:
> rotate([0,30,0,20]) cube(); // WARNING: Problem converting rotate(a=[0, 30,
> 0, 20]) parameter
> I don't think that multitude of behaviors may be accepted as reasonable.
> Some coherence is demanded here. Either all those operators require proper
> dimensions for their parameters or they should have a consistent behavior
> for incomplete parameters.
> In special, I don't like the ad hoc preview display of 2D objects (not
> abided by render) when some operator bring them out of the XY plane like
> rotate([0,30,0]) square();
> But this is another discussion.
> Finally, I should mention a donbright comment
> <http://forum.openscad.org/Clarifying-behaviors-tp18492p18507.html> in
> previous referred thread:
> In my experience the "de facto" language spec is in the several hundred
> regression tests.
> So, clarifications in the wiki may help the users but it is the inclusion
> new tests in the regression test list that will ensure a given behavior
> be considered valid and be preserved in future versions.
> Sent from: http://forum.openscad.org/
> OpenSCAD mailing list
> Discuss at lists.openscad.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Discuss