Re: [osg-users] Getting the main camera.

[Robert Osfield]

Hi Marlin,

On 2 May 2018 at 18:05, Rowley, Marlin R  wrote:

> Is there a way to get a pointer to the main rendering camera without
> passing the Viewer around through classes and functions?
>

In the draw traversal the main two objects that are passed around are
osg::RenderInfo and osg::State.  The osg::RenderInfo has high level info
such as what is the current View being rendered and what the current Camera
is.


https://github.com/openscenegraph/OpenSceneGraph/blob/master/include/osg/RenderInfo

The RenderInfo is passed to drawables during the draw traversal via:

  osg::Drawable::drawImplementation(osg::RenderInfo&)

The CullVisitor also has a handle to the RenderInfo as well as various
other useful state info:


https://github.com/openscenegraph/OpenSceneGraph/blob/master/include/osgUtil/CullVisitor

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

Re: [osg-users] Getting the main camera.

[Rowley, Marlin R]

Here is a more informed email of what I'm trying to accomplish:

We have some old code that inherits from the ShadowMapTechnique to do most of 
it's work which is based on the fixed-function pipeline.  It uses the shadow 
map's camera for projection of textures (among other things) and we are 
redesigning it so that the base class is independent of the shadow map class.  
I thought I had everything working when I gutted out this function in the 
ViewData override function called addShadowReceivingTexGen():

_texgen->setMode(osg::TexGen::EYE_LINEAR);

// compute the matrix which takes a vertex from view coords into tex coords
_texgen->setPlanesFromMatrix(
  mClampCallback->getLastProjection() *
  osg::Matrix::translate(1.0, 1.0, 1.0) *
  osg::Matrix::scale(0.5f, 0.5f, 0.5f));

osg::RefMatrix * refMatrix = new osg::RefMatrix
  (_camera->getInverseViewMatrix() * *_cv->getModelViewMatrix());

_cv->getRenderStage()->getPositionalStateContainer()->
  addPositionedTextureAttribute
  (*_shadowTextureUnitPtr, refMatrix, _texgen.get());

This is evidently stored in OpenGL's built-in variables because it's used in 
the vertex shader like this:

{
gl_TexCoord[1].s = dot(ecPosition, gl_EyePlaneS[1]);
gl_TexCoord[1].t = dot(ecPosition, gl_EyePlaneT[1]);
gl_TexCoord[1].p = dot(ecPosition, gl_EyePlaneR[1]);
gl_TexCoord[1].q = dot(ecPosition, gl_EyePlaneQ[1]);
}

My new solution for the addShadowReceivingTexGen() is a simple 
updateTextureCoordinates() function:

mTexGenMatrix = mCamera->getViewMatrix() *mCamera->getProjectionMatrix() * 
osg::Matrixd::translate(osg::Vec3d(1.0, 1.0, 1.0)) *
osg::Matrixd::scale(0.5, 0.5, 0.5);

And in the new vertex shader, I do this:

TexCoords[0] = TexGenMatrix0 * gl_Vertex;

Which goes from modelspace all the way to clip space.  This works on simple 
objects created at the origin in modelspace, but it does NOT work with an 
entire world with large terrain.

I'd like to continue NOT using the gl_EyePlaneSTRQ and just doing a regular 
transformation.  However, going back to the old code for any clues is leading 
me nowhere.  I traced the 'addPositionedTextureAttribute' to this:

virtual void addPositionedTextureAttribute(unsigned int textureUnit, 
osg::RefMatrix* matrix,const osg::StateAttribute* attr)
{
_texAttrListMap[textureUnit].push_back(AttrMatrixPair(attr,matrix));
}

.. but I'm not sure what it's doing here.  The attr is the texgen object but 
that's used to store a matrix.  So what does the vertex shader 'see' from this 
function?

I apologize for the long and drawn out email but I've been thinking on this for 
a few hours now and am really new to OpenGL and not sure what some of this code 
is trying to do.

Thanks,

-M


Marlin Rowley
Software Engineer, Staff
[cid:image002.jpg@01D39374.DEC5A2E0]
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin.r.row...@lmco.com

From: osg-users [mailto:osg-users-boun...@lists.openscenegraph.org] On Behalf 
Of Rowley, Marlin R (US)
Sent: Wednesday, May 2, 2018 12:05 PM
To: OpenSceneGraph Users 
Subject: EXTERNAL: [osg-users] Getting the main camera.

Is there a way to get a pointer to the main rendering camera without passing 
the Viewer around through classes and functions?

Thanks,

-M


Marlin Rowley
Software Engineer, Staff
[cid:image002.jpg@01D39374.DEC5A2E0]
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin.r.row...@lmco.com

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

[osg-users] Getting the main camera.

[Rowley, Marlin R]

Is there a way to get a pointer to the main rendering camera without passing 
the Viewer around through classes and functions?

Thanks,

-M


Marlin Rowley
Software Engineer, Staff
[cid:image002.jpg@01D39374.DEC5A2E0]
Missiles and Fire Control
972-603-1931 (office)
214-926-0622 (mobile)
marlin.r.row...@lmco.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.1 release candidate 2 tagged

