Re: [osg-users] Textured ply file is black when loaded.
While i agree that it makes no sense for ply to support any application specific formats, I still support the idea of allowing for importing a small subset of possibilities. If the plugin is called osgdb_ply.dll, how should one know that it only supports the semantic of equalizergraphics. Is there a warning that only one format is supported? Is it documented other than by the implemented parser itself? Anyways, I personally just think that the format that was used in the data that I used is not so special. If you take a look then it is semantically not much different than the ones used in obj files, except that there are extra R G B A fields. And I think it is not a bad idea to have it, as it is then possible to have a binary way of storing large textured meshes. Am Freitag, 24. Januar 2020 03:50:28 UTC+1 schrieb julienvalentin51: > > Hi > PLY is a meta format. It means its interpretation is application > specific...The simple fact to map ply metadata to osg attribute semantic > (texture coordinate for ex) is a complete nonsense. > osgply plugin might have been developped without that in mind and have > implement an application semantic mapping (Equalizer LGPL source) > if you want to use ply format you'll have to implement your own plugin i'm > afraid > Cheers > > Le lundi 20 janvier 2020 11:38:08 UTC+1, Tom Pollok a écrit : >> >> I converted the repaired obj meshmodel from >> https://groups.google.com/forum/#!topic/osg-users/BBUYMYiWGl8 using >> MeshLab to a ply file. >> >> https://owncloud.iosb.fraunhofer.de/owncloud/s/fF6tLLgDCu2xwZk >> >> Pw: osg >> >> I can load the ply file using MeshLab and CloudCompare, but when loading >> the ply file using openscenegraph 3.6.2 then i just get model that is >> completely black. >> >> The header defines in a comment that there is a texture file: >> >> ply >> 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 >> >> But MeshLab did not create an mtl file, however as said, other tools can >> still load the model. >> >> For loading i use: >> >> osgDB::Options* opt = new >> osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr >> node = osgDB::readNodeFile(pathToPlyFile, opt); >> >> -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/4ed6afe3-8286-4450-8ba3-924e9abdbe52%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Textured ply file is black when loaded.
PLY is a meta format. It means its interpretation is application specific...The simple fact to assign its data to osg attribute semantic is a nonsense, but it's the most probable application semantic Le lundi 20 janvier 2020 11:38:08 UTC+1, Tom Pollok a écrit : > > I converted the repaired obj meshmodel from > https://groups.google.com/forum/#!topic/osg-users/BBUYMYiWGl8 using > MeshLab to a ply file. > > https://owncloud.iosb.fraunhofer.de/owncloud/s/fF6tLLgDCu2xwZk > > Pw: osg > > I can load the ply file using MeshLab and CloudCompare, but when loading > the ply file using openscenegraph 3.6.2 then i just get model that is > completely black. > > The header defines in a comment that there is a texture file: > > ply > 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 > > But MeshLab did not create an mtl file, however as said, other tools can > still load the model. > > For loading i use: > > osgDB::Options* opt = new > osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr > node = osgDB::readNodeFile(pathToPlyFile, opt); > > -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/30874a4f-46d6-44f3-bbca-957eeab54b27%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Textured ply file is black when loaded.
On Tuesday, 21 January 2020 15:03:12 UTC, Tom Pollok wrote: > > I converted it to ascii using MeshLab > > https://owncloud.iosb.fraunhofer.de/owncloud/s/KpZFxn5SCm0JFmN > > pw: osg > Thanks. For future reference this might be useful. At this point in time I don't feel confident about inferring the data usage as it could be so open ended. Have you come across any formal specification that MeshLab are assuming for their export? Perhaps ask them. > Yes, using another format is probably a better idea. Do you know which > format is typically used that supports binary encoding? > I can't answer this. The OSG is used in many different sectors with many different tools there isn't one binary file format that is used pervasively. Perhaps others in your sector might be able to advice. Cheers, Robert -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/482b7f89-7c53-4c2f-9553-21c45e4ee842%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Textured ply file is black when loaded.
I converted it to ascii using MeshLab https://owncloud.iosb.fraunhofer.de/owncloud/s/KpZFxn5SCm0JFmN pw: osg Yes, using another format is probably a better idea. Do you know which format is typically used that supports binary encoding? Am Dienstag, 21. Januar 2020 15:41:34 UTC+1 schrieb Robert Osfield: > > On Tuesday, 21 January 2020 14:07:35 UTC, Tom Pollok wrote: >> >> 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 >> > > Did you regenerate the scene, the .ply you shared earlier is a binary. > ascii is easier to infer what is going on so the dev/debugging stage using > ascii makes sense, then once it's working try the binary. > > > >> 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's makes partial sense... each far having 6 additional floats and a red, > green, blue, alpha colour. How one is supposed to interpret those 6 floats > seems to be left to the implementation to infer that it means each vertex > has a Vec2(u,v) value for it, that's an inference based on this particular > dataset, there doesn't look to be an formal mapping. > > The design of the format looks like each face could have any number of > floats in the list, so one face could legally have 0 additional floats, > while the next could have 10, then the next 1 and so for. To parse the > texcoord as a Vec2(u,v) one would have to make sure that there are 6 > floats, and also since the OSG binds the vertex, normal and texcoords > arrays as BIND_PER_VERTEX one would need to duplicate the vertex and > normals to match the per corner texcoords. > > Then after generating all the geometry one would probably be best to run a > mesh optimizer to remove all the duplicate vertices/normal/texcoord pairs > and reset all the triangle indices. To not due this optimization pass > would likely lead to massively larger and inefficient geometries. > > It's all possible but does all require a bit of work and inference that > that's how the data is intended to be used. > > This all tells me that PLY might be used in some sectors but it really > isn't a good format for doing so, it likely would be far better to use a > more standardized format that doesn't have implicit mappings that you have > to infer based on the data that some 3rd party tools have chosen to pump > out. > > Robert. > > -- You received this message because you are subscribed to the Goog
Re: [osg-users] Textured ply file is black when loaded.
On Tuesday, 21 January 2020 14:07:35 UTC, Tom Pollok wrote: > > 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 > Did you regenerate the scene, the .ply you shared earlier is a binary. ascii is easier to infer what is going on so the dev/debugging stage using ascii makes sense, then once it's working try the binary. > 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's makes partial sense... each far having 6 additional floats and a red, green, blue, alpha colour. How one is supposed to interpret those 6 floats seems to be left to the implementation to infer that it means each vertex has a Vec2(u,v) value for it, that's an inference based on this particular dataset, there doesn't look to be an formal mapping. The design of the format looks like each face could have any number of floats in the list, so one face could legally have 0 additional floats, while the next could have 10, then the next 1 and so for. To parse the texcoord as a Vec2(u,v) one would have to make sure that there are 6 floats, and also since the OSG binds the vertex, normal and texcoords arrays as BIND_PER_VERTEX one would need to duplicate the vertex and normals to match the per corner texcoords. Then after generating all the geometry one would probably be best to run a mesh optimizer to remove all the duplicate vertices/normal/texcoord pairs and reset all the triangle indices. To not due this optimization pass would likely lead to massively larger and inefficient geometries. It's all possible but does all require a bit of work and inference that that's how the data is intended to be used. This all tells me that PLY might be used in some sectors but it really isn't a good format for doing so, it likely would be far better to use a more standardized format that doesn't have implicit mappings that you have to infer based on the data that some 3rd party tools have chosen to pump out. Robert. -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/f7625d4d-1caa-4513-aaf3-34c6cada1cdc%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/l
Re: [osg-users] Textured ply file is black when loaded.
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
Re: [osg-users] Textured ply file is black when loaded.
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::cout<<"fields & TEXCOORD = "<<(fields & TEXCOORD)< + > // 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" ) ) >
Re: [osg-users] Textured ply file is black when loaded.
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)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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/b1f92194-53eb-42ff-a7c8-e73cd2a65b60%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Textured ply file is black when loaded.
I converted the repaired obj meshmodel from https://groups.google.com/forum/#!topic/osg-users/BBUYMYiWGl8 using MeshLab to a ply file. https://owncloud.iosb.fraunhofer.de/owncloud/s/fF6tLLgDCu2xwZk Pw: osg I can load the ply file using MeshLab and CloudCompare, but when loading the ply file using openscenegraph 3.6.2 then i just get model that is completely black. The header defines in a comment that there is a texture file: ply 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 But MeshLab did not create an mtl file, however as said, other tools can still load the model. For loading i use: osgDB::Options* opt = new osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr node = osgDB::readNodeFile(pathToPlyFile, opt); -- 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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/osg-users/32ffc1ad-5bce-43d3-a983-a777e1a981ae%40googlegroups.com. ___ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org