[OpenSCAD] multmatrix expands the input matrix to 4x4?
rcmpersiano at gmail.com
Wed Jul 3 20:30:15 EDT 2019
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 comprises
> 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 in
But this is another discussion.
Finally, I should mention a donbright comment
<http://forum.openscad.org/Clarifying-behaviors-tp18492p18507.html> in my
previous referred thread:
In my experience the "de facto" language spec is in the several hundred
So, clarifications in the wiki may help the users but it is the inclusion of
new tests in the regression test list that will ensure a given behavior will
be considered valid and be preserved in future versions.
Sent from: http://forum.openscad.org/
More information about the Discuss