Closed laxnpander closed 2 years ago
My feeling is, this might be related to the fact that the viewer has not finished rendering the last scene and is already called to update again. Do you think this is possible? And is there a way to check whether the graphics card / rendering backend is currently busy?
Yes. That can cause an issue, and the graphics card behavior is not defined.
You already said it is not designed to work well with dynamic updating performancewise. I wouldn't mind performance loss in general, but visual artifacts like this are quite annoying. Do you have a suggestion how to solve it? I already tried to protect my calls to "update_vertex_buffer" with a mutex, so I don't have concurrent calls on it. But it does not seem to help, probably because the Graphics Card is involved.
"mutex" works for CPUs, but GPUs work completely differently.
For reference here is my viewer code. Interesting part is the processKeyframe / drawKeyframe function. Every camera is added as drawable, not sure if this is also not the best way to handle it?
If you have only a few cameras/images, then you will not notice the performance overhead. But if you have tens, hundreds, or even more cameras/images, I suggest you use a single drawable for all the cameras.
For easier debugging, I suggest you dump all keyframes into a file (*.kf) and load them into Mapple to see they are correct. If correctly visualized in Mapple, then it must be something wrong with the rendering or buffer data transfer. If still the same, then the keyframes are not computed correctly.
Yes. That can cause an issue, and the graphics card behavior is not defined.
Is there a way to avoid this? Can I check whether or not creation of the buffer was successful or not?
"mutex" works for CPUs, but GPUs work completely differently.
Jeah sure, my hope was that locking the mutex while creating the buffer also avoids the GPU from multi threaded access (as it is triggered from CPU processes). But this does not seem to work reliably.
If you have only a few cameras/images, then you will not notice the performance overhead. But if you have tens, hundreds, or even more cameras/images, I suggest you use a single drawable for all the cameras.
I tried that, but wasn't really happy. If I remember correctly, the visuals didn't update for the drawables even after calling update_vertex_buffer and a viewer update. Not sure why.
For easier debugging, I suggest you dump all keyframes into a file (*.kf) and load them into Mapple to see they are correct. If correctly visualized in Mapple, then it must be something wrong with the rendering or buffer data transfer. If still the same, then the keyframes are not computed correctly.
I am pretty confident, that the camera position / rotation is fine. It really looks like a memory issue.
If you modify one of the examples in Easy3D so it can reproduce the issue, I will be happy to investigate the issue. Any also, please let me know how it works without multi-threading.
@LiangliangNan: Okay, I will try to create something reproduceable within this week.
I will close this for now, I don't find the time to examine the problem in more detail. I will reopen once it comes back up again.
Okay. Thanks
Hey again,
I am facing a new issue, maybe you can help me with that. I think it is once again linked to the fact, that I dynamically update a 3D point cloud + some drawables. I get the following error every once in a while:
Whenever this error occures, there is a graphic bug in my viewer. You can see the effects here: https://drive.google.com/file/d/1i5n3XzKs92T5Hnv5G0g8yHqUzVGThat0/view?usp=sharing
What happens is I think there is some memory access error, so that when he tries to render the LinesDrawable he uses the wrong points or indices to connect the dots. I observe other effects connected to this as well, where with a new update my whole point cloud suddenly turns green and in the next frame it is okay (RGB colored) again. My feeling is, this might be related to the fact that the viewer has not finished rendering the last scene and is already called to update again. Do you think this is possible? And is there a way to check whether the graphics card / rendering backend is currently busy?
You already said it is not designed to work well with dynamic updating performancewise. I wouldn't mind performance loss in general, but visual artifacts like this are quite annoying. Do you have a suggestion how to solve it? I already tried to protect my calls to "update_vertex_buffer" with a mutex, so I don't have concurrent calls on it. But it does not seem to help, probably because the Graphics Card is involved.
For reference here is my viewer code. Interesting part is the processKeyframe / drawKeyframe function. Every camera is added as drawable, not sure if this is also not the best way to handle it?