[osg-users] Textured ply file is black when loaded.
'Tom Pollok' via OpenSceneGraph Users
osg-users at googlegroups.com
Tue Jan 21 06:23:48 PST 2020
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 osg-users+unsubscribe at googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/55177541-1e78-4385-be88-6e67c0916100%40googlegroups.com.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openscenegraph.org/pipermail/osg-users-openscenegraph.org/attachments/20200121/3529829f/attachment-0001.html>
More information about the osg-users
mailing list