So I just want to do something really similar to this:
Which comes from this discussion:
But, I want to do it with :
the official Gizmo provided by BabylonJS
react-babylonjs
My idea is to bind the gizmo to a cube, and to apply to this cube a quaternion transformation from the camera rotation. The cube will be invisible and I hope to find a way (with the layerMask hopefully) to hide the gizmo from the main viewport.
Anyway, for now I can’t create two viewports with react-babylonjs… and I don’t really know why? It seems react-babylonjs isn’t supported by playground, so I will just share with you the bit where I thought I was doing what was required:
If the project is mature enough will depend a lot on what is being built and developer experience level - it is just mostly generated code to create and send reconciled differences to babylonjs objects! API support has been extended primarily from github issues. Some properties aren’t supported by the renderer still (from supported API there are 204 unsupported properties last time I counted). It was done that way intentionally to support auto-completion and compiler assistance (and TypeScript). It’s really up to the developer if and how they want to integrate with react. If you want an imperative solution you can try out a hook ( babylonjs-hook - npm (npmjs.com)) or follow the babylonjs docs, but then you need to track all objects and property changes yourself, but for some projects that can be a better way to go. I wrote a turn-based game and it worked really well without react-babylonjs. react-babylonjs provides callbacks, but you can also use react refs as escape hatches for imperative code.
What you were asking for is a declarative way to do something that requires writing imperative code for multiple active cameras. I did offer in your discussion the same day you asked to add support. Any time custom properties are added warrants a discussion. One project goal is to not stray from babylonjs API and keep the transition as easy as possible which is why there are only a dozen custom properties so far and they’re usually only added for a good reason.
react-babylonjs is pretty quiet - there have only been 55 commits and 14 releases this year (last 4 months) - I don’t expect it will get any busier than that, but it is open source! I don’t have nearly as much spare time to work on that project as I would like unfortunately - my day job is very demanding. Another reason that it is quiet is because “it just works” for many people there is nothing missing.
Well, I first opened a post here and I thought then it was more appropriate to do it on the github project.
I didn’t want to be slanderous, nor to diminish this project. I just have a heavy React/Web background. And I got some habits from it (closure, functional, immutability, …). Something hard to transcribe when using BabylonJS (or ThreeJS for that matters). So I found this project which allowed me to stay in my comfort zone. I wanted to know if it was a good idea to try BabylonJS through it.
Anyway thanks for the in-depth explanation. I apologize if my comments were rude, it was not my intention.
I think the comments were good and appropriate and I appreciate them actually. I always look at support and how active a dependency is before bringing it into my own projects. It’s a fair question that would be better answered by somebody besides me was my only point!! There are a LOT of things that can be added that would improve the project tremendously (including documentation), but not so much is being done on the project. I would love to sit down and get Expo working finally, for example. For some people it will be enough as-is and others will find it isn’t! I started on React and BabylonJS at nearly the same time around 5 years ago and I still find the trade-offs difficult. You get so far with the declarative model and probably faster as a React developer, but then you hit walls and end up doing strange things to get it working declaratively.
I think the same can be said for all easy paths - I like to learn more about those moments others have like you did with viewports and activeCameras, because it shows further areas for improvement. Someone recently was trying to do all kinds of stuff with quaternions and transformations declaratively and the declarative model was really messy!