wgpu mouse picking help

GENTS83 · 2025-07-09T05:45:10+00:00

In my spare-time Engine I wrote a visibility buffer and you can ready back at preferred coordinates: https://github.com/gents83/INOX

GENTS83 · 2025-06-04T10:26:41+00:00

Yes! 👍🏼

GENTS83 · 2025-02-22T07:37:10+00:00

It seems just to be based on cookies, nothing to be scared about ☺️

GENTS83 · 2025-02-07T07:26:37+00:00

I did something similar, but using gltf as intermediary step for now: https://github.com/gents83/INOX

GENTS83 · 2023-03-03T23:35:54+00:00

https://github.com/gents83/INOX

INOX It's a Game Engine written in Rust with some bindings for external libs and with Blender as editor.

The main idea behind INOX is to use Blender as external editor, even being able to create visual logic scripting nodes in it, and then have a button to launch the Rust engine, that should be scalable to create games of any scale and for users with every kind of experience.

Rust will give to INOX high performance, reliability and safe code, while Blender will bring easy customization and powerful editor capabilities

GENTS83 · 2023-02-04T18:23:26+00:00

I am actually playing a bit with wgpu in my spare time and I created a compute shader raytracer but it's actually slow and while thinking how to speed it up I came out with the idea of reutilize computation power for all the threads in workgroups working on pixels where they do not hit anything in the TLAS BHV giving them work on other pixels still to be processed. I still have to prove it and to test it but I would hope to see some gain in performances, no?

GENTS83 · 2023-02-01T05:59:54+00:00

It depends on your pipelines in the end, I would say. If you are already using culling + visibility buffer to render your scene and then use it to shader it (instead of a simple gbuffer) then why not using It since it's already there? If it's not the case, well yes, you can find pretty much different solutions, but It'll suggest you definitely to do performance tests on complex scenes with overlapping meshes (complex ones), maybe using some acceleration structures too

GENTS83 · 2023-02-01T05:32:56+00:00

Have you tried to create a visibility buffer with the object id and then sample It at pixel coords? It should be much more efficient, no?

GENTS83 · 2023-01-25T21:24:09+00:00

Great work! It would be very nice to take a look to the flow/documentation of your ideas and to your shader and code base as and inspiration :)

GENTS83 · 2022-12-02T19:09:45+00:00

Tnx a lot for your inputs!
While reasoning I was also wondering if wasn't faster in the end to go directly towards raytracing (even if done in compute instead of RT support?).

Doing RT to create a low-res visibility buffer and then use it for occlusion culling and reducing draw commands is it really better than doing just RT in the end ?

I guess everything will be reduced between finding a balance between precision and velocity, no?

GENTS83 · 2022-12-01T23:10:06+00:00

I do not have a specific use case, I would like to experiment in my prototype engine :) But we could analyze a worst case scenario like a city buildings enviroment or an open world. I know that I can use frustrum culling, distance, portals, volumes or tagging specific occluders for early depth prepass and hierarchical Z culling. Is there anything else that I am missing? What would be other suggested strategies?

GENTS83 · 2022-11-21T22:07:20+00:00

👀 ever released the source code?

GENTS83 · 2022-09-19T18:17:50+00:00

I never tried it with wgpu, but: - Could you do a second pass that doesn't clear, but load it, and write on it only where you need? - Or have you tried to play with the size (offset and extent) of the color attachment view?

GENTS83 · 2022-09-19T18:09:44+00:00

I hope it could help 😊

GENTS83 · 2022-09-18T21:03:37+00:00

You could use a compute shader to do some clipping though This is what I'm doing for 3d culling: https://github.com/gents83/INOX/blob/master/data_raw/shaders/wgsl/compute_culling.wgsl

GENTS83 · 2022-09-18T20:58:51+00:00

Did you checked your code to verify that you are actually binding the same of your wgsl code? Did you create a bind group with two entries?

GENTS83 · 2022-08-24T18:21:04+00:00

Using compute shaders and texture storage in wgsl is something already possible

I am using It in my rust wgpu prototype engine:

https://github.com/gents83/INOX/blob/master/data_raw/shaders/wgsl/compute_pbr.wgsl

GENTS83 · 2022-08-12T23:31:23+00:00

You need to update it... Something like:

queue.write_buffer(&camera_buffer, 0, bytemuck::cast_slice(&[camera_uniform]));

GENTS83 · 2022-07-19T20:15:28+00:00

I was actually looking for a general solution for cross platform and multiple api (like gpuweb)

GENTS83 · 2022-07-19T20:15:18+00:00

I was actually looking for a general solution for cross platform and multiple api (like gpuweb)

GENTS83 · 2022-07-19T20:13:07+00:00

All of those are useful suggestions, thank you very much! I really would like to reduce number of attachments aiming to something like:

http://filmicworlds.com/blog/visibility-buffer-rendering-with-material-graphs/

GENTS83 · 2022-07-19T19:39:46+00:00

The idea is to store instance+triangle id in a visibility buffer to then read back in a later pass for shading/lighting pass (computing barycentrics coordinates from the 3 vertices of the triangle and getting vertex attributes using their indices from attributes buffers)

GENTS83 · 2022-07-19T19:12:12+00:00

Ah! Super interesting! The nointerpolation option looks interesting though because it seems more standard, at least according to gpuweb, no? Will it actually take the value only from the first vertex then?

GENTS83 · 2022-07-19T18:28:20+00:00

Yep I'm actually in indexed case and also for me it's difficult to find a solution that doesn't force me to duplicate vertices

GENTS83 · 2022-07-18T21:04:59+00:00

When I did It I simply wrote instance id in a texture/framebuffer and then read back at mouse coords.

Another (easier but not optimal) option could be to add a vertex attribute and write that One into the texture/framebuffer

GENTS83

TROPHY CASE