[Robert Osfield]

Hi All,

I have tagged the second 3.6.1 release candidate.

I have merged a PR that removed so un-implemented functions in
osgParticle, this technically changes the ABI for osgParticle so I've
bumped the SO version for 3.6.1-rc2.  The rest of the changes are
fixes.

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

I'm ready to tag 3.6.1, all need from the community is testing and
feedback on whether things are working on all the main platforms.  Let
us know of success or failures here on this thread.

Cheers,
Robert.

-- ChangeLog since 3.6.0

Wed, 2 May 2018 09:10:54 +0100
Author : Robert Osfield
Updates for the 3.6.1-rc2

Mon, 30 Apr 2018 11:55:17 +0100
Author : Robert Osfield
Updated SO version to reflect change in ABI

Mon, 30 Apr 2018 11:44:02 +0100
Author : OpenSceneGraph git repository
Merge pull request #542 from psyinf/fix_particle_system_headerFIX:
 removed unimplemented functions from header

Mon, 30 Apr 2018 11:16:02 +0200
Author : Sebastian Messerschmidt
FIX:  removed unimplemented functions from header

Fri, 27 Apr 2018 11:23:07 +0100
Author : Robert Osfield
Fixed particle update bug where a ParticleSystem wouldn't start when
loaded during the frame loop due to the _last_frame value not being
set.

Thu, 26 Apr 2018 10:21:53 +0100
Author : Robert Osfield
Updated ChangeLog, README.md and rc number for 3.6.1-rc1

Thu, 26 Apr 2018 09:49:35 +0100
Author : Robert Osfield
Split up #pragma so that there only three parameters per line to aovid
Intel driver bug crash

Thu, 26 Apr 2018 09:36:52 +0100
Author : Robert Osfield
Renamed text.vert and text.frag to osgText_Text.vert and .frag to
avoid name overlapping with user shaders.

Wed, 25 Apr 2018 09:48:02 +0100
Author : Julien Valentin
add wrapper for osg::DrawIndirectBufferObject

Tue, 24 Apr 2018 17:05:03 +0100
Author : Robert Osfield
Renamed CMake variable + C++ #define to OSG_GL_CONTEXT_VERSION

Tue, 24 Apr 2018 16:22:13 +0100
Author : Robert Osfield
Added OSG_GL_CONTEXT_STRING cmake variable to set include/osg/GL
headers that sets Traits::glContextVersion.

Tue, 24 Apr 2018 15:38:02 +0100
Author : OpenSceneGraph git repository
Merge pull request #537 from
openscenegraph/revert-536-default-gl3-contextRevert "When GL3 build is
enabled, default context requested is version 3.3, …"

Tue, 24 Apr 2018 15:37:44 +0100
Author : OpenSceneGraph git repository
Revert "When GL3 build is enabled, default context requested is version 3.3, …"

Tue, 24 Apr 2018 15:36:11 +0100
Author : OpenSceneGraph git repository
Merge pull request #536 from emminizer/default-gl3-contextWhen GL3
build is enabled, default context requested is version 3.3, …

Tue, 24 Apr 2018 15:33:03 +0100
Author : Robert Osfield
Refactored the handling of glyph and shadow alpha values to make the
text and shadow clearer for fonts with narrow glyphs

Tue, 24 Apr 2018 13:52:53 +0100
Author : Robert Osfield
Refactored the handling of text bounding box to provide more stable
bounding box computation

Tue, 24 Apr 2018 06:31:32 -0400
Author : Daniel Emminizer
When GL3 build is enabled, default context requested is version 3.3,
enabling core profile by default.

Fri, 20 Apr 2018 21:16:46 +0200
Author : Alberto Luaces
Small fix for uncaught typo.

Fri, 20 Apr 2018 18:18:22 +0200
Author : Alberto Luaces
Fix typos and spelling.

Mon, 23 Apr 2018 11:02:03 +0100
Author : OpenSceneGraph git repository
Merge pull request #534 from emminizer/fix-msvc-includesFix includes
for MSVC 2015 build.

Fri, 20 Apr 2018 13:16:43 -0400
Author : Daniel Emminizer
Fix includes for MSVC 2015 build.

Fri, 20 Apr 2018 15:58:27 +0100
Author : Robert Osfield
Updated ChangeLog

Fri, 20 Apr 2018 14:32:34 +0100
Author : Robert Osfield
Replaced osgUtil::IntersectVisitor usage with osgUtil::InteresectionVisitor

Fri, 20 Apr 2018 10:24:17 +0100
Author : Robert Osfield
Removed TriStripVisitor for default set of Optimizer passes as it
doesn't generate efficient scene graphs

Fri, 20 Apr 2018 09:57:04 +0100
Author : Robert Osfield
Added osgUtil::optimizeMesh(osg::Node* node) convinience method

Fri, 20 Apr 2018 11:42:31 +0100
Author : Robert Osfield
Removed usage of the osgUtil::TriStripVisitor is it generates
osg::Geometry that perform very poorly when using VBO and VAO's vs GL
DisplayLists. With DisplayLists being deprecated in GL and VBO and VAO
becoming standard it's best to standardize on using the
osgUtil::MeshOptimizers instead of TripStrupVisitor

