Re: [osg-users] GL Error vulnerability in OSG 3.4.0 (invalid enum)

[Robert Osfield]

Hi Rick,

If we need to protect the testing of certain features for certain drivers
then glVersion number probably isn't sufficient as we have GL and GLES
versions to consider.

Another thing we'd need to do is provide a fallback in case we don't set
the associated values.

BTW, what platform and GL versions are you seeing issus with?

Robert.

On 30 June 2016 at 16:34, Rick Irons  wrote:

> Hi,
>
>
>
> openscenegraph/src/osg/GLExtensions.cpp should probably be checking the
> OpenGL version prior to using the GL_MAX_3D_TEXTURE_SIZE and
> GL_MAX_ARRAY_TEXTURE_LAYERS_EXT enums (see change below).  Otherwise, such
> calls will generate GL errors when using older versions of OpenGL.  Any
> concerns with such a change?
>
>
>
> Thanks,
>
> Rick
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

[osg-users] GL Error vulnerability in OSG 3.4.0 (invalid enum)

[Rick Irons]

Hi,

openscenegraph/src/osg/GLExtensions.cpp should probably be checking the OpenGL 
version prior to using the GL_MAX_3D_TEXTURE_SIZE and 
GL_MAX_ARRAY_TEXTURE_LAYERS_EXT enums (see change below).  Otherwise, such 
calls will generate GL errors when using older versions of OpenGL.  Any 
concerns with such a change?

Thanks,
Rick
[cid:image001.png@01D1D2C2.771617C0]
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Sebastian Messerschmidt]

Hi Robert, Phillip

Hi Phillip,

On 30 June 2016 at 12:22, Philipp Meyer  wrote:

unfortunately some objects move in my scene, so its not enough to only hold the 
old view matrix.

The camera AND any object can move.

OK.

You haven't ever said what you are trying to do with current vs
previous frame data.  I don't recall anyone ask for this specific
requirement before.  The OSG community have been around quite a long
time now...  So you are either doing something very novel or a trying
to solve a common problem in a very awkward way.
That's not entirely correct. I asked for something like this some years 
ago to implement a per-object motion blur in a deferred pipeline.
Basically one would write per-fragment velocity vectors to a render 
target to later selectively blur in a post-processing step. The velocity 
vectors were based on the change in the view-matrix + the changes per 
object.
I remember experimenting with callbacks and holding the last 
model-matrix in the objects user-data which was used to fill an uniform 
each frame, but I ultimately switched to a solution which didn't 
consider the blur on a per-object base.
So basically there are use-cases, but I never found a satisfactory 
solution (I think the problem was performance, due to the many uniform 
updates/statesets).
May be there is a more advanced solution to the problem that haven't 
thought of.


Cheers
Sebastian


One thing to also considering in your pondering is that not all
objects will actually be in the view frustum over subsequent frames,
especially as you pan around, new objects will appear in the view
frustum for the first time so won't have a previous modelview matrix
associated with them.

Since you haven't said what this is all in aid of I can't say whether
this later issue has any baring, it will however, if you really need
to do what you say you need to do will introduce it's own set of
issues.


Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Robert Osfield]

Hi Phillip,

On 30 June 2016 at 12:22, Philipp Meyer  wrote:
> unfortunately some objects move in my scene, so its not enough to only hold 
> the old view matrix.
>
> The camera AND any object can move.

OK.

You haven't ever said what you are trying to do with current vs
previous frame data.  I don't recall anyone ask for this specific
requirement before.  The OSG community have been around quite a long
time now...  So you are either doing something very novel or a trying
to solve a common problem in a very awkward way.

One thing to also considering in your pondering is that not all
objects will actually be in the view frustum over subsequent frames,
especially as you pan around, new objects will appear in the view
frustum for the first time so won't have a previous modelview matrix
associated with them.

Since you haven't said what this is all in aid of I can't say whether
this later issue has any baring, it will however, if you really need
to do what you say you need to do will introduce it's own set of
issues.


Robert.
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Julien Valentin]

As you doesn't answer the my post I assume you're using the mailing list
so you may haven't seen my updates and I'm curious to know if it would work lik 
this:
clas mycull : public  Callback{
public:
Matrif modelview;
virtual void  run(Node,Cullvisitor ){

cv->traverse(node)
modelview=cv->getModelViewCullingStack().back()
}
};

yournode->setCullCallBack(new mycull())

and in your update callback static_cast 
(yournode->getCullCallBack())->_modelview


mille25 wrote:
> Hi Robert,
> 
> unfortunately some objects move in my scene, so its not enough to only hold 
> the old view matrix.
> 
> The camera AND any object can move.


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67933#67933





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Philipp Meyer]

