<div dir="ltr"><div>Also it seems that its not the method<br></div><div><br></div><div>void VertexData::readVertices( PlyFile* file, const int nVertices, <span class="pl-k">const</span> <span class="pl-k">int</span> fields )</div><div>see
https://github.com/openscenegraph/OpenSceneGraph/blob/32566420c9d68a640996d741d13852e8d1229f3e/src/osgPlugins/ply/vertexData.cpp#L48</div><div><br></div><div>that needs to be adapted, but <br></div><div><br></div><div>void VertexData::readTriangles( PlyFile* file, const int nFaces )</div><div>see https://github.com/openscenegraph/OpenSceneGraph/blob/32566420c9d68a640996d741d13852e8d1229f3e/src/osgPlugins/ply/vertexData.cpp#L215<br></div><div><br></div><div><br></div><div>which actually parses the faces.<br></div><div><br></div><div><br></div><br>Am Dienstag, 21. Januar 2020 15:07:35 UTC+1 schrieb Tom Pollok:<blockquote class="gmail_quote" style="margin: 0;margin-left: 0.8ex;border-left: 1px #ccc solid;padding-left: 1ex;"><div dir="ltr"><div>Hi Robert,</div><div><br></div><div>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.</div><div><br></div><div><br></div><div>I investigated a little.</div><div><br></div><div>So it seems that the comment for texture files is actively used:</div><div><br></div><div>comment TextureFile YourTexture_material_0_map_Kd.<wbr>jpg</div><div><br></div><div>So that needs to be parsed, and not ignored as just being a comment.</div><div><br></div><div>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.<br></div><div><br></div><div>Regarding the header, ill add comments from what i understood <br></div><div><br></div><div>ply<br>format ascii 1.0<br>comment VCGLIB generated<br>comment TextureFile Wareneingang_material_0_map_<wbr>Kd.jpg<br>element vertex 99428 //number of vertices<br>property float x //vertex X coordinate<br>property float y //vertex Y coordinate<br>property float z //vertex Z coordinate<br>element face 186642 //number of faces<br>property list <span style="color:rgb(0,0,255)">uchar </span><span style="background-color:rgb(255,255,0)">int vertex_indices</span> //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.<br>property list <span style="color:rgb(255,0,255)">uchar </span><span style="background-color:rgb(0,255,255)">float texcoord</span> //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. <br><span style="color:rgb(234,153,153)">property uchar red</span> //not sure, probably a default color if the number of uv coordiantes was zero because there is no texture file?<br><span style="color:rgb(234,153,153)">property uchar green</span> //not sure, probably a default color if the number of uv coordiantes was zero because there is no texture file?<br><span style="color:rgb(234,153,153)">property uchar blue</span> //not sure, probably a default color if the number of uv coordiantes was zero because there is no texture file?<br><span style="color:rgb(234,153,153)">property uchar alpha</span> //not sure, probably a default color if the number of uv coordiantes was zero because there is no texture file?<br>end_header</div><div><br></div><div>I converted the binary ply to ascii ply and there is one line of a vertex:</div><div><br></div><div>-7.326906 -0.92065 -15.26979 <br></div><div><br></div><div>So x y z totally makes sense.</div><div><br></div><div>Here is the line of a face:<br></div><div><br></div><div><span style="color:rgb(0,0,255)"><b>3</b></span> <span style="background-color:rgb(255,255,0)">74350 89839 97021</span> <span style="color:rgb(255,0,255)"><b>6</b></span> <span style="background-color:rgb(0,255,255)">0.670419 0.990827 0.669870 0.993111 0.668217 0.991639</span> <span style="background-color:rgb(234,153,153)">255 255 255 255</span></div><div><br></div><div>So the explanation in the header makes sense.<br></div><div><br></div><div>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. <br></div><div>But at least wanted to have this documented in case somebody else is running into that issue.<br></div><div><br></div><div><br></div><div><br></div><div><br></div><br>Am Dienstag, 21. Januar 2020 12:47:08 UTC+1 schrieb Robert Osfield:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi Tom,</div><div><br></div><div>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.<br></div><div><br></div><div>I have begun looking into the issue with reading your ply file, I just get a grey model right now. Converting to .osgt using:</div><div><br></div><div> osgconv Wareneingang2.ply test.osgt</div><div><br></div><div>And then looking the test.osgt in an editor reveals that the model has no texture coordinats.</div><div><br></div><div>The next step was to add some debugging to the ply plugin to see what was happening in texture coordinates code:<br></div><div><br></div><div>diff --git a/src/osgPlugins/ply/<wbr>vertexData.cpp b/src/osgPlugins/ply/<wbr>vertexData.cpp<br>index f2db29e00..58293f8dd 100644<br>--- a/src/osgPlugins/ply/<wbr>vertexData.cpp<br>+++ b/src/osgPlugins/ply/<wbr>vertexData.cpp<br>@@ -174,6 +174,9 @@ void VertexData::readVertices( PlyFile* file, const int nVertices,<br> _texcoord = new osg::Vec2Array;<br> }<br> <br>+ std::cout<<"fields = "<<(fields)<<std::endl;<br>+ std::cout<<"fields & TEXCOORD = "<<(fields & TEXCOORD)<<std::endl;<br>+<br> // read in the vertices<br> for( int i = 0; i < nVertices; ++i )<br> {<br><br></div><div>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:</div><div><br></div><div> // determine if the file stores vertex colors<br> for( int j = 0; j < nProps; ++j )<br> {<br> // if the string have the red means color info is there<br> if( equal_strings( props[j]->name, "x" ) )<br> fields |= XYZ;<br> if( equal_strings( props[j]->name, "nx" ) )<br> fields |= NORMALS;<br> if( equal_strings( props[j]->name, "alpha" ) )<br> fields |= RGBA;<br> if ( equal_strings( props[j]->name, "red" ) )<br> fields |= RGB;<br> if( equal_strings( props[j]->name, "ambient" ) )<br> fields |= AMBIENT;<br> if( equal_strings( props[j]->name, "diffuse_red" ) )<br> fields |= DIFFUSE;<br> if (equal_strings(props[j]->name, "specular_red"))<br> fields |= SPECULAR;<br> if (equal_strings(props[j]->name, "texture_u"))<br> fields |= TEXCOORD;<br> if (equal_strings(props[j]->name, "texture_v"))<br> fields |= TEXCOORD;<br> }<br><br></div><div>So... the plugin is only checking for texture_u and texture_v, but if we look at your .ply file the header has: <br></div><div><br></div><div>ly<br>format binary_little_endian 1.0<br>comment VCGLIB generated<br>comment TextureFile Wareneingang_material_0_map_<wbr>Kd.jpg<br>element vertex 99428<br>property float x<br>property float y<br>property float z<br>element face 186642<br>property list uchar int vertex_indices<br>property list uchar float texcoord<br>property uchar red<br>property uchar green<br>property uchar blue<br>property uchar alpha<br>end_header<br></div><div><br></div><div>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.</div><div><br></div><div>Does texcoord now implictly mean a x,y value? Is there some other encoding?</div><div><br></div><div>A quick search online for the spec takes me to:<br></div><div><br></div><div> <a href="http://paulbourke.net/dataformats/ply/" rel="nofollow" target="_blank" onmousedown="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fpaulbourke.net%2Fdataformats%2Fply%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEz9SaBSr2tCXmw5fMUykpZU_O-pQ';return true;" onclick="this.href='http://www.google.com/url?q\x3dhttp%3A%2F%2Fpaulbourke.net%2Fdataformats%2Fply%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEz9SaBSr2tCXmw5fMUykpZU_O-pQ';return true;">http://paulbourke.net/<wbr>dataformats/ply/</a></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div> <br></div></div></blockquote></div></blockquote></div>
<p></p>
-- <br />
You received this message because you are subscribed to the Google Groups "OpenSceneGraph Users" group.<br />
To unsubscribe from this group and stop receiving emails from it, send an email to <a href="mailto:osg-users+unsubscribe@googlegroups.com">osg-users+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href="https://groups.google.com/d/msgid/osg-users/55177541-1e78-4385-be88-6e67c0916100%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/osg-users/55177541-1e78-4385-be88-6e67c0916100%40googlegroups.com</a>.<br />