Also it seems that its not the method void VertexData::readVertices( PlyFile* file, const int nVertices, const int fields ) see https://github.com/openscenegraph/OpenSceneGraph/blob/32566420c9d68a640996d741d13852e8d1229f3e/src/osgPlugins/ply/vertexData.cpp#L48
that needs to be adapted, but void VertexData::readTriangles( PlyFile* file, const int nFaces ) see https://github.com/openscenegraph/OpenSceneGraph/blob/32566420c9d68a640996d741d13852e8d1229f3e/src/osgPlugins/ply/vertexData.cpp#L215 which actually parses the faces. Am Dienstag, 21. Januar 2020 15:07:35 UTC+1 schrieb Tom Pollok: > > Hi Robert, > > oh i didnt mean you to do a deep investigation, i just thought it was a > bug or at least you might know if im doing sth wrong. > > > I investigated a little. > > So it seems that the comment for texture files is actively used: > > comment TextureFile YourTexture_material_0_map_Kd.jpg > > So that needs to be parsed, and not ignored as just being a comment. > > The tools i used (MeshLAB and CloudCompare) are widely used in the > research community or industry. I guess there is no perfect documentation > that keeps track of every "hack", in case that is it is one. > > Regarding the header, ill add comments from what i understood > > ply > format ascii 1.0 > comment VCGLIB generated > comment TextureFile Wareneingang_material_0_map_Kd.jpg > element vertex 99428 //number of vertices > property float x //vertex X coordinate > property float y //vertex Y coordinate > property float z //vertex Z coordinate > element face 186642 //number of faces > property list uchar int vertex_indices //means that a face consists of > a number of vertices, the first uchar states that there is a n uchar at the > beginning that states the number of vertices that make a face. Typically > that is 3, but thats then in the ascii or binary dump. So assuming there > are 3 vertices, then 3 ints (vertex indices) have to be parsed. > property list uchar float texcoord //after the vertex indices there is a > list of float texture coordiantes. The uchar states the number of values. > So this has to be interpreted as uv coordinates like (U0, V0, U1 V1, ..., > Un Vn), as there are 3 vertices, there will be three times two (u+v) == six > floats. The U V coordinates are typically in a rage between 0/0 to 1/1, but > i read somewhere that they could be larger which could mean a mirroring or > some sort of repetition. But lets assume they are always in the range of > 0/0 to 1/1. > property uchar red //not sure, probably a default color if the number of > uv coordiantes was zero because there is no texture file? > property uchar green //not sure, probably a default color if the number > of uv coordiantes was zero because there is no texture file? > property uchar blue //not sure, probably a default color if the number of > uv coordiantes was zero because there is no texture file? > property uchar alpha //not sure, probably a default color if the number > of uv coordiantes was zero because there is no texture file? > end_header > > I converted the binary ply to ascii ply and there is one line of a vertex: > > -7.326906 -0.92065 -15.26979 > > So x y z totally makes sense. > > Here is the line of a face: > > *3* 74350 89839 97021 *6* 0.670419 0.990827 0.669870 0.993111 0.668217 > 0.991639 255 255 255 255 > > So the explanation in the header makes sense. > > It seems like this shouldnt be to difficult to implement. But i can't > promise that I'll find the time to make a PR that fixes that issue. > But at least wanted to have this documented in case somebody else is > running into that issue. > > > > > > Am Dienstag, 21. Januar 2020 12:47:08 UTC+1 schrieb Robert Osfield: >> >> Hi Tom, >> >> FYI, it's was a community submission back in 2009, I don't personally >> know the ply format or have done anything more than cosmetic work on this >> plugin. I basically in the same boat as yourself in terms of ability to >> debug the format, I just have to look at the code and see what it's doing >> with your file. It could be a buggy file, or a buggy plugin, or perhaps a >> revision to the ply specs since the OSG plugin was written. The >> investigation might determine which. >> >> I have begun looking into the issue with reading your ply file, I just >> get a grey model right now. Converting to .osgt using: >> >> osgconv Wareneingang2.ply test.osgt >> >> And then looking the test.osgt in an editor reveals that the model has no >> texture coordinats. >> >> The next step was to add some debugging to the ply plugin to see what was >> happening in texture coordinates code: >> >> diff --git a/src/osgPlugins/ply/vertexData.cpp >> b/src/osgPlugins/ply/vertexData.cpp >> index f2db29e00..58293f8dd 100644 >> --- a/src/osgPlugins/ply/vertexData.cpp >> +++ b/src/osgPlugins/ply/vertexData.cpp >> @@ -174,6 +174,9 @@ void VertexData::readVertices( PlyFile* file, const >> int nVertices, >> _texcoord = new osg::Vec2Array; >> } >> >> + std::cout<<"fields = "<<(fields)<<std::endl; >> + std::cout<<"fields & TEXCOORD = "<<(fields & TEXCOORD)<<std::endl; >> + >> // read in the vertices >> for( int i = 0; i < nVertices; ++i ) >> { >> >> The result was that the plugin wasn't detected any valid texture >> coordinates as the field mask didn't enable TEXCOORD , so then I looked >> header parsing code and it looks like: >> >> // determine if the file stores vertex colors >> for( int j = 0; j < nProps; ++j ) >> { >> // if the string have the red means color info is there >> if( equal_strings( props[j]->name, "x" ) ) >> fields |= XYZ; >> if( equal_strings( props[j]->name, "nx" ) ) >> fields |= NORMALS; >> if( equal_strings( props[j]->name, "alpha" ) ) >> fields |= RGBA; >> if ( equal_strings( props[j]->name, "red" ) ) >> fields |= RGB; >> if( equal_strings( props[j]->name, "ambient" ) ) >> fields |= AMBIENT; >> if( equal_strings( props[j]->name, "diffuse_red" ) ) >> fields |= DIFFUSE; >> if (equal_strings(props[j]->name, "specular_red")) >> fields |= SPECULAR; >> if (equal_strings(props[j]->name, "texture_u")) >> fields |= TEXCOORD; >> if (equal_strings(props[j]->name, "texture_v")) >> fields |= TEXCOORD; >> } >> >> So... the plugin is only checking for texture_u and texture_v, but if we >> look at your .ply file the header has: >> >> ly >> format binary_little_endian 1.0 >> comment VCGLIB generated >> comment TextureFile Wareneingang_material_0_map_Kd.jpg >> element vertex 99428 >> property float x >> property float y >> property float z >> element face 186642 >> property list uchar int vertex_indices >> property list uchar float texcoord >> property uchar red >> property uchar green >> property uchar blue >> property uchar alpha >> end_header >> >> Which suggests it only has a single texcoord, no texcoord_u or texcoord_v >> field that the OSG is assuming is required for textured ply files. For a >> 2D textured file I would expect two fields, like the head explicitly has to >> the x, y, z and red, green, blue, alpha values. >> >> Does texcoord now implictly mean a x,y value? Is there some other >> encoding? >> >> A quick search online for the spec takes me to: >> >> http://paulbourke.net/dataformats/ply/ >> >> Which doesn't say anything explicit about texcoords so it looks like this >> is user definable in which case how to interpret things could be really >> open ended. >> >> I haven't yet found any explanation online about what is expected in this >> case. I know nothing about the tools you've used to create the file. This >> my first experience with looking into the PLY spec and the actual file >> format and haven't away knowing is there is any official guide to what >> should be doing with files which using the texcoords field. To me it looks >> like some tools have decided on their own convention and some other tools >> honour this, but without know exactly what it is I don't have anything to >> go on to make modifications to the OSG's ply plugin. >> >> I have to defer further work on this to members of the community that >> actually use PLY files in their applications, you will have more knowledge >> than myself and what might be meant. >> >> >> -- You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/55177541-1e78-4385-be88-6e67c0916100%40googlegroups.com.
_______________________________________________ osg-users mailing list [email protected] http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