Thu, 19 Apr 2018 19:43:14 +0100
Author : Robert Osfield
Fixed the set*Binding() methods so that they assign BufferObjects when required

Thu, 19 Apr 2018 19:42:51 +0100
Author : Robert Osfield
Fixed messages

Thu, 19 Apr 2018 19:41:51 +0100
Author : Robert Osfield
Fixed the GLBufferObject size computation so that it takes into account padding.

Thu, 19 Apr 2018 19:36:19 +0100
Author : Robert Osfield
Replaced the use of osgUtil::TriStripVisitor with
ogUtil::MeshOptimizer usage to improve performance. Fixed set
setColorArray assignement to pass in the 

Re: [osg-users] (no subject)

[Robert Osfield]

Hi Oran,

When optimizing OSG applications most of the task is really about
optimizing the scene graph to address bottlenecks.  You've taken the
first step in look at high level cull, draw dispatch (the OSG's draw
traversal dispatch data into the OpenGL FIFO) and draw GPU stats, and
listing the various scene graph stats that cause the performance
issues.

The next step is working out how to address the performance issues,
the first step in this is to look at which element of the frame is
longest and start there as this is likely the most fruitful place to
achieve gains.  In your case I expect each of the high cull, draw
dispatch and draw GPU are all linked to how fine grained the scene
graph is set up - you have large number of scene graph level objects
relative to the number vertices and primitives being dispatched.

The most effective way to improve performance will be merge
osg::Geometry and with it simplify the scene graph structure above it.
You can only merge osg::Geometry that share the same state so this may
require some adjustment to how you manage the state of objects.
Moving state changes from osg::StateSet's/osg::Material into the
osg::Geometry as per vertex data/per PrimitiveSet data may the be the
solution, it might be that shaders might be need to help with this.

For picking, if you merge a large number of osg::Geometry then CPU
based intersection testing may end up being slower, to resolve this
you can build osg::KdTree for the osg::Geometry and then the
IntersectionVisitor will be able to use the KdTree to speed up
intersection.

If you want to pick patches then you may want to keep each patch in
it's own osg::PrimitiveSet rather than merging these.   However,
merging osg::PrimitiveSet is something that will help performance,
just like merging osg::Geometry will do.  For modern graphics hardware
it's typically best to just use a single osg::DrawElementsUShort/UInt
with GL_TRIANGLES mode for all the triangles in an osg::Geometry
rather than using triangle strips.  So if you are wanting to pick and
edit patches that you once managed at the osg::Geometry level, then
you could merge all the triangles in the original osg::Geometry into a
single osg::DrawElementUShort/UInt and then merge the osg::Geometry
data whilst not further merging any of the primitives sets.

The osgUtil::Optimizer class has a collected of visitors that can help
with merging state and geometries, and the osgUtil::MeshOptimizers can
also help with generating efficient meshes.

Robert


On 2 May 2018 at 01:31, Oran Wallace  wrote:
>
> Hi All,
>
> Been using OSG for a while and have learned a lot and enjoyed it. I
> currently have an application with uses OSG and Qt for displaying a highly
> detailed model. A database is loaded which may cause colors in the model to
> change or additional geometries to be generated.
>
> My OSG viewport is a class which subclasses from QWidget and
> osgViewer::CompisiteViewer and is embedded into a QMainWindow. This works
> fine so I've stuck with it. The application can perform most CAD-like
> operations on the model with OSG.
>
> I've finally encountered a model which brings my application to around 1-2
> fps while interacting with it. I know there are various techniques used to
> help with performance but also understand the approach depends on the
> situation. I'm currently considering a major rewrite.
>
> Scene Details:
> 1. 540k vertices
> 2. 81000 drawables
> 3. 77000 sorted drawables
> 4. 81000 fast drawables
> 5. 81000 primitive sets
> 6. 10 triangles
> 7. 37000 quad
> 8. 181000 polygon ( probably hurting a lot)
> 9. 26000 unique state sets
> 10. 73000 instance state sets
> 11. 28000 groups
>
> Cull: 113.50, Draw: 390, GPU: 355 (never seen values this high on the
> forums)
> Additionally the graph doesn't seem to rendering correctly; the largest
> "bar" is Cull and last ~10% is the Draw, which doesnt seem to match the
> values. (Probably because a single frame takes so long?)
>
> Implementation Details:
> 1. I am orthographic project as it is a "CAD" style application.
> 2. Currently all objects are within Geode->Geometry nodes, each with
> their own vertex, color, and normal arrays.
> 3. The main "mode" of the application is a "ghosted" mode which is
> applied to the walls of the model. Each wall has an osg::Material set to it
> and blending turned on.
> 4. All objects are pickable and hold a variety of property data
> (extracted from the models file or the database). I have implemented
> "picking" using the PickHandler::pick example and code.
> 5. A user often views the whole model from afar interacting with other
> Qt widgets and watch how the scene changes, occasionally they will zoom in
> on a section but are never "inside" the model. I can clearly see when view
> frustum culling is working when zooming in.
> 6. My graph is VERY flat. Nearly all object are attached to the root