Bug with .ply
- Thread starter xenoargh
- Start date
Users who are viewing this thread
AFAIR, it happens when you import obj into Meshlab.
Try export ply from OB, load ply into Meshlab, edit, save as ply and import into OB
Try export ply from OB, load ply into Meshlab, edit, save as ply and import into OB
Tested it out.
It works, but there's a minor problem. If I compute AO in OpenBRF before exporting to .ply, the export causes Meshlab to crash- something about "more than 3 vertexes".
That kind've sucks, as it will make the workflow a little more finicky, but I suppose I can deal with it.
It works, but there's a minor problem. If I compute AO in OpenBRF before exporting to .ply, the export causes Meshlab to crash- something about "more than 3 vertexes".
That kind've sucks, as it will make the workflow a little more finicky, but I suppose I can deal with it.
I loaded ply-s with OpenBrf AO just fine in to Meshlab.
The latter is prone to occasional crashes anyway.
The latter is prone to occasional crashes anyway.
Hrmm. I think there's a real problem here. The issue happens every time that I export from OpenBRF as .ply after doing anything with the mesh normals at all. Meshlab crashes every time. Which sucks, because I need to merge some vertexes at the seam lines, otherwise Meshlab tends to totally hose the mesh when doing displacement. Basically, I'm trying to work up a rocky object that was real, real, real low-poly, by expanding the triangle count a bit. That works, but there are issues at the UV seams that are causing problems. I'll look and see what else might work for me as middleware to get this sorted out.
Hrmm.
Can OpenBRF read the text version of ply? Can't seem to get that to work, either. Seems like using the text version would make it (slightly) easier to figure out what's going sideways here- it's really not a good thing that you can 'corrupt' the data in a way that Meshlab no longer understands upon export.
For example, I took an OBJ, rebuilt it with a bit of noise, and when exported from OpenBRF, Meshlab no longer reads it properly and crashes. So I can fairly easily end up with 'corrupted' data, even though it all works perfectly in OpenBRF. Very irritating; about the only way to take full advantage of doing vertex painting is getting that stuff working properly. Oh well, I'll keep hacking away at this, see if I can find better middleware.
Can OpenBRF read the text version of ply? Can't seem to get that to work, either. Seems like using the text version would make it (slightly) easier to figure out what's going sideways here- it's really not a good thing that you can 'corrupt' the data in a way that Meshlab no longer understands upon export.
For example, I took an OBJ, rebuilt it with a bit of noise, and when exported from OpenBRF, Meshlab no longer reads it properly and crashes. So I can fairly easily end up with 'corrupted' data, even though it all works perfectly in OpenBRF. Very irritating; about the only way to take full advantage of doing vertex painting is getting that stuff working properly. Oh well, I'll keep hacking away at this, see if I can find better middleware.
OK. Tried the following, just to test things out.
1. Build a Voronoi hull from something.
2. Built the uvs in Wings, tested it.
3. Everything looked fine.
4. Exported as 3DS. Meshlab got all... feisty about that. Said that it didn't have a "vertex field", whatever that means.
5. So then I took it to Rhino. Exported as OBJ.
6. Imported to Meshlab.
7. Exported to PLY.
Success. No distortions.
So... something is !#@*!@'d up in Meshlab's OBJ importer, for sure, and only Rhino apparently meets its specifications. And then when it's exported, you can't do post-edit in OpenBRF and bring it back to Meshlab, because it's very likely not to work- there's definitely a bug there, but not on OpenBRF's import side.
1. Build a Voronoi hull from something.
2. Built the uvs in Wings, tested it.
3. Everything looked fine.
4. Exported as 3DS. Meshlab got all... feisty about that. Said that it didn't have a "vertex field", whatever that means.
5. So then I took it to Rhino. Exported as OBJ.
6. Imported to Meshlab.
7. Exported to PLY.
Success. No distortions.
So... something is !#@*!@'d up in Meshlab's OBJ importer, for sure, and only Rhino apparently meets its specifications. And then when it's exported, you can't do post-edit in OpenBRF and bring it back to Meshlab, because it's very likely not to work- there's definitely a bug there, but not on OpenBRF's import side.
OK, confirmed that that workflow works. Now for the final test- whether it works after adding vertex colors. If yeah, at least there's a workflow, even if it's a one-way ride. I will submit a bug report to the Meshlab folks about this when I can document it a little better- I think it has something to do with Materials.
Wow, Meshlab hoses PLY exports even if you don't change geometry, if it's not 100% happy with the OBJ.
So... meh... workflow...
1. Take object you want to do vertex painting on.
2. Do all of your changes, except for vertex painting / AO. And I mean, all of them, because once you pass this point, there's no going back.
3. Export from Rhino3D 3.0 to Meshlab, as OBJ.
4. Do vertex painting in Meshlab.
5. Export from Meshlab, as PLY.
6. Export to OpenBRF.
...profit?
Wasn't quite expecting this much pain, lol. So much for making an EZ demo for this- I've used 6 apps as middleware today to get this far, and now need to return to something productive
So... meh... workflow...
1. Take object you want to do vertex painting on.
2. Do all of your changes, except for vertex painting / AO. And I mean, all of them, because once you pass this point, there's no going back.
3. Export from Rhino3D 3.0 to Meshlab, as OBJ.
4. Do vertex painting in Meshlab.
5. Export from Meshlab, as PLY.
6. Export to OpenBRF.
...profit?
Wasn't quite expecting this much pain, lol. So much for making an EZ demo for this- I've used 6 apps as middleware today to get this far, and now need to return to something productive
OK, this is the result. A lot of work for a fricking rock, but now that I know the process, I can do it:
Straight shots from OpenBRF. Uses just one 1024 skin. 1789 verts.
That said... this is painful, and I doubt anybody else here has the weird collection of apps I used to do it with. I would like to humbly offer my apologies to GetAssista; he's right, we probably need a vertex painter in OpenBRF, because Meshlab sucks, is unstable at the darndest times, and is the pickiest app in terms of file formats I've run across in a long, long while. I guess that's why it's free.
Straight shots from OpenBRF. Uses just one 1024 skin. 1789 verts.
That said... this is painful, and I doubt anybody else here has the weird collection of apps I used to do it with. I would like to humbly offer my apologies to GetAssista; he's right, we probably need a vertex painter in OpenBRF, because Meshlab sucks, is unstable at the darndest times, and is the pickiest app in terms of file formats I've run across in a long, long while. I guess that's why it's free.
Nice model!
I can try to make the process smooth.
BTW, did you double check that your Meshlab version is up to date?
I would really avoid situations where "once you pass [a given] point, there's no going back": it should be possible to avoid that. Also, MeshLab is not supposed to be crashy or picky, even if sometimes it is, so maybe it can be fixed too, if the error is on its side (I'm among its developers after all). For sure, MeshLab adopts an internal structure for meshes which is quite different than M&B one, especially in terms of storing attributes (normals, UV, colors...). It is way more general, but also fall shorts in some respect with respect to BRF. This make some algorithm a lot more complicated, some other a lot simpler.
Right now I'm extra busy with RL, but I'll be able to have a closer look at these problems (hopefully) soon.
Maybe someone PMs me a brf that is problematic, with simple instructions, like: "export it as ply, then import in mehslab, and it crashes/it destroys UV".
I can try to make the process smooth.
BTW, did you double check that your Meshlab version is up to date?
I would really avoid situations where "once you pass [a given] point, there's no going back": it should be possible to avoid that. Also, MeshLab is not supposed to be crashy or picky, even if sometimes it is, so maybe it can be fixed too, if the error is on its side (I'm among its developers after all). For sure, MeshLab adopts an internal structure for meshes which is quite different than M&B one, especially in terms of storing attributes (normals, UV, colors...). It is way more general, but also fall shorts in some respect with respect to BRF. This make some algorithm a lot more complicated, some other a lot simpler.
Right now I'm extra busy with RL, but I'll be able to have a closer look at these problems (hopefully) soon.
Maybe someone PMs me a brf that is problematic, with simple instructions, like: "export it as ply, then import in mehslab, and it crashes/it destroys UV".
Yeah, definitely using the latest Meshlab. In terms of process, what I found was that any OBJ not exported from Rhino had screwed UVs along the seams when exported from Meshlab as .ply; even OBJ from Rhino went sideways if I did any vertex deformation. It was pretty annoying the first time, after painting verts for an hour, to find it was all junk, but hey, I'm a modeler, stuff like that happens
Not quite sure what that means, and I should probably shut up about it and just send you a file. Perhaps Meshlab's doing something different with the Rhino and non-Rhino versions? How about I send both versions and let you to a test of that, when you get the chance?
Not quite sure what that means, and I should probably shut up about it and just send you a file. Perhaps Meshlab's doing something different with the Rhino and non-Rhino versions? How about I send both versions and let you to a test of that, when you get the chance?
