-
-
Notifications
You must be signed in to change notification settings - Fork 890
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
TextureMesh
significantly slower when using non-zero --resolution-level
#1094
Comments
Doing more experiments, I couldn't replicate this issue. Running the full reconstruction (sparse, dense, model, texture) for varying |
first of all you are not using the same input, you should make the experiemnt with changing only resolution level and nothiing else second, all command line paths are relative to the working folder, no need to set full path for any argument, except the working folder; your command are very hard to parse and read |
The input data is the same, that was the point of the issue. The reconstruction was, however, ran twice, so the vertices/faces are slightly different. |
I'll close the issue for now, will reopen when I have some more concrete examples. |
what do u mean by the same if the first is
and the second is
|
The input data is the same (exactly same images). The reconstruction was then ran and so the meshes produced differ slightly. It was therefore strange that the differences in texturing were as large as I mentioned. |
@cdcseacave just ran into the issue again, this time with the same input data (attached below). It seems that This is very unintuitive since the packing theoretically shouldn't rely on this parameter (at least from my understanding). input.zip |
Describe the bug
The texturing of a mesh takes significantly more time when using a resolution level that is higher than zero (done to reduce memory consumption for larger scenes).
Resolution level
0
:Resolution level
3
:This is very likely due to the fact that there are
71
patches in the resolution0
and89266
in resolution3
, which is strange since the code should arguably behave in the same way.Is there something I'm missing?
The text was updated successfully, but these errors were encountered: