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

Static z-axis rotation #96

Closed
Kevin-Mattheus-Moerman opened this issue Jun 17, 2019 · 5 comments
Closed

Static z-axis rotation #96

Kevin-Mattheus-Moerman opened this issue Jun 17, 2019 · 5 comments

Comments

@Kevin-Mattheus-Moerman
Copy link

Sorry @SimonDanisch but this is a real stopper for me. The current view rotation settings are not useful and should frustrate any computational geometry person (see also: MakieOrg/Makie.jl#38, #76, #80, MakieOrg/Makie.jl#329).
It is not just a matter of a opinion/preference, the current convention is actually not useful and is hindering use of the package.

  1. The current convention differs from all CAD packages and stuff like Blender and MeshLab. Currently Makie feels like somebody inverted the controls on your bike (or it is like everybody is used to riding a Lagrangian bike and currently we need to switch to a Eulerian bike). You might say this is just a preference but still it makes sense to match the standard convention which has been tried and tested and feels most natural to most people. Here is a GIF showing the MeshLab system:
    Peek 2019-06-17 09-09_2

  2. My main objection to the current convention is that not all views are obtainable i.e. the rotation system does not allow all types of orientations. For instance I challenge you to use the current system to make the cat look to the right so we can look at its left flank (while the cat is still facing forward). See my attempt in this GIF
    Peek 2019-06-17 09-09

  3. When one continues to move the mouse in a single direction the direction of rotation should not change. Again if you look at the above GIF, if I move to cursor to the left the direction of rotation switches (perhaps something goes from 1 -> -1 or something after passing the middle?). The axis of rotation and angle should always be based on the cursor motion vector not location.

In short please please please implement the standard CAD convention.

@SimonDanisch
Copy link
Member

Yeah would be nice! It's very hard to get a good reference for camera code, since it's either hidden deep in a complex C++ library, closed source, or one just finds toy example. I even went through the effort to extract the camera code from Blender, but it was so complex I gave up^^

So this was definitely one of the occasions where I had 0 motivation to reinvent the wheel, but I couldn't find any good reference to implement this nicely.
At some point I was just like: ok I wasted way too much time on the camera code, this has to be good enough for now.
Any help to improve this would be very welcome.

Btw, at some point I implemented the cube camera navigation from 3Ds max, which was pretty nice, but integrated rather awkwardly with the rest....

@Kevin-Mattheus-Moerman
Copy link
Author

I did not realize this is difficult to do. I implemented a similar fix for MATLAB based rotation (https://www.gibboncode.org/img/gibbonViewControl.gif, left GIBBON, right MATLAB). Since I'm new to Julia I might not be much help but I can have a look if you like. Could you point me to the right code?

@SimonDanisch
Copy link
Member

Well, it's probably not super hard, but starting from scratch without any mathematical background was definitely not easy, especially if one doesn't really know how the best camera should be ;)
Here lives the 3D camera code:
https://github.com/JuliaPlots/AbstractPlotting.jl/blob/master/src/camera/camera3d.jl

@Kevin-Mattheus-Moerman
Copy link
Author

Thanks. I'll have a look.

@Kevin-Mattheus-Moerman
Copy link
Author

Thanks @SimonDanisch I've moved the discussion over to: JuliaPlots/AbstractPlotting.jl#147

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

No branches or pull requests

2 participants