Support basic transparency for Mesh3D/Asset3D/Boxes3D/Ellipsoids3D/Capsules3D/Cylinders3D
#11132
Conversation
|
Latest documentation preview deployed successfully.
Note: This comment is updated whenever you push a commit. |
|
Web viewer built successfully.
Note: This comment is updated whenever you push a commit. |
| {{1.0f, 1.0f, 1.0f}, {-1.0f, -1.0f, 1.0f}, {-1.0f, 1.0f, -1.0f}, {1.0f, -1.0f, -1.0f}} | ||
| ) | ||
| .with_triangle_indices({{0, 1, 2}, {0, 1, 3}, {0, 2, 3}, {1, 2, 3}}) | ||
| .with_triangle_indices({{0, 2, 1}, {0, 3, 1}, {0, 3, 2}, {1, 3, 2}}) |
There was a problem hiding this comment.
makes the winding order ccw so that if you make them transparent they don't look awful
| /// Adapter shared with all tests. | ||
| /// | ||
| /// Devices are not re-used since we want to isolate wgpu resources. | ||
| static TEST_ADAPTER: LazyLock<wgpu::Adapter> = LazyLock::new(|| { |
There was a problem hiding this comment.
could go into a separate PR. But on my Windows box this turned out necessary for executing the new tests - there seems to be some race condition in wgpu (or my driver?) when spamming creation of new adapters in parallel. (also, it's slow ;))
Worth deeper investigation from a wgpu pov, but need to isolate it first
There was a problem hiding this comment.
Drive-by: Recently saw a similarly shaped problem elsewhere, but on a different platform (loading libdrm amdgpu in parallel tests). The problem was calling dlopen/LoadLibrary in parallel. Putting it behind a lock was the solution there also
32d964a to
db50197
Compare
1d6ebe8 to
6e814ac
Compare
db50197 to
521c697
Compare
| /// If there are multiple [archetypes.InstancePoses3D] instances logged to the same entity as a mesh, | ||
| /// an instance of the mesh will be drawn for each transform. | ||
| /// | ||
| /// The viewer draws meshes always two-sided. However, for transparency ordering |
There was a problem hiding this comment.
Drive-by: Are there plans to expose an option to disable this? I was a bit surprised that the meshes in the demo posted on socials were two-sided 🤔 (Sorry if this is already answered elsewhere and I missed it)
There was a problem hiding this comment.
I did miss it, it's even linked in the PR description #1741 disregard! 🤦
There was a problem hiding this comment.
but I should also link the issue here
521c697 to
573e8c8
Compare
|
I noticed opacity of images in 3d is fully broken here: It is broken in the current version too, but you can see meshes through them: Since it was already quite broken I think it makes sense to put this in an issue. |
|
good callout. I think we can mitigate it a bit by drawing the images last in the opaque phase until we do the right thing and put transparent images on the transparent phase & take their draw order into account. There's some trickiness on how we combine 2D draw order in 3D, but I'm sure we'll figure something out |
|
filed an issue here should link it in the code |
|
I think these changes look good! So after going through the checkboxes, and the things you wanted to note down in code this should be good to go. |
…m transparent they look nice)
720da4a to
cdd2918
Compare
|
URDF example works just fine with this! happy.urdf.mp4 |
Related
Drawables(new subdivision ofDrawData) tore_renderer#11131What
Uses the newly established
Drawablessorting mechanism to implement classic far to near rendering for all types of meshes.Comes with image comparison tests for all archetypes where this is possible now, plus some unit tests to test the updated mesh renderer draw data buildup & drawable emission.
output_video.mp4
Bunch of limitations still:
Opacityproperty like images in addition?pre-checkin:
put images to last of opaque phase(too hard), link Opacity for images/depth-images/videos/etc. is broken in 3D #11156