Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Issue #123: implement turntable mouse navigation #144

Closed
wants to merge 18 commits into from

Conversation

dynamodan
Copy link
Contributor

I took a little time to implement this. It wasn't very difficult. This comes with config checkbox (disabled by default).

@@ -70,6 +70,8 @@ void SolveSpaceUI::Init() {
drawBackFaces = CnfThawBool(true, "DrawBackFaces");
// Check that contours are closed and not self-intersecting
checkClosedContour = CnfThawBool(true, "CheckClosedContour");
// Use turntable mouse navigation
checkTurntableNav = CnfThawBool(false, "CheckTurntableNav");
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"check" in "checkClosedContour" doesn't mean "checkbox", it's a part of the option name

src/mouse.cpp Outdated
if(SS.checkTurntableNav) {
projRight = orig.projRight.RotatedAbout(Vector::From(0, 1, 0), -s*dx);
projUp = orig.projUp.RotatedAbout(Vector::From(orig.projRight.x, orig.projRight.y, 0), s*dy); // lock the Z to vertical
} else {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please use our coding style

@dynamodan
Copy link
Contributor Author

Ok so commit d11ba14 addresses the variable naming and the coding style (I think). I think it was the one line being more than 100 characters long, but you didn't specify. Not sure if you will like the coding style yet. :)

@whitequark
Copy link
Contributor

@dynamodan There are more tabs in that commit...

Anyway, other than style issues I like it. Unfortunately we still have to sort out a CLA for external contributions so I can't merge it just yet, but I'm on it.

whitequark
whitequark previously approved these changes Dec 31, 2016
@whitequark
Copy link
Contributor

Hm, don't you think the Y axis is not the right one? The initial sketch is on the XY plane, so if you're extruding it then the 'turntable' will not rotate parallel the extrusion vector.

@dynamodan
Copy link
Contributor Author

The build failed due to some write permission in the mac part of the travis CI:
[ 72%] Built target solvespace /Applications/Xcode.app/Contents/Developer/usr/bin/make -f src/CMakeFiles/solvespace-dmg.dir/build.macd /Users/travis/build/solvespamake[2]: write error make[1]: *** [src/CMakeFiles/solvespace-dmg.dir/all] Error 1 make[1]: write error make: *** [all] Error 1 +echo 'I can'\''t believe how deep the Travis brokenness goes. Retrying...' ./.travis/build-macos.sh: line 13: echo: write error: Resource temporarily un The command "if [[ "$TRAVIS_OS_NAME" == "osx" ]]; then ./.travis/build-macos.sh; fi" exited with 1. Done. Your build exited with 1. /Users/travis/build.sh: line 148: shell_session_update: command not found

Doesn't have anything to do with this pull.

@dynamodan
Copy link
Contributor Author

Hm, don't you think the Y axis is not the right one?
I thought about that... One thing I realized is that when I export to triangle mesh for Blender, then the part is lying on its side. I may try to get this to match Blender's coordinate system where the Z axis is "up". Is that what you were referring to? I also noticed that by default, Y seems to be "up" in solvespace. Or maybe it's just that the default view is from the top, which makes it seem so.

@Evil-Spirit
Copy link
Collaborator

Evil-Spirit commented Jan 9, 2017

@dynamodan, just use the z axis for upvector like all the normal guys.

@dynamodan
Copy link
Contributor Author

@Evil-Spirit I tried to make Z (the blue axis) be vertical, but it causes some strange bugs. By default, Y is vertical, I'm sure of it, because of the way the horizontal and vertical constraints are messed up in some work planes when Z is "up". So... Y is up for now.

@whitequark
Copy link
Contributor

@dynamodan Horizontal and vertical constraints have nothing to do with XYZ (i.e. the global coordinate system). They are defined in reference to the workplane they're in.

@Evil-Spirit
Copy link
Collaborator

@whitequark, I can try to fix this for Z axis

@dynamodan
Copy link
Contributor Author

Here's a screenshot of what I mean by the constraints being messed up. They aren't really -- the constraints still work perfectly to constrain the lines straight. The sketching is being done in the ZX workplane, with Z pointing "up", that is, toward the top of the screen.
solvespace - new sketch _004

@whitequark
Copy link
Contributor

Yeah, that only affects the text orientation.

@dynamodan
Copy link
Contributor Author

Well, not just the H and V lying on their sides, but the H is on the vertical segment, and the V is on the horizontal segment. It really confused me the other day, LOL! Anyway, in the context of turntable mouse navigation, I'm happy.

@whitequark
Copy link
Contributor

@dynamodan Actually, now that I look closer, there's no issue. Try pressing F2 (without any turntable mode enabled). You'll see that horizontal will become what you expect from the constraints.

@dynamodan
Copy link
Contributor Author

dynamodan commented Jan 17, 2017

I've discovered a new bug in my turntable nav implementation. When the view is aligned to a workplane that tilts the locked axis to horizontal (i.e. parallel to my desk surface), the view becomes locked to middlebutton+drag mouse navigation. (Other movements still work, such as ctrl+middlebutton+drag and shift+middlebutton+drag.)

So in regard to this pull request, don't pull and merge just yet.

@dynamodan
Copy link
Contributor Author

This is done now -- I've fixed the issue of Z not staying vertical when some workplanes are active. Also, over the last few weeks I've been periodically pulling and merging from the master branch and testing to keep my fork fresh so whenever you're ready it should be good to pull.

@whitequark
Copy link
Contributor

@dynamodan OK. I'll take a look soon. We unfortunately still don't have a CLA so I can't merge yet.

@whitequark
Copy link
Contributor

We have a CLA now so hopefully this will be merged soon!

@dynamodan
Copy link
Contributor Author

That's good news! Did you do the merge yet? I just tonight merged from the latest (16540b1 at this moment) commit and successfully built in my fork. I try to do this periodically.

@whitequark
Copy link
Contributor

Still waiting on CLA stuff...

@whitequark
Copy link
Contributor

Thank you for your contribution, and welcome. The SolveSpace project has a Contributor License Agreement; in order for me to be able to merge your pull request, please sign it at https://cla-assistant.io/solvespace/solvespace. It will take only a small amount of your time.

@whitequark whitequark force-pushed the master branch 2 times, most recently from 371f33b to fb1065d Compare July 12, 2018 20:24
@dynamodan
Copy link
Contributor Author

I signed the CLA. I'll pull the latest and get my branch up to date, seems like that will make it easier to pull the turntable stuff.

);
}

