-
Notifications
You must be signed in to change notification settings - Fork 407
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
feature request: cameraMatrices
prop in <Worldview />
component
#270
Comments
This definitely seems like a good feature to add. Let's think about the API a bit more — some of the properties in cameraState would be replaced by the view matrix and some by the projection matrix, right?
I was thinking it might be nice to group these properties in with the cameraState, but now I realize if both matrices are specified then there's nothing left in cameraState (except that keyboard/mouse controls depend on the values in cameraState, but you said you'd probably want to disable those). I'd be a bit hesitant to keep adding new props to Worldview since it already has so many, but maybe we can change the type of cameraState to include both alternatives Do you think you (or other users) would want to supply one of these matrices but not the other? As an point of reference, the XRView interface defined in the WebXR spec provides a cc @brianc @vidaaudrey who worked with raw view/projection matrices for a Worldview VR project :) |
Thanks for the feedback! 😸 Just spent some time poking at it this morning and I think I have a plan for moving forward.
I totally see your concern. I think it's a matter of documentation though. There are 3 groups of users who all want a simple explanation (and ideally an example) of the props they need to use.
Personally I don't need Worldview to manage input events… that's firmly outside of the scope of what I want it to do for me. But it's definitely convenient if we want this to be a one stop shop for building a 3D application. That's a whole other discussion though.
Turning
I think in most cases if someone is using matrices, they'll probably provide both.
Using the name
Dealing with Anyway, it seems like we'll be able to reach alignment one way or another and at this point I'll just need to make a branch for more feedback. Here's my current plan:
We have a sprint coming up where we're focusing on FE infra. I'll plan to tackle this during the week of Dec 9. Open to discussing more here but probably won't be able to do much until then. Does that sound like a reasonable plan? |
yeah, agreed if we have both docs and warnings, this should be fine.
we'll have to see about this organization, since if the matrices are a separate prop from cameraState it doesn't make as much sense to group them with the cameraState stories...but they are camera-related, so maybe it's fine. You might find some opportunities to clean up the organization while you're there. Looking forward to your branch! |
Hey there, we haven't forgotten about this. We have a fork over at https://github.com/hoverinc/webviz/ As we continue to integrate Worldview into our apps, we are finding more tweaks we need to make. I think our plan to merge might have been a bit premature. It's still something we would like to do, but it might make sense to wait until our changes have stabilized a bit more. |
Cool, feel free to make a PR if you think it's stable enough now. 😄 |
Awesome library, thanks for all you do! 😺
I'd like to supply my own camera matrices to
<Worldview />
instead of thecameraState
object.the idea
data model
new behavior
<Worldview />
component checks for validcameraMatrices
prop on mount and update, sets them incameraStore
which uses them directly with priority overcameraState
benefits
adds support for arbitrary camera parameters in a standard format, expanding use cases
drawbacks
introduces more complexity to the camera state api
what do you think about this design? i'm eager to contribute if you think it fits.
The text was updated successfully, but these errors were encountered: