-
Notifications
You must be signed in to change notification settings - Fork 1
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
More Makie integration #6
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great. Other than reducing the duplication between the README and Documenter docs (which I think is important), the rest of this I'd leave up to your excellent judgement!
arrows!( | ||
plot, | ||
@lift([$eyeposition_obs]), | ||
@lift([$viewdir_obs]); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go with your frustum idea, should we instead use an arrow for upvector
? With a polar rotation I can imagine some confusion arising from a failure to change this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two arrows might get confusing if we don't have the frustum active, and it's currently pretty finicky - you need to have a second Scene active with the camera being set, otherwise the data source doesn't exist. It's possible to compute the frustum manually but it would be pretty annoying.
Instead of that, we could use a 3D camera mesh as an arrow marker - that would show directionality as well. Currently the arrow doesn't indicate upvector but presumably this would if it's sufficiently large.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points. I don't have a clear idea about how to do this, so let's just do whatever seems reasonable.
oldstate = set_view!(camera, path, t) | ||
``` | ||
|
||
This updates the current `camera` settings from `path` at time `t`. | ||
|
||
### Displaying the path | ||
|
||
``` | ||
```julia |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
With the move to Documenter docs, I think we could also slim the README a lot. Otherwise we have two places we have to keep updated.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can definitely slim the README down (and translate the examples to Documenter syntax)!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Example translation should be done, but I still have to slim down the README.
Co-authored-by: Tim Holy <[email protected]>
Welcome to Codecov 🎉Once you merge this PR into your default branch, you're all set! Codecov will compare coverage reports and display results in all future pull requests. Thanks for integrating Codecov - We've got you covered ☂️ |
This looks awesome, thanks for sticking with it! |
Any idea what causes |
Nope, will look into it though. I based this on GeoMakie, which works, so will have to make sure nothing is different... |
Awesome, great to see it fixed. If it's just slimming the README, I can help with that, so feel free to merge whenever you're comfortable. |
Thanks! I've got a couple more changes I wanted to make, then should be good to go. You can see the docs at https://holylab.github.io/FlyThroughPaths.jl/previews/PR6 |
plotcamerapath
recipe which has a colored line (representing time) and an arrow (representing the camera).xvfb
) so we can use GLMakie on CIduration(path)
for paths as well