InvalidateGraphics(); // not sure if this is needed after the AnimateOnto, but hey
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nope, AnimateOnto implies InvalidateGraphics.

Copy link
Contributor

@whitequark whitequark left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It looks like you have some extra changes in extlib/libdxfrw, can you exclude these? Also, it would be great if you could squash and rebase your commits so that it's just a single commit on top of master, but if you can't figure that out, I can do it myself as well.

@dynamodan
Copy link
Contributor Author

I'll try to see what changed in extlib/libdxfrw, but they weren't my changes that I know of. I believe I had simply run

git submodule update --init extlib/libdxfrw

as directed in the build instructions. Something could have changed in that submodule?

@dynamodan
Copy link
Contributor Author

I excluded extlib/libdxfrw. Not sure if I did it correctly, as now the appveyor and travis builds fail.

@whitequark
Copy link
Contributor

No, you just deleted the submodule...

@dynamodan
Copy link
Contributor Author

I guess I don't understand how to do this. When I checkout your branch, the extlib/libdxfrw folder is empty. When I checkout my branch, the extlib/libdxfrw folder is empty. Same, same! But when I do git submodule update --init extlib/libdxfrw in my branch, I get error: pathspec 'extlib/libdxfrw' did not match any file(s) known to git

@whitequark
Copy link
Contributor

Thanks! I'll take a closer look soon and merge--there isn't obviously wrong that I can see.

@whitequark
Copy link
Contributor

Merged in master, thank you for your contribution and patience.

@whitequark whitequark closed this May 23, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants