Re: [osg-users] Rendering a Depthmap

['Tom Pollok' via OpenSceneGraph Users]

Is there a way to do this directly with osg or does it need a custom 
implementation? If no, is anybody able to share code for how to render a 
depthmap with intrinsic camera parameters as a 3d pointcloud using shaders?

Am Mittwoch, 12. Juni 2019 21:18:38 UTC+2 schrieb Trajce Nikolov NICK:
>
> Hi Lucas,
>
> I have this working (Lidar scans simulation). If you post snippets I might 
> be able to help you. You can private msg me too
>
> Cheers
> Nick
>
> On Wed, Jun 12, 2019 at 2:25 PM Glenn Waldron  > wrote:
>
>> Lucas,
>> Just guessing, but it sounds like you are experiencing a problem knows as 
>> "shadow acne." There's a good explanation of it here along with some 
>> possible mitigation ideas. Very common problem when projecting a depth map 
>> back onto the main camera.
>>
>>
>> http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/
>>  
>>  
>> Glenn Waldron
>>
>>
>> On Wed, Jun 12, 2019 at 6:47 AM Lucas Amparo > > wrote:
>>
>>> Hi, everyone
>>>
>>> I'm trying to render a depthmap using shaders. Very simple, just using 
>>> the distance from an arbitrary point P to the camera's eye. That map will 
>>> be deprojected into a pointcloud.
>>>
>>> The problem is an unexpected (by me lol) behavior from the deprojection. 
>>> Using a tutorial (can't post links yet), I've done the work but the result 
>>> seems weird.
>>>
>>> For example, if I had a perfect wall on the scene, the depthmap is 
>>> projected similar to a "rinnegan" (do you remember naruto? Is the best way 
>>> to represent the problem )
>>>
>>> Someone already did something similar to that? What's the best way to 
>>> make a depthmap on OSG? Tutorials, examples, books are very welcomed.
>>>
>>> Thank you!
>>>
>>> Cheers,
>>> Lucas
>>>
>>> --
>>> Read this topic online here:
>>> http://forum.openscenegraph.org/viewtopic.php?p=76186#76186
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> osg-users mailing list
>>> osg-...@lists.openscenegraph.org 
>>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>>
>> ___
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>
>
> -- 
> trajce nikolov nick
>

-- 
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/fdcf0da7-44d8-4c83-beda-42f710fb57ef%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.

['Tom Pollok' via OpenSceneGraph Users]

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.

['Tom Pollok' via OpenSceneGraph Users]

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 

Re: [osg-users] Textured ply file is black when loaded.

['Tom Pollok' via OpenSceneGraph Users]

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 

Re: [osg-users] Textured ply file is black when loaded.

['Tom Pollok' via OpenSceneGraph Users]

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" ) )
> 

[osg-users] Textured ply file is black when loaded.

['Tom Pollok' via OpenSceneGraph Users]

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

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Hi Laurens,

thank you for clarification! My problem was that im using openscenegraph in 
combination with osgEarth. I figured out how to fix it, so in case other 
osg and osgEarth users might run into the same issue.

To fix the issue i had to include

#include 

and after loading the model i had to run the shader generator on the model.

osgEarth::Registry::shaderGenerator().run( model );

Now everything works fine.

Thank you very much for your super quick help @Laurens and @Robert !!!

Best,
Tom

Am Mittwoch, 15. Januar 2020 13:00:41 UTC+1 schrieb Voerman, L.:
>
> Hi Tom,
> Your model works with texture for me, in osg 3.4.0 as well as 3.6.5 with 
> the following commands:
> sed -E "s#(f [0-9]+/[0-9]+)/0 ([0-9]+/[0-9]+)/0 ([0-9]+/[0-9]+)/0#\1 \2 
> \3#" "Data2.obj" > noNormals.obj
> osgviewer -O noRotation  noNormals.obj 
> Laurens.
>
>
> On Wed, Jan 15, 2020 at 12:24 PM 'Tom Pollok' via OpenSceneGraph Users <
> osg-...@googlegroups.com > wrote:
>
>> Hello Robert,
>>
>> to test it with my old osg version, i fixed the obj file such it does not 
>> contain any indices to normals anymore, as there are no normals.
>> This indeed helped loading the model, but no textures appear at all. 
>> Should it load the textures automatically due to the first line in the obj 
>> file being mtllib Data.mtl and the use of usemtl material_0 before the 
>> faces or do i need to take extra care when loading a textured model?
>>
>> For loading, im using only:
>>
>> osgDB::Options* opt = new 
>> osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr 
>> node = osgDB::readNodeFile(pathToObjFile, opt);
>>
>>
>> Best,
>> Tom
>>
>>
>> Am Dienstag, 14. Januar 2020 17:25:27 UTC+1 schrieb Robert Osfield:
>>>
>>> On Tue, 14 Jan 2020 at 15:26, 'Tom Pollok' via OpenSceneGraph Users <
>>> osg-...@googlegroups.com> wrote:
>>>
>>>> Thank you for the workaround.
>>>>
>>>> So as far as i understand you only add the texture coordinate and 
>>>> normal, if there exists one with a index greater than 0 and less then the 
>>>> number of normals or texture coordinates.
>>>> So that means that openscenegraph now will be able to display the 
>>>> textured mesh, even if the normals are missing, right?
>>>>
>>>
>>> Yes, that's correct, you'll get a textured mesh with no normals assigned.
>>>
>>> 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-...@googlegroups.com .
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/osg-users/b55a82c5-4801-49da-b1c4-149d868bd6fa%40googlegroups.com
>>  
>> <https://groups.google.com/d/msgid/osg-users/b55a82c5-4801-49da-b1c4-149d868bd6fa%40googlegroups.com?utm_medium=email_source=footer>
>> .
>> ___
>> osg-users mailing list
>> osg-...@lists.openscenegraph.org 
>> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>>
>

-- 
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/79d8878f-0123-4a3a-8d70-1e2e3eb9e20c%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Hello Robert,

to test it with my old osg version, i fixed the obj file such it does not 
contain any indices to normals anymore, as there are no normals.
This indeed helped loading the model, but no textures appear at all. Should 
it load the textures automatically due to the first line in the obj file 
being mtllib Data.mtl and the use of usemtl material_0 before the faces or 
do i need to take extra care when loading a textured model?

For loading, im using only:

osgDB::Options* opt = new 
osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr node 
= osgDB::readNodeFile(pathToObjFile, opt);


Best,
Tom


Am Dienstag, 14. Januar 2020 17:25:27 UTC+1 schrieb Robert Osfield:
>
> On Tue, 14 Jan 2020 at 15:26, 'Tom Pollok' via OpenSceneGraph Users <
> osg-...@googlegroups.com > wrote:
>
>> Thank you for the workaround.
>>
>> So as far as i understand you only add the texture coordinate and normal, 
>> if there exists one with a index greater than 0 and less then the number of 
>> normals or texture coordinates.
>> So that means that openscenegraph now will be able to display the 
>> textured mesh, even if the normals are missing, right?
>>
>
> Yes, that's correct, you'll get a textured mesh with no normals assigned.
>
> 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/b55a82c5-4801-49da-b1c4-149d868bd6fa%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Thank you for the workaround.

So as far as i understand you only add the texture coordinate and normal, 
if there exists one with a index greater than 0 and less then the number of 
normals or texture coordinates.
So that means that openscenegraph now will be able to display the textured 
mesh, even if the normals are missing, right?

Am Dienstag, 14. Januar 2020 16:01:11 UTC+1 schrieb Robert Osfield:
>
> I have checked in a workaround for the invalid indices to the 3.6 branch 
> and master:
>
> 
> https://github.com/openscenegraph/OpenSceneGraph/commit/2b9c501e18b6eded7375c0e272aff401ad9793a2
>

-- 
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/562cb694-52e1-4e80-b64b-909a2e716e79%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Am Dienstag, 14. Januar 2020 15:23:15 UTC+1 schrieb Robert Osfield:
>
>
> On Tuesday, 14 January 2020 13:54:37 UTC, Tom Pollok wrote:
>>
>> I used OpenMVS to create it:
>>
>> https://github.com/cdcseacave/openMVS
>>
>
> The model isn't a valid .obj file, I am not familiar with OpenMVS and as I 
> have my own open source projects to manage I'll leave it to others to fix 
> OpenMVS.  I would suggest having a look at the .obj export yourself or 
> creating an Issue for it, but a quick look at the github page makes me 
> wonder if the Issue tracker is being largely ignored or misused at there 
> are 95 items in there.
>
 

>  
>
>> I can also view the model using MeshLab or other tools.
>>
>
> These other tools must have added a catch for this type of invalid model.
>  
>
>>
>> Is it possible to fix the invalid references in openscenegraph?
>>
>
> I am currently modifying the OSG's obj loader to catch the invalid data as 
> crashing is as much as a bug as the dodgy data.  I expect to get a fix 
> checked in this afternoon so it'll be part of the OSG-3.6 branch and the up 
> coming 3.6.5 release.
>

> Robert.
>  
>

Thank you Robert for your help and thank you for all your efforts for 
openscenegraph!
Best, Tom.

-- 
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/8db7521b-2941-4624-9c75-b71e20ca1453%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Hello Laurens,

thank you for your investigation!

Best,
Tom

Am Dienstag, 14. Januar 2020 14:10:27 UTC+1 schrieb L. Voerman:
>
> repost in google group; It seems like my reply to the mailing list does 
> not show up in google groups.
>
> Hi Tom,
> I think your obj file is invalid, as the faces all reference normal "0" 
> and 
> 1> no normals are provided
> 2> normal indices start at 1 (according to wikipedia 
> )
>
> if I reduce your obj file to just the first face (removing material and 
> all but vertex/texcoord 0-1-2) ( attached )
> I get the same crash with
> osgconv DataFace1.obj
> removing the /0 (normal ref) three times fixes the problem - same works 
> for the large file (with textures working)
> Laurens.
>
> On Monday, January 13, 2020 at 12:12:48 PM UTC+1, Tom Pollok wrote:
>>
>> I added a zip file with the mesh. It happens when loading that obj file.
>>
>> https://owncloud.iosb.fraunhofer.de/owncloud/s/dc8dkbXrQz3gTuh
>>
>> Pw: osg
>>
>> I have to check for the stack trace again.
>>
>> osgDB::Options* opt = new 
>> osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr 
>> node = osgDB::readNodeFile(pathToObjFile, opt);
>>
>> Im using two windows machines with intel processors (64bit). 
>> OSG was built by ourselves. 
>> One has an integrated intel graphics unit and one with a Nvidia 2080Ti.
>>
>>
>> Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>>>
>>> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:

 When loading a textured mesh from an obj file with mtl + texture file, 
 openscenegraph crashes.

 I use openscenegraph 3.4.1. Does anybody know if that issue has been 
 fixed in newer versions?

>>>
>>> I don;t recall reports of crashes associated with .obj.
>>>
>>> Could you provide a link to the model that is causing the problem?
>>>
>>> Could you provide a stack trace?
>>>
>>> What platform are you working on?  Did you build the OSG yourself?  
>>>
>>> What hardware are you working on?
>>>
>>> Cheers,
>>> Robert,
>>>
>>
>>
>> Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>>>
>>> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:

 When loading a textured mesh from an obj file with mtl + texture file, 
 openscenegraph crashes.

 I use openscenegraph 3.4.1. Does anybody know if that issue has been 
 fixed in newer versions?

>>>
>>> I don;t recall reports of crashes associated with .obj.
>>>
>>> Could you provide a link to the model that is causing the problem?
>>>
>>> Could you provide a stack trace?
>>>
>>> What platform are you working on?  Did you build the OSG yourself?  
>>>
>>> What hardware are you working on?
>>>
>>> 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/35f1fdb6-f7a2-410b-afbf-b2911388438f%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

I used OpenMVS to create it:

https://github.com/cdcseacave/openMVS

I can also view the model using MeshLab or other tools.

Is it possible to fix the invalid references in openscenegraph?


Am Dienstag, 14. Januar 2020 14:36:29 UTC+1 schrieb Robert Osfield:
>
> I have looked at the model with the 3.6 branch and get the crash and 
> concur with Luarens - the model is broken, it has normal indices assigned 
> to the faces but no normal array.  The crash occurs because the OSG's obj 
> plugin is assuming that if normal indices are provided they are valid 
> normal indices.
>
> Where did this model come from?
>

-- 
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/f766688a-6560-4b0a-82a9-db3d1dbb4fc8%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Imported .obj file not showing textures.

['Tom Pollok' via OpenSceneGraph Users]

Which version of openscenegraph are you using?

Would you mind trying my obj model with mtl and jpg texture file.

https://owncloud.iosb.fraunhofer.de/owncloud/s/dc8dkbXrQz3gTuh 


Pw: osg

I use the following to load it, but it crashes on my system with 
openscenegraph_3.4.1. 
Im curious if it works on your system.

osgDB::Options* opt = new 
osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr node 
= osgDB::readNodeFile(pathToObjFile, opt);


Am Dienstag, 14. Januar 2020 10:52:54 UTC+1 schrieb JILJITH JOHN:
>
> [image: Capture.PNG]
>
> [image: Capture.PNG]
> Hi,
>
> I am developing a tool for editing 3D models using openscenegraph. When I 
> tried to load an .obj file, the texture is not applied. I am getting only 
> black shade.
> The model is imported using the below code. 
>
>
>  osg::ref_ptr model1= osgDB::readNodeFile(path.toStdString());
>  model1->setDataVariance(osg::Object::DYNAMIC);
>
>
>
>

-- 
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/16b6202d-9322-4880-a5a9-bb92abf1e1aa%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

Hello Robert,

I added a minimal reproducer and a stracktrace (release). Unfortunately i 
only have release builds on this machine, but I could provide debug stack 
trace from another system later...

Best,
Tom



Am Montag, 13. Januar 2020 12:12:48 UTC+1 schrieb Tom Pollok:
>
> I added a zip file with the mesh. It happens when loading that obj file.
>
> https://owncloud.iosb.fraunhofer.de/owncloud/s/dc8dkbXrQz3gTuh
>
> Pw: osg
>
> I have to check for the stack trace again.
>
> osgDB::Options* opt = new 
> osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr 
> node = osgDB::readNodeFile(pathToObjFile, opt);
>
> Im using two windows machines with intel processors (64bit). 
> OSG was built by ourselves. 
> One has an integrated intel graphics unit and one with a Nvidia 2080Ti.
>
>
> Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>>
>> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:
>>>
>>> When loading a textured mesh from an obj file with mtl + texture file, 
>>> openscenegraph crashes.
>>>
>>> I use openscenegraph 3.4.1. Does anybody know if that issue has been 
>>> fixed in newer versions?
>>>
>>
>> I don;t recall reports of crashes associated with .obj.
>>
>> Could you provide a link to the model that is causing the problem?
>>
>> Could you provide a stack trace?
>>
>> What platform are you working on?  Did you build the OSG yourself?  
>>
>> What hardware are you working on?
>>
>> Cheers,
>> Robert,
>>
>
>
> Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>>
>> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:
>>>
>>> When loading a textured mesh from an obj file with mtl + texture file, 
>>> openscenegraph crashes.
>>>
>>> I use openscenegraph 3.4.1. Does anybody know if that issue has been 
>>> fixed in newer versions?
>>>
>>
>> I don;t recall reports of crashes associated with .obj.
>>
>> Could you provide a link to the model that is causing the problem?
>>
>> Could you provide a stack trace?
>>
>> What platform are you working on?  Did you build the OSG yourself?  
>>
>> What hardware are you working on?
>>
>> 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/e8e0c207-93e6-49ff-accc-2f4e7ba1be6e%40googlegroups.com.
<>
.  0  Id: 12bc.2d94 Suspend: 1 Teb: 0062`5477d000 Unfrozen
Child-SP  RetAddr   Call Site
0062`545ed090 7ffd`400749f2 MSVCP140D!std::_Debug_message+0x46
0062`545ed0d0 7ffd`40094947 osgdb_objd+0x449f2
0062`545ed110 7ffd`40094c62 osgdb_objd+0x64947
0062`545ed1f0 7ffd`4005e7c4 osgdb_objd+0x64c62
0062`545ed260 7ffd`4005f18a osgdb_objd+0x2e7c4
0062`545edc30 7ffd`4005c0d7 osgdb_objd+0x2f18a
0062`545ee1b0 7ffd`256206a7 osgdb_objd+0x2c0d7
0062`545ee650 7ffd`255f8d44 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0x28b751
0062`545ee690 7ffd`255f9bb7 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0x263dee
0062`545eeeb0 7ffd`255f206f 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0x264c61
0062`545ef0e0 7ffd`2544c39f 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0x25d119
0062`545ef180 7ffd`255eb4f0 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0xb7449
0062`545ef300 7ff6`5dd52baa 
osg131_osgDBd!osgDB::PropertyInputIterator::readBool+0x25659a
0062`545ef3c0 7ff6`5dd59f4d osgTest!main(int argc = 0n1, char ** argv = 
0x01dc`a7b57b50)+0x36a
0062`545ef710 7ff6`5dd57bbd osgTest!WinMain(struct HINSTANCE__ * 
__formal = 0x7ff6`5dd5, struct HINSTANCE__ * __formal = 
0x`, char * __formal = 0x01dc`a7b45e07 "", int __formal = 
0n10)+0xed [c:\users\qt\work\qt\qtbase\src\winmain\qtmain_win.cpp @ 104]
0062`545ef790 7ff6`5dd57a67 osgTest!invoke_main(void)+0x2d 
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 99]
0062`545ef7d0 7ff6`5dd5792e osgTest!__scrt_common_main_seh(void)+0x127 
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 253]
0062`545ef830 7ff6`5dd57bd9 osgTest!__scrt_common_main(void)+0xe 
[f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl @ 296]
0062`545ef860 7ffd`53598364 osgTest!WinMainCRTStartup(void)+0x9 
[f:\dd\vctools\crt\vcstartup\src\startup\exe_winmain.cpp @ 17]
0062`545ef890 7ffd`53977091 KERNEL32!BaseThreadInitThunk+0x14
0062`545ef8c0 ` ntdll!RtlUserThreadStart+0x21

   1  Id: 12bc.2a88 Suspend: 1 Teb: 0062`5477f000 Unfrozen
Child-SP  RetAddr   Call Site
0062`548ff5c8 7ffd`5394354e ntdll!ZwWaitForWorkViaWorkerFactory+0x14
0062`548ff5d0 7ffd`53598364 ntdll!RtlReleaseSRWLockExclusive+0x1ade
0062`548ff9d0 

Re: [osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

I added a zip file with the mesh. It happens when loading that obj file.

https://owncloud.iosb.fraunhofer.de/owncloud/s/dc8dkbXrQz3gTuh

Pw: osg

I have to check for the stack trace again.

osgDB::Options* opt = new 
osgDB::Options;opt->setOptionString("noRotation");osg::ref_ptr node 
= osgDB::readNodeFile(pathToObjFile, opt);

Im using two windows machines with intel processors (64bit). 
OSG was built by ourselves. 
One has an integrated intel graphics unit and one with a Nvidia 2080Ti.


Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>
> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:
>>
>> When loading a textured mesh from an obj file with mtl + texture file, 
>> openscenegraph crashes.
>>
>> I use openscenegraph 3.4.1. Does anybody know if that issue has been 
>> fixed in newer versions?
>>
>
> I don;t recall reports of crashes associated with .obj.
>
> Could you provide a link to the model that is causing the problem?
>
> Could you provide a stack trace?
>
> What platform are you working on?  Did you build the OSG yourself?  
>
> What hardware are you working on?
>
> Cheers,
> Robert,
>


Am Freitag, 10. Januar 2020 19:45:26 UTC+1 schrieb Robert Osfield:
>
> On Friday, 10 January 2020 18:01:57 UTC, Tom Pollok wrote:
>>
>> When loading a textured mesh from an obj file with mtl + texture file, 
>> openscenegraph crashes.
>>
>> I use openscenegraph 3.4.1. Does anybody know if that issue has been 
>> fixed in newer versions?
>>
>
> I don;t recall reports of crashes associated with .obj.
>
> Could you provide a link to the model that is causing the problem?
>
> Could you provide a stack trace?
>
> What platform are you working on?  Did you build the OSG yourself?  
>
> What hardware are you working on?
>
> 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/4464ef67-e303-45cf-adce-c68472d0d558%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] Loading textured meshes (obj+mtl) leads to crash in osg 3.4.1

['Tom Pollok' via OpenSceneGraph Users]

When loading a textured mesh from an obj file with mtl + texture file, 
openscenegraph crashes.

I use openscenegraph 3.4.1. Does anybody know if that issue has been fixed 
in newer versions?

-- 
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/a6713d30-91b6-49b3-a240-d98f87781461%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org