Hi Robert,

unfortunately some objects move in my scene, so its not enough to only hold the 
old view matrix.

The camera AND any object can move.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67932#67932





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Robert Osfield]

Hi Philip,

In your scene graph are there dynamic transforms or is it just the
changes in the camera's view matrix that is altering the accumulated
modelview matrix?

Robert.

On 30 June 2016 at 09:44, Philipp Meyer  wrote:
> My goal is to create a fragment shader that computes the delta distance to 
> each fragment compared to the previous frame.
>
> In the shader, I can easily calculate the current distance to a fragment by 
> using built in functions, the problem is that I also need access to the 
> fragment position in the PREVIOUS frame in order to compute the delta and 
> generate the output.
>
> As the vertex and fragment shaders have no native access to data of the 
> previous frame my idea was to use uniform variables to pass the viewMatrix 
> and the modelMatrix of the PREVIOUS frame to the vertex shader.
>
> I can easily retrieve old viewMatrix by setting a uniform variable in the 
> program main render loop after the current frame completed.
> However, it is very difficult to obtain the old modelMatrix because the 
> modelMatrix is unique to every primitive in the scene (or in other words, 
> there are many modelView matrices and not just one).
>
> So, the only solution I found was to attach a uniform to every transform node 
> in my scene graph and store the previous modelMatrix in it.
> This is very CPU intensive but works okay, unfortunately I do not yet take 
> Billboards into account and this is why I need to calculate the modelMatrix 
> of a Billboard.
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67926#67926
>
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Julien Valentin]

Hi mille
ok I understand better why rtt doesn't fit your use.
As Robert says before you should read back the modelview accumulated by the 
cull pass ..
so 2 solutions:
-either you'll have to override traverse() method on all nodes
-either you'll have setup your own CullVisitor managing your scenegraph



mille25 wrote:
> Hi,
> 
> that was my first idea as well, however, then I realized that this approach 
> does not work.
> 
> The problem is that there is no way to know if a certain pixel still shows 
> the same fragment. For example, if the camera view angle changes by 180 
> degrees in one frame, the pixel at the 0,0 texture coordinate would no longer 
> refer to the same fragment. Therefore, the program would compute the delta 
> between two unrelated fragments, yielding a wrong result.
> 
> However, with my approach, the program would calculate the old fragment 
> position by using the old view matrix (pre 180 degree change) and the model 
> matrix (unchanged in this example), compute the distance to the camera and 
> compare it to the old distance, resulting in 0. 
> 
> Or another example: Imagine the camera looking at the ground (perfectly 
> planar surface) at a 45 degree angle and moving forward every frame. If I 
> only compared the pixel values of the output texture, every point on the 
> ground would yield a 0 delta distance, because the new fragment is just as 
> close to the camera as the old fragment. However, with my approach, each 
> fragment would show a negative delta distance, because they moved towards the 
> camera.
> 
> Thank you!
> 
> Cheers,
> Philipp


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67930#67930





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Philipp Meyer]

Hi,

that was my first idea as well, however, then I realized that this approach 
does not work.

The problem is that there is no way to know if a certain pixel still shows the 
same fragment. For example, if the camera view angle changes by 180 degrees in 
one frame, the pixel at the 0,0 texture coordinate would no longer refer to the 
same fragment. Therefore, the program would compute the delta between two 
unrelated fragments, yielding a wrong result.

However, with my approach, the program would calculate the old fragment 
position by using the old view matrix (pre 180 degree change) and the model 
matrix (unchanged in this example), compute the distance to the camera and 
compare it to the old distance, resulting in 0. 

Thank you!

Cheers,
Philipp

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67929#67929





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Virtual base initialization issues

[Stuart Mentzer]

  
  
Hi Robert,
That is surprising and unfortunate -- in this instance VC++ is
  actually correct. If you know which compilers gave contradictory
  warnings I might be able to see if that has now been corrected. In
  any event, it seems better to have correct code give erroneous
  warnings than incorrect code that gives correct warnings.
I think there 2+ classes which aren't properly initializing the
  virtual bases, at least on compilers that handle virtual bases
  correctly. So there may be actual bugs, not just warnings. I am
  willing to pursue this if you would like me to.

Stuart
--
  
Stuart G Mentzer
Objexx Engineering
Office  1.781.455.1150 x11
Mobile 1.781.708.3872

  
On 6/30/2016 4:29 AM, Robert Osfield
  wrote:


  Hi Stuart,

This warning is a bit of pain.  Fix this warning and you generate a
warning with other compilers depending upon which compiler and warning
options enabled.  We had a discussion and attempted to fix some of
these warnings in the last dev release cycle.

Robert.

On 30 June 2016 at 06:08, Stuart Mentzer  wrote:

  
Hello,

Visual C++ 2015 finds a problem (in current master) with the initialization
of virtual base classes in the constructors of the hierarchies including
Object, Callback, NodeCallback, GUIEventHandler, EventHandler,
CameraManipulator, StandardManipulator, and AnimationManagerBase.
Constructors are attempting to initialize virtual bases Object and Callback
from classes that are not the most-derived, concrete class so those
initializations are being ignored. It doesn't help (or look right) that
multiple levels in the hierarchy attempt (and fail) to initialize these
virtual bases.

An example of the reported warnings is:
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning
C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
initializer for virtual base class 'osg::Object'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note:
virtual base classes are only initialized by the most-derived type
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): warning
C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
initializer for virtual base class 'osg::Callback'
C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): note:
virtual base classes are only initialized by the most-derived type

In some cases I see the most-derived classes also do the (correct) virtual
base initialization but it looks like at least these 2 are missing it:
BasicAnimationManager::BasicAnimationManager(const AnimationManagerBase& b,
const osg::CopyOp& copyop)
TimelineAnimationManager::TimelineAnimationManager(const
TimelineAnimationManager& nc,const osg::CopyOp& co)

I don't know enough of the internals to say if this could be causing
problems in practice but it would be good to fix this usage. I'm willing to
take a shot at it if that would be helpful.

Stuart


___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org


  
  ___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org



  

___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Julien Valentin]

Hi Milles25
If I understand you correctly you want to compute differences between fragment 
props. Your approach seams very CPU intensive and GPU redondant (you compute 2 
times interpolants of your VS out attrib).
You should use pingpong Render2Texture in order to store previous frame 
fragment props and then access it throught texture sampling in the current 
frame.
It would be a lot more efficient.

attach tex1 to main camera
sample tex2 in your FS
swap(tex1,tex2)



mille25 wrote:
> My goal is to create a fragment shader that computes the delta distance to 
> each fragment compared to the previous frame.
> 
> In the shader, I can easily calculate the current distance to a fragment by 
> using built in functions, the problem is that I also need access to the 
> fragment position in the PREVIOUS frame in order to compute the delta and 
> generate the output.
> 
> As the vertex and fragment shaders have no native access to data of the 
> previous frame my idea was to use uniform variables to pass the viewMatrix 
> and the modelMatrix of the PREVIOUS frame to the vertex shader. Then I could 
> simply compute the old vertex position and pass it as varying variable to the 
> fragment shader.
> 
> I can easily retrieve old viewMatrix by setting a uniform variable in the 
> program main render loop after the current frame completed.
> However, it is very difficult to obtain the old modelMatrix because the 
> modelMatrix is unique to every primitive in the scene (or in other words, 
> there are many modelView matrices and not just one).
> 
> So, the only solution I found was to attach a uniform to every transform node 
> in my scene graph and store the previous modelMatrix in it. (Calculate the 
> total modelMatrix by multiplying all parent matrix transforms on the CPU)
> This is very CPU intensive but works okay, unfortunately I do not yet take 
> Billboards into account and this is why I need to calculate the modelMatrix 
> of a Billboard.


--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67927#67927





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Get current Billboard ModelView matrix?

[Philipp Meyer]

My goal is to create a fragment shader that computes the delta distance to each 
fragment compared to the previous frame.

In the shader, I can easily calculate the current distance to a fragment by 
using built in functions, the problem is that I also need access to the 
fragment position in the PREVIOUS frame in order to compute the delta and 
generate the output.

As the vertex and fragment shaders have no native access to data of the 
previous frame my idea was to use uniform variables to pass the viewMatrix and 
the modelMatrix of the PREVIOUS frame to the vertex shader.

I can easily retrieve old viewMatrix by setting a uniform variable in the 
program main render loop after the current frame completed.
However, it is very difficult to obtain the old modelMatrix because the 
modelMatrix is unique to every primitive in the scene (or in other words, there 
are many modelView matrices and not just one).

So, the only solution I found was to attach a uniform to every transform node 
in my scene graph and store the previous modelMatrix in it.
This is very CPU intensive but works okay, unfortunately I do not yet take 
Billboards into account and this is why I need to calculate the modelMatrix of 
a Billboard.

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67926#67926





___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Virtual base initialization issues

[Robert Osfield]

Hi Stuart,

This warning is a bit of pain.  Fix this warning and you generate a
warning with other compilers depending upon which compiler and warning
options enabled.  We had a discussion and attempted to fix some of
these warnings in the last dev release cycle.

Robert.

On 30 June 2016 at 06:08, Stuart Mentzer  wrote:
> Hello,
>
> Visual C++ 2015 finds a problem (in current master) with the initialization
> of virtual base classes in the constructors of the hierarchies including
> Object, Callback, NodeCallback, GUIEventHandler, EventHandler,
> CameraManipulator, StandardManipulator, and AnimationManagerBase.
> Constructors are attempting to initialize virtual bases Object and Callback
> from classes that are not the most-derived, concrete class so those
> initializations are being ignored. It doesn't help (or look right) that
> multiple levels in the hierarchy attempt (and fail) to initialize these
> virtual bases.
>
> An example of the reported warnings is:
> C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): warning
> C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
> initializer for virtual base class 'osg::Object'
> C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(24): note:
> virtual base classes are only initialized by the most-derived type
> C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): warning
> C4589: Constructor of abstract class 'osgGA::CameraManipulator' ignores
> initializer for virtual base class 'osg::Callback'
> C:\Projects\OSG\OpenSceneGraph\src\osgGA\CameraManipulator.cpp(25): note:
> virtual base classes are only initialized by the most-derived type
>
> In some cases I see the most-derived classes also do the (correct) virtual
> base initialization but it looks like at least these 2 are missing it:
> BasicAnimationManager::BasicAnimationManager(const AnimationManagerBase& b,
> const osg::CopyOp& copyop)
> TimelineAnimationManager::TimelineAnimationManager(const
> TimelineAnimationManager& nc,const osg::CopyOp& co)
>
> I don't know enough of the internals to say if this could be causing
> problems in practice but it would be good to fix this usage. I'm willing to
> take a shot at it if that would be helpful.
>
> Stuart
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Odd Text Distortion (Which Does Not Appear to Be Due to the 3.2 Bugfix)

[Robert Osfield]

Hi Sammy,

It's not entirely clear what the specific issue might be from your
description, it sounds like it's simply that the wrong font is being
used, from the the look of the picture it looks like the fallback
built in font is being used.  This would normally only happen if you
don't have the freetype plugin built.

Check if the freetype plugin has been built and being loaded at runtime.

Another quick check is to run osgviewer with a simply model and then
enable stats by pressing 's'. This will bring up text on screen, if
it's blocky then the OSG isn't loading freetype fonts most likely due
to lack of feetype plugin being built.

Robert.

On 29 June 2016 at 23:53, Sam Jones  wrote:
> Hi,
>
> I have been having an issue with the display of text for a few days now 
> (where the correct font is not used), while updating a project from pre-3.0 
> OSG to the latest version.
>
> I know about this bug fix from 3.2 where, now, creating a camera and 
> assigning it to the viewer without initialising it properly or setting it to 
> global defaults will give you exactly what you're asking for. It seems that 
> past posters have had problems with text rendering in a blocky or unusual 
> way, and have traced it to this bugfix, however, I have not found this 
> project to have any improperly initialised cameras.
>
> Does anyone have any suggestions?
>
> (I have attached an image).
>
> Thank you!
>
> Cheers,
> Sammy J
>
> (I should mention, this is on a Win7 machine, building a project in Win32 
> Release mode; I have made sure that I am using the correct, non-debug dlls)
>
> --
> Read this topic online here:
> http://forum.openscenegraph.org/viewtopic.php?p=67921#67921
>
>
>
>
> ___
> osg-users mailing list
> osg-users@lists.openscenegraph.org
> http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
>
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org

Re: [osg-users] Odd Text Distortion (Which Does Not Appear to Be Due to the 3.2 Bugfix)

[Sam Jones]

Hi,

I have been having an issue with the display of text for a few days now (where 
the correct font is not used), while updating a project from pre-3.0 OSG to the 
latest version. 

I know about this bug fix from 3.2 where, now, creating a camera and assigning 
it to the viewer without initialising it properly or setting it to global 
defaults will give you exactly what you're asking for. It seems that past 
posters have had problems with text rendering in a blocky or unusual way, and 
have traced it to this bugfix, however, I have not found this project to have 
any improperly initialised cameras. 

Does anyone have any suggestions?

(I have attached an image).

Thank you!

Cheers,
Sammy J

(I should mention, this is on a Win7 machine, building a project in Win32 
Release mode; I have made sure that I am using the correct, non-debug dlls)

--
Read this topic online here:
http://forum.openscenegraph.org/viewtopic.php?p=67921#67921



___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org