This is huge in what it enables. Love the continued innovation . And thanks @roland for the suggestion, we’re in the exact same boat
Very nice, good to see these developments
Any chance this will be implemented for the ActionManager anytime in the near future as well?
Good idea! No plan for now but totally fine to plan for it in the future
@Deltakosh while having a look at this recent post you just answered, I came back to this topic and found out that none of the 2 first demos above are working, due to later changes : picker.setPickingList
and pickingInfo
returned in callback
If you want to edit the links for users who will arrive later on this topic :
- First demo updated (First post)
- Second demo updated (Stress Test with CPU/GPU switch)
++
Tricotou
Fixed!
thanks buddy!
Quick and dirty proof of concept: Babylon.js Playground
Part 2 - World raycasting: https://playground.babylonjs.com/#YW67YY#1
There is some visual flashing though
GPU picking point and normal example - Demos and projects - Babylon.js (babylonjs.com)
Is it possible to integrate the get position and normals into this object as well, and call it as needed.
There is also the ability to get face.
@xiehangyun cool stuff! Why didn’t you make a contribution?
I did my research for the project I was working on, but I didn’t think it was perfect. Later, due to a job change, my current company doesn’t use babylon, and I don’t have much energy to refine the idea. Although I still follow the babylon forum.
GPUPicker is the form I expect, so I’d like to request the integration of point and normals pickup, and maybe one day I’ll come back to Babylon.
Solid, no dirty overrides. Going with this one now: https://playground.babylonjs.com/#YW67YY#2
Yummy!
Hey that would be a cool addition to the feature!
I have been trying to integrate this now in my local project. Here is the latest (prettyfied [sortof…lol]) copy&paste and put in a playground.
GPUPickWithPointer (pickedPoint), currently, can only work with the gBuffer. But the gBuffer comes from the GeometryBufferRenderer which in turn doubles draw calls. Big performance hit
GPUPickWithRay (from/to any world point). My use case is to scan the level on startup for certain features (e.g. cover spots). Many low poly meshes. Scan runtime skyrockets from 5sec to 50sec when switching from mesh raycasting to gpu picking (~1000 picks). I am not seeing how this could be improved - by an order of magnitude
I think even in the best case, the way the GPUPicker works (i.e. onAfterRender of the pickingTexture), means between every pickWithRay you likely will need one scene.render (just pickingTexture.render does not seem to be enough) - if you are off or between the render loop I mean. The latter is probably the default I assume.
Maybe you guys see some mistakes in the code but I have almost lost hope.
@Deltakosh will be able to have a look when he’ll be back next week after a well deserved break.
Please bear with us in the mean time.
Are there any plans to make GPUPicker to work with thinInstances? We use thinInstance picking a fair amount in our project, and it would be great to have this uplift! I updated the test playground just to validate the behavior.
I saw this playground for GPU picking a while back, and I was wondering if this approach of updating the thinInstance buffer with unique colors before rendering and then reassigning the original color buffer could be used.
Thanks!
We should add support for thin instances!
I added an issue to track it: Add support for thin instances in GPUPIcking · Issue #15263 · BabylonJS/Babylon.js (github.com)
Testing this feature now and it seems that IGPUPickingInfo
and PickingInfo
are not synonymous yet. I’m guessing this is still experimental and wip? Any timeline on when it might be ready for production use?
They are not meant to be synonymous
In the future we may add more feature to the gpupicker but they are not meant to be identical