-
-
Notifications
You must be signed in to change notification settings - Fork 4.6k
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
Issues with loading OBJ file into TextureMesh and visualizing it #2252
Comments
Marking this as stale due to 30 days of inactivity. It will be closed in 7 days if no further activity occurs. |
This issue is still there.
Maybe the documentation needs some update, too. Since one could presume a return of 0 on, success < 0 on error as many other io functions do in the documents. |
@EwingKang Which PCL version do you use? Have you tried |
@mvieth Thanks for the reply! We're having the Lunar New Year currently so I'm afraid I can't provide more details. I was using the version that came with apt on a Ubuntu 22.04. Not sure if it's the version that came with ros-pcl or just standalone PCL. l'll provide more info maybe next week once we get back to the job. |
@EwingKang Sure, no problem. On Ubuntu 22.04, apt would give you PCL 1.12.1. This problem is fixed in PCL 1.13.0 and newer. So using a newer PCL version should solve the issue for you. |
Just to follow up: On my system I'm using PCL 1.12.1 as @mvieth has mentioned. So I presume it's not a problem anymore.
My original issue was that, when load an .obj mesh file with a single mesh using I really appreciate the super fast response and accurate information. I would try the newer version sometime. Thanks again for mvieth's help. |
Recently I've bumped into issues trying to display a textured mesh in visualizer. The mesh was comping from a
.obj
file produced by MVS-Texturing. The visualized geometry was alright, but the textures were messed up. I remembered that we have a bunch of issues related to this. I did a small research and tried some quick fixes, but the problem turned out to be more complex. I don't have time to address it entirely now, but since I've already invested some time, I decided to summarize my findings for future reference. If someone wants to have this issue fixed and has a reasonable spare time budget, welcome! I will be willing to guide and provide assistance.Reports
GitHub
Specifically this problem:
(I will close all of them in favor of this umbrella issue.)
Related:
Elsewhere
Problem
According to my understanding, the problem is two-fold and needs fixes in multiple PCL modules.
Texture coordinate indices
The first part of the problem has been reported in #1592. In a nutshell, the
TextureMesh
class lacks texture coordinates indices and the loader ignores such indices (if they are present in an.obj
file). Refer to the original report for more details.Hidden assumption in
PCLVisualizer::addTextureMesh()
The second part of the problem has to do with how
TextureMesh
is displayed withPCLVisualizer
. According to my understanding, the hidden assumption in the code is that there should be one-to-one correspondence between vertices (i.e. points in theTextureMesh.cloud
) and UV coordinates inTextureMesh.tex_coordinates
. This means that same vertex can not have different UV coordinates when it appears in different faces.Quick hack
A quick and dirty solution (proposed in #1169) is to load the geometry and texture coordinates with
loadPolygonFileOBJ
(i.e. VTK-based reader) and materials withloadOBJFile
(i.e. PCL's own loader) and then merge them:This works for a single material case, but I suspect will fail if there are multiple materials. (But I did not test.) The reason why this works is that the VTK reader duplicates vertices and texture coordinates for each face.
Solution plan
TextureMesh
..obj
file has texture indices read them;.obj
file does not have texture indices generate sequential indices to mimic current behavior.PCLVisualizer
to use the texture coordinate indices. This means that every vertex of every face should be added to thevtkPolyData
points array (duplicating as needed), same with texture coordinates.TextureMapping
class. I haven't looked into that, but since it producesTextureMesh
objects it probably needs to be updated to populate the newly introduced member field.TextureMesh
es.To verify the results and avoid regressions, we would also need to collect a set of
.obj
files for testing. This should include files produced both by PCL and other software; with and without texture indices; with single and multiple materials.Ideally, the changes in the loader class should be supported by unit tests (which are currently non-existent).
Another approach
VTK 6.3 has a new
vtkOBJImporter
class (merge request) that can handle materials. We could piggy-back on it. However:The text was updated successfully, but these errors were encountered: