Empathy List Archives

R

Ronaldo

Thu, Jan 26, 2017 10:58 PM

Try this simple code:

$vpr = [0,0,0];
//$vpr=[0,90,45];
cube(20);

After F5 or F6, we are able to set freely a new viewing direction with the
mouse.

Now, comment out the first assignment and uncomment the following one. After
F5 or F6, we are no longer able to freely change the view.

Next, keep both assignment commented. The change of view interaction remains
constrained as in the previous step. Argh!

To restore the normal behavior we have to set $vpr to [0,0,0] first.

This seems more a bug than a intended behavior. I have tried it in version
2015.03-2 in a Windows environment.

--
View this message in context: http://forum.openscad.org/Annoying-behavior-of-vpr-tp20244.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Try this simple code: > $vpr = [0,0,0]; > //$vpr=[0,90,45]; > cube(20); After F5 or F6, we are able to set freely a new viewing direction with the mouse. Now, comment out the first assignment and uncomment the following one. After F5 or F6, we are no longer able to freely change the view. Next, keep both assignment commented. The change of view interaction remains constrained as in the previous step. Argh! To restore the normal behavior we have to set $vpr to [0,0,0] first. This seems more a bug than a intended behavior. I have tried it in version 2015.03-2 in a Windows environment. -- View this message in context: http://forum.openscad.org/Annoying-behavior-of-vpr-tp20244.html Sent from the OpenSCAD mailing list archive at Nabble.com.

TP

Torsten Paul

Thu, Jan 26, 2017 11:04 PM

On 01/26/2017 11:58 PM, Ronaldo wrote:

Next, keep both assignment commented. The change of view interaction
remains constrained as in the previous step. Argh!

Sounds like gimbal lock to me. I'm not totally sure, but I think
the prototype code for supporting the 3d mouse devices has a
solution for this.

And yes, this is certainly not the intended behavior.

ciao,
Torsten.

On 01/26/2017 11:58 PM, Ronaldo wrote: > Next, keep both assignment commented. The change of view interaction > remains constrained as in the previous step. Argh! > Sounds like gimbal lock to me. I'm not totally sure, but I think the prototype code for supporting the 3d mouse devices has a solution for this. And yes, this is certainly not the intended behavior. ciao, Torsten.

R

Ronaldo

Thu, Jan 26, 2017 11:46 PM

Gimbal lock and prototype code sounds like greek to me :)

I want to see my model from a very specific view direction and from there
change the view a little to understand what is going wrong. But I can't do
the change I need.

BTW, I would prefer to set the view direction instead of rotating it.
Rotations are nice when they are about one axis alone. Besides, as I mention
before, the rotations in $vpr are applied in a inverted order in respect to
rotate(). I know we can compute cartesian to polar but almost time we are
working in cartesian coordinates.

--
View this message in context: http://forum.openscad.org/Annoying-behavior-of-vpr-tp20244p20246.html
Sent from the OpenSCAD mailing list archive at Nabble.com.

Gimbal lock and prototype code sounds like greek to me :) I want to see my model from a very specific view direction and from there change the view a little to understand what is going wrong. But I can't do the change I need. BTW, I would prefer to set the view direction instead of rotating it. Rotations are nice when they are about one axis alone. Besides, as I mention before, the rotations in $vpr are applied in a inverted order in respect to rotate(). I know we can compute cartesian to polar but almost time we are working in cartesian coordinates. -- View this message in context: http://forum.openscad.org/Annoying-behavior-of-vpr-tp20244p20246.html Sent from the OpenSCAD mailing list archive at Nabble.com.

DM

doug moen

Fri, Jan 27, 2017 1:00 AM

It looks like gimbal lock to me too.
After executing the example code, I "unlocked" the "gimbal" by executing $vpr
= [0,0,90];

My understanding is that you can avoid this by representing the rotations
internally using normalized quaternions. And I know that QT5 and Eigen both
have quaternion classes. But I only learned about gimbal lock and
quaternions on the weekend, so I can't be sure I know what I'm talking
about.

On 26 January 2017 at 18:04, Torsten Paul Torsten.Paul@gmx.de wrote:

On 01/26/2017 11:58 PM, Ronaldo wrote:

Next, keep both assignment commented. The change of view interaction
remains constrained as in the previous step. Argh!

Sounds like gimbal lock to me. I'm not totally sure, but I think
the prototype code for supporting the 3d mouse devices has a
solution for this.

And yes, this is certainly not the intended behavior.

ciao,
Torsten.

OpenSCAD mailing list
Discuss@lists.openscad.org
http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org

It looks like gimbal lock to me too. After executing the example code, I "unlocked" the "gimbal" by executing $vpr = [0,0,90]; My understanding is that you can avoid this by representing the rotations internally using normalized quaternions. And I know that QT5 and Eigen both have quaternion classes. But I only learned about gimbal lock and quaternions on the weekend, so I can't be sure I know what I'm talking about. On 26 January 2017 at 18:04, Torsten Paul <Torsten.Paul@gmx.de> wrote: > On 01/26/2017 11:58 PM, Ronaldo wrote: > > Next, keep both assignment commented. The change of view interaction > > remains constrained as in the previous step. Argh! > > > Sounds like gimbal lock to me. I'm not totally sure, but I think > the prototype code for supporting the 3d mouse devices has a > solution for this. > > And yes, this is certainly not the intended behavior. > > ciao, > Torsten. > > _______________________________________________ > OpenSCAD mailing list > Discuss@lists.openscad.org > http://lists.openscad.org/mailman/listinfo/discuss_lists.openscad.org > > >

discuss@lists.openscad.org

Annoying behavior of $vpr