<div dir="ltr"><div>I converted it to ascii using MeshLab</div><div><br></div><div>https://owncloud.iosb.fraunhofer.de/owncloud/s/KpZFxn5SCm0JFmN</div><div><br></div><div>pw: osg</div><div><br></div><div>Yes, using another format is probably a better idea. Do you know which format is typically used that supports binary encoding?<br></div><br>Am Dienstag, 21. Januar 2020 15:41:34 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">On Tuesday, 21 January 2020 14:07:35 UTC, Tom Pollok  wrote:<blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I investigated a little.<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></div></div></blockquote><div><br></div><div>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.<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0;margin-left:0.8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>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></blockquote><div><br></div><div>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.<br></div><div><br></div><div>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.   <br></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.<br></div><div><br></div><div>Robert.</div><div><br></div></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/8ab67c38-9416-4133-843e-deeab1814e42%40googlegroups.com?utm_medium=email&utm_source=footer">https://groups.google.com/d/msgid/osg-users/8ab67c38-9416-4133-843e-deeab1814e42%40googlegroups.com</a>.<br />