Re: [osg-users] camera functionality issue

[Ravi]

We have got the camera panning by calculating the resultant of two 
vectors(previous vector before panning and changed vector after panning) 
and compared its magnitude with a value to restrict its position in camera 
view. But when we zoom in and zoom out the magnitude of the vector that 
geometry can cover side by side changes and hence the hardcoded value is of 
no help to us anymore.


On Tuesday, January 21, 2020 at 7:57:53 PM UTC+5:30, Robert Osfield wrote:
>
> How far have you got?  What problems do you have?
>

-- 
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/e5468c08-d827-4226-a1d8-1b2d9eb7fc57%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.

[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 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

Re: [osg-users] camera functionality issue

[Robert Osfield]

How far have you got?  What problems do you have?

-- 
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/fb9dad1a-856f-481d-a746-68aa16d6f6ce%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]

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

Re: [osg-users] camera functionality issue

[Robert Osfield]

Could you change you user name to a human name, it helps the community to 
converse respectively.

-- 
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/701c7428-1142-4aa1-a3cc-c07838005a68%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.

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

Re: [osg-users] Node with different projection/view matrix fixed pipeline

[Robert Osfield]

The way I'd tackle dragging of objects in model space that are billboarded 
icons would be to project the mouse coords into clip coords then into 
object space using the matrices inverse of the (projection * view * 
model).  You'd also need to compute the depth to use, this could be 
computed by taking the original object space into clip coords, then using 
this in the mouse clip coords to object space multiplication.

Hopefully this makes sense.  It's a bit of advance topic as it requires 
understanding how matrices are used in the scenegraph/3D graphics.

-- 
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/27951025-2b7f-451e-ab1f-197771929a93%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] How to use the osgUI

[Robert Osfield]

The osgUI NodeKit was written to be used from C++ and/or Lua script.  
During development the primary focus was on making sure it was functional 
via Lua script and as part of Present3D presentations (see 
OpenSceneGraph/applicaton/present3D).

Due to the focus on Lua script usage I didn't write any C++ examples, 
instead it was all done via Lua scripts.  There a couple of Lua scripts in 
the OpenSceneGraph-Data/ui directory that illustrate it in action.  For 
example try:

 osgviewer ~/Data/OpenSceneGraph-Data/ui/TabWidget.lua.90,0,0.rot 

Note the 90,0.0.rot uses a psuedo plugin to rotate the widget that is on 
the XY plane by default to the XZ plane to fit with the OSG default viewing 
orientation (X to the east/right, Y north/forward, Z up).

The project that funded this work, after the end of the project I haven't 
had time have time to further develop.

-- 
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/aa0f73fb-fbc9-48a7-bb80-b93cac8d0da2%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] camera functionality issue

[ShoutMe]

I am trying to create a camera functionality that pans the camera side by 
side but when it reaches the bounds of geometry we shouldn't be able to pan 
camera anymore. The functionality also includes zoom in and zoom out

-- 
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/302ea41c-7165-4eff-b7a9-cd5f2940a434%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] OpenSceneGraph-3.6.5 release candidate 2 tagged, please test

[Robert Osfield]

Hi All,

I have just tagged the OpenSceneGraph-3.6.5-rc2:


https://github.com/openscenegraph/OpenSceneGraph/tree/OpenSceneGraph-3.6.5-rc2

Please test across as many platforms and applications as you have 
available, and report success or failures here on this thread so we can 
track convergence.  All going well we'll be able to make the 3.6.5 stable 
release this week,

Thanks in advance for your help in testing/build and bug fixes :-)

Cheers,
Robert.

-- Changes since 3.6.5-rc1

Tue, 21 Jan 2020 09:43:08 +
Author : Robert Osfield
Removed stray space

Tue, 21 Jan 2020 09:32:57 +
Author : OpenSceneGraph git repository
Merge pull request #902 from mp3butcher/oqn3.6 OQN API convergence 

Tue, 21 Jan 2020 09:16:51 +
Author : OpenSceneGraph git repository
Merge pull request #903 from dedowsdi/renderstageAdd getPreRenderList, 
getPostRenderList to RenderStage.

Fri, 17 Jan 2020 18:47:49 +0800
Author : dedowsdi
Add getPreRenderList getPostRenderList to RenderStage.

Fri, 23 Aug 2019 09:59:54 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: make all usages of 'updateDefaultQueryGeometry' thread 
safe

Fri, 23 Aug 2019 09:46:02 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: fix resetting to default query geometryWhen the query 
geometry gets reset to its default then its
vertices have to be updated by the bounding box dimensions of
the current children of the OcclusionQueryNode.


Wed, 14 Aug 2019 11:27:40 +0200
Author : Daniel Trstenjak
OcclusionQueryNode: fix use case of user defined query geometryThe user 
defined query geometry handling has been broken in several ways.

The previous way of defining a query geometry was using the non const
`getQueryGeometry` method and overriding its members. But then
`OcclusionQueryNode` wasn't aware of the geometry change and couldn't
internally handle it correctly.

The `computeBound` method never considered a user defined query geometry and
always just overrode the vertices of the geometry.

The member `_validQueryGeometry` wasn't correctly set.

This change should fix all this issues by introducing a small backward
compatibility break. The non const `getQueryGeometry` method is removed
forcing the user to use the `setQueryGeometry` method. But then 
`OcclusionQueryNode`
is aware of the user defined query geometry and can handle it correctly.


Tue, 29 Jan 2019 14:40:16 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: reset the test result of the invalid geometryThere're 
cases that the occlusion test result has been retrieved
after the query geometry has been changed, it's the result of the
geometry before the change.


Tue, 29 Jan 2019 11:37:28 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: ensure a valid query geometryIf the query geometry is 
invalid then don't do any occlusion queries and
never traverse the subgraphs.


Fri, 25 Jan 2019 15:02:45 +0100
Author : Daniel Trstenjak
OcclusionQueryNode: ensure a consistent value for '_passed'

Sat, 26 Jan 2019 16:33:23 +
Author : Robert Osfield
Introduced a QueryGeometry::getQueryResult(const osg::Camera*) method as a 
more informative replacedment for QueryGeometry::getNumPixels().

Mon, 20 Jan 2020 10:37:12 +
Author : OpenSceneGraph git repository
Merge pull request #900 from dedowsdi/fix_particle_rotationFix particle 
rotation.

Fri, 17 Jan 2020 11:18:30 +0800
Author : dedowsdi
Fix particle rotation.

Fri, 17 Jan 2020 09:28:09 +
Author : Robert Osfield
Updated ChangeLog

Fri, 17 Jan 2020 09:07:58 +
Author : Robert Osfield
Moved setting of isftream locale to Model::readOBJ(..) and 
Model::readMTL(..).

Fri, 17 Jan 2020 08:54:52 +
Author : Robert Osfield
Added explict setting of local to classic to avoid local platform settings 
affecting parsing

-- 
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/f7e6d823-4e2c-45df-be32-c147aa7a193f%40googlegroups.com.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org