<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/vertexData.cpp b/src/osgPlugins/ply/vertexData.cpp<br>index f2db29e00..58293f8dd 100644<br>--- a/src/osgPlugins/ply/vertexData.cpp<br>+++ b/src/osgPlugins/ply/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_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>   http://paulbourke.net/dataformats/ply/</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>

<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/b1f92194-53eb-42ff-a7c8-e73cd2a65b60%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/osg-users/b1f92194-53eb-42ff-a7c8-e73cd2a65b60%40googlegroups.com</a>.<br />