-
Notifications
You must be signed in to change notification settings - Fork 1
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
add visualisation directly from trimesh #5
Comments
We had a discussion about that me and Yassir and Yassir highlighted that since PETSIRD already have |
|
Tried. Worked with only installing pyglet, since we already installed scipy to be able to use convexhull of trimesh. Also, discovered that trimesh assumes meters or something, since some of the 3D viewers show only a part of the scanner. Looking at blender, this is due to ?fog of war? being 1000 meter. Same happens with pyglet and dividing everyone by 1000.0 deal with this. See screenshot below. The viewier is meh at best. So, I would leave the issue as is until someone take the time to adjust the show options such that it can look somewhat decent. |
oh well... |
If VTK is not too much of a dependency I think we can set up a good-looking viewer pretty easily. |
I have no idea what we gain from using VTK over pyglet. Pyglet was a pip install and a show, so pretty short and sweet. If VTK is the same and you know how to make it nice, then it would be better than pyglet since no one seems to have a mastery of that tool. However, I would say that I believe that efforts on this endeavor should be minimal: 3D viewer already exists and, for me, the true validation would be for the user to have access to a 3D representation of their scanner via the vendor or whatever and compare it to the 3D mesh created with this repo. I do not see much advantages to a direct viewer since we add a dependencies, which is equivalent, for me, to ask the user to have a 3D viewer and it is not really faster. Well, with meshlab, I can load the 3D mesh created here with a command line, so it is as fast, or even faster when doing visual tests! Nevertheless, it would not be the first time that I am wrong on the viewer optimal form. Good luck if you continue in that direction! |
A separate viewer is not a big deal. My suggestion for pyglet was because it's essentially already in trimesh, and could therefore be a 5 min thing. I agree with @MaxTousss that this seems a large amount of work (not just for writing, but also for maintaining), and VTK is a very large dependency. I'm not going to stop you doing this of course, but would then suggest to do it in a separate repository (using this one). By the way, it's not so clear to me how a VTK viewer would be different from using any other viewer (unless VTIK can consume a trimesh object, but then it can just as well read a .ply presumably). |
A VTK viewer would be better than pyglet in our context since Yassir has experience in it and thus could make it a nice experience. Pyglet might be as powerfull as VTK but we have no one that responded our call for help on that part. |
It'd be nice to be able to directly visualise here. According to the trimesh doc, it's as simple as
networkx
,scipy
,pyglet
combined.show()
So I tried that, but I just get an empty window. Anyone else more luck?
The text was updated successfully, but these errors were encountered: