OpenSceneGraph Forum Forum Index OpenSceneGraph Forum
Official forum which mirrors the existent OSG mailing lists. Messages posted here are forwarded to the mailing list and vice versa.
 
   FAQFAQ    SearchSearch    MemberlistMemberlist    RulesRules    UsergroupsUsergroups    RegisterRegister 
 Mail2Forum SettingsMail2Forum Settings  ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 
   AlbumAlbum  OpenSceneGraph IRC ChatOpenSceneGraph IRC Chat   SmartFeedSmartFeed 

(no subject)


 
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General
View previous topic :: View next topic  
Author Message

Guest





PostPosted: Thu Mar 08, 2018 3:16 am    Post subject:
(no subject)
Reply with quote

11

------------------
Post generated by Mail2Forum
Back to top
Oran Wallace
Guest





PostPosted: Wed May 02, 2018 12:32 am    Post subject:
(no subject)
Reply with quote

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. 100000 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 node (objects like cubes, cylinders, and meshes), when the rooms form a closed space I create a group node whos children are the walls. (I often rearranged it but never saw an performance changes from this)
7. Anything else you need to know...

Fairly certain my main problem is just the sheer number of draw calls the occur when my models get a decent amount (20,000+) objects. It seems a remedy for this is to combine drawables and share one vertex array (correct?). Would this totally break the picking code? This application is designed to run on computers with "buisness" level GPU (example GeForce GT 640) but sadly I have to use the nouveau drivers.

Sorry for being so long winded by wanted to clearly lay down the situation for anyone that feels like helping. Also thanks a lot to anyone willing to help me out!

~Oran

------------------
Post generated by Mail2Forum
Back to top
robertosfield
OSG Project Lead


Joined: 18 Mar 2009
Posts: 12132

PostPosted: Wed May 02, 2018 7:42 am    Post subject:
(no subject)
Reply with quote

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:
Quote:

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. 100000 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
node (objects like cubes, cylinders, and meshes), when the rooms form a
closed space I create a group node whos children are the walls. (I often
rearranged it but never saw an performance changes from this)
7. Anything else you need to know...

Fairly certain my main problem is just the sheer number of draw calls the
occur when my models get a decent amount (20,000+) objects. It seems a
remedy for this is to combine drawables and share one vertex array
(correct?). Would this totally break the picking code? This application is
designed to run on computers with "buisness" level GPU (example GeForce GT
640) but sadly I have to use the nouveau drivers.

Sorry for being so long winded by wanted to clearly lay down the situation
for anyone that feels like helping. Also thanks a lot to anyone willing to
help me out!

~Oran






------------------
Post generated by Mail2Forum
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    OpenSceneGraph Forum Forum Index -> General All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum

Similar Topics
Topic Author Forum Replies Posted
No new posts (no subject) Andre Normann Submission 2 Mon Nov 13, 2017 10:00 am View latest post
No new posts (no subject) tanshihaj General 0 Tue Sep 19, 2017 2:26 pm View latest post
No new posts (no subject) filnet Submission 0 Wed Jun 29, 2016 9:31 am View latest post
No new posts (no subject) grendah General 1 Sat Apr 23, 2016 1:45 pm View latest post
No new posts (no subject) andersb General 6 Thu Feb 04, 2016 9:10 am View latest post


Board Security Anti Bot Question MOD - phpBB MOD against Spam Bots
Powered by phpBB © 2001, 2005 phpBB Group
Protected by Anti-Spam ACP