So far I have spent the majority of my career building C4ISR solutions. I'm currently working to replace a proprietary tool with a new more modern an open solution. I am enjoying working with osg/osgearth but still am trying to understand the big picture. This is a bit of a change since i am used to working with a very domain specific API for manipulating the map scene.
It was trivial to programatically create the earth, add imagery/shapefiles etc. I am currently using objectplacer to put entities on the map. I need to display symbology (mil std 2525b, and custom dhs) along with the text label. Not to mention all the typical symbology that goes along with any c2 application. So in osgearth is your osgEarthSymbology classes planning to support or already support that type of action. Or do i need to build my own custom solution. I just want to make sure I am not going to reinvent the wheel if i don't have to. Just for clarification, we have our own symbolkit libs internally that handle taking sic codes and returning the symbol pixmap. So i am not asking if osgearth does that. I just want to know what the preferred design pattern is for adding, updating, deleting packaged entities.
From looking through the code it seems that if I were going to do this my self, i would create a custom node object. This is my first experience with osg in general so any suggestions on that approach.
As a defense contractor i get to work on and with a lot of very interesting things. Most of which will never be publicly available so its not always obvious how much your work is used and appreciated. So, thanks for all the work you guys have put into osgearth and releasing it as oss.
quick followup question. when working with thousands of concurrent entities on the map i want to update their position and symbol characteristic within our current frameworks event system. So i will receive an entity update message, and want to do a ninja strike update on that object. Would it be completely wrong when using a scene graph to keep an external QHash (I'm a hard core Qt developer) and keep pointers to the nodes based on an entity id key. Since i'm still learning i don't want to break the osg::ref_ptr system because of lack of experience on my part. But i haven't been able to find any examples where people have done anything like that.
You're right, symbolized entities is one of the most common things you find in a C2 application.
Originally we considered this outside the scope of osgEarth - it was originally designed to render just the globe. The features + symbology framework then evolved out of the need to render vector features atop the terrain. Its design is meant to support not only "draping" shapefiles and the like, but also to support future efforts at placing 3D models (like buildings) or extruding shapes or doing point-model substitution, much like the older osgGIS project does.
The symbology framework works for entity symbolization as well. In fact we're doing just that on some of our current contract work. Since C2 entity visualization is so common, we opted to start putting "helper" classes into the osgEarthUtil namespace to assist. There are relatively new - ObjectPlacer at first, and more recently the ObjectLocatorNode. There are no examples of their use just yet but that will come.
Your approach of maintaining a separate hashtable that points to nodes in the scene graph is fine. Just make sure you update nodes at a legal time (i.e. during OSG's update traversal) to avoid multi-threading issues.
A couple other topics..
One thing OSG lacks when you are simulating 1000's of objects is a dynamic spatial index. How do you organize your entity nodes in the scene graph for optimal culling when their positions are constantly changing? This is another problem we might address in osgEarthUtil in the form of a custom entity container.
Finally, symbology like 2525 supports levels of aggregation. For example you might want to see the icon for a platoon, and then upon zooming in, see the icons for the individual tanks. This type of agg/de-agg is something we also plan to build into the symbology framework down the road.
So...short answer yes, osgEarth aims to support the type of things you need to do; long answer, it is still a work in progress and we welcome any input you might have.
PS. We've doing a lot of work with Boeing in the past. I'd be happy to speak with you offline in more detail about the effort if you like.
Thank you for the thorough reply. It appears that for my IRAD work i'm going to have to not only learn OSG really fast, but implement some of the things you discussed. I think my "custom node" object is pretty much what you are referring to as a "custom entity container". So maybe some of my work will be reusable. I had not thought about the over all node organization yet. And thats an interesting point you made about the lack of a dynamic spatial index. I'll also check out the headers for ObjectLocatorNode too. The name alone seems to make it pretty obvious to what its function is. So far the hardest thing with OSG was building my own OSG Qt integration. I am not really satisfied with the examples they have so far. Maybe this is my typical developer ego talking but with my extensive Qt knowledge I believe I can make a beter solution.
It would seem I have a lot of work cut out for me.
I would definitely appreciate a quick conversation offline. I definitely have questions about over all capabilities and about some of your commercial solutions you built at Pelican.
I was wondering if you received an answer from Glenn about the best practice for doing a "ninja strike update" on thousands of objects. I will be doing something like that here in the near future so I'm interested in his answer also.