-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Jagged edges + "glitchy" overlap when rendering multiple meshes in a single scene? #657
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
Comments
@collinskatie You are currently only rendering with Can you provide the cube mesh you are using so we can reproduce the behavior at the high resolution setting? If you can provide the full code snippet to load and render one mesh and the stacked meshes, we can help you more easily. Regarding the overlap, both meshes are now part of the same mesh, so all the faces are handled equally by the rasterizer - as you have set Also in the rasterization settings make sure you set |
Hi @nikhilaravi - thank you for your reply! The cube mesh function is included below. I realize I actually think I had some issues with the coordinate system! And regarding faces_per_pixel, I'm a bit confused on the exact impact of that parameter. Do we always want faces_per_pixel > 1 if we have multiple stacked meshes? Is there a particular setting of that parameter (say, faces_per_pixel = 5) that you've found to be typically good? And I'll update the bin_size - thanks!!
|
Hi @nikhilaravi , even when adjusting the faces_per_pixel and bin_size, we are having issues where a cube either floats or overlaps with another cube mesh - even though the locations we specify would prohibit overlap and place cubes directly ontop of each other. This seems to particularly be an issue with small cube meshes. Just curious if you have any sense of why we may be having issues with small cube meshes? Does this seem like a face resolution issue? We are using the same method detailed above, where we concatenate individual cube meshes, and adjust the vertices, to render several meshes to a single image. And because we are encountering both floating and overlapping cubes, we can't uniformly adjust the y-coordinate of blocks in our towers to hack-ily amelioriate these issues. Does PyTorch3D have any way to automatically check if meshes will overlap? Below are some examples of floating + overlapping cubes: Thank you for any help as to why this may be happening! |
@collinskatie apologies for the delay! Are you still having problems with this? I have time to look into it now! |
Hi @nikhilaravi! Thank you for your response (PyTorch3D is awesome!) We have mostly fixed the issue above. You were right that increasing the faces_per_pixel definitely helps, particularly using around 10. And I actually found a bug in our mesh function -- the following code works better, in case anyone encounters a similar issue:
However, I did have one other question related to overlap --- if two cube meshes are sitting directly ontop of each other, they end up sharing vertices, which seems to lead to rendered overlap. Do you know if there is a good way to render/combine meshes that sit directly ontop of each other/have contact without overlap issues? I have been able to add a hack by slightly moving one of the blocks up (by something like epsilon = 0.005), but was wondering if there was a better method or already a way to render meshes that have contact along some vertices? Most of the time the rendering works, but it does seem that sometimes surfaces are resolved oddly, leading to overlap? This is a very minor issue, and the hack works well! Just wanted to check though. (as an example, the vertices of these blocks are all lying directly ontop of each other, meaning some blocks share vertices -- which I'm guessing needs to be avoided by a user when working in PyTorch3D?)Thanks! |
@collinskatie glad that increasing faces per pixel helped to partially resolve this. Regarding the overlap issue, are you referring to this effect where the green cube is on top of the purple but you're saying the cubes are actually on top of each other?
To clarify, the the vertices for each mesh in the |
Hi @nikhilaravi , yes that's the issue. The y position is the same for some of the vertices -- though, as seen, the two blocks have different textures. I partially resolved this by adding a tiny amount to the y of the upper block (offsetting the y by 0.05), which helped! Regarding your point about the rendering pipeline -- does that mean it's most important to ensure that the z coordinates are the same? I'm a little confused about the "retained or discarded depending on the z distance" aspect? Thank you again for your help! |
This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days. |
This issue was closed because it has been stalled for 5 days with no activity. |
Hi I was using your great examples @collinskatie and wanted to thank you for this. I have an issues that for some reason I cannot see more than 2 cubes... do you see anything wrong in code below?
|
well never mind... error was:
|
Glad you figured things out! |
❓ Questions on how to use PyTorch3D
Hi, thank you for making such an amazing tool!
I'm currently trying to render a scene of block towers. I am following the method proposed in Issue #15 to concatenate several meshes (in this case, cubes) into a single mesh to render. However, sometimes the edges of these cubes look very jagged, particularly in low-resolution settings. And when adding blur/blending, there are still challenges with overlap.
I'm curious if anyone on the PyTorch3D dev team (or any other user!) has recommendations on how to better render multiple meshes to a single image, where each mesh may have a different color? Does the renderer have issues resolving face overlap, or cases where one block sits directly ontop of another (and how to potentially resolve this on-the-fly?)
Thank you!
Below are some examples of cube "glitches" (the top is shown at 32x32 res and the bottom at 256x256). I've also included a cube mesh in isolation, showing the "jagged" edges.
Here is a sampling of the code used to combine the meshes, in case anything is particulary amiss there.
Thanks for any help/advice!
The text was updated successfully, but these errors were encountered: