I like the Red Black trees - and their special behaviour about the O(log n).
Okay I guess there are other trees which may be faster, but these are already fast I think.
(When I remember corrtly, the RBT are a little bit uneven - thus not comptly optimized)
Hm. Why should you reinvent the wheel by coding a own graphic engine?
(Okay. It will be faster and much smaller than other engines - its custom made for your network visual.)
If you really need to reinvent it - you probably look at directX or even openGL - depends on
which platform(s) you want to release it.
But if you want to create fast and easy a visualation of it - you may think about open source
3D renderer like Irrlicht ( very easy, powerful ) or Ogre (extremly powerful - I use it:) ).
Irrlicht is good for 2D and 3D - its fast, easy and of course, open source.
Ogre is awesome and much better than Irrlicht - but its mostly for 3D applications.
I didnt use Panda or something else - I think that Ogre is one of the best open source
3D renderer which receives lots of updates - have tools and a great community.
Depends how detailed the graphics need to be - you could pick one of the options.
Hm. Offtopic I think.
I guess it wouldnt be so hard to create a visual from a tree which is completed -
just I said above, each node have a small space between athoer nodes - (leafes) and connections.
Maybe the hardest part of it will be add / removing of data in runtime.
But even that dont need a special physic library like PhysX I think - its only an algorithm which
moves the nodes / leafes so they dont touch each other.
But when you really want to use a phsyic engine for it (which makes atm no sense for me)
you should think about the huge amount of possible actors - when you create a node at a position from the root node - the actor of the new node (or entry) call every single time when he “moves” something like a AABB test - (overlap)… … and think about how much RAM you need for it …
Or another way you maybe archieve it: You store each position of your actors (which repesents nodes)
in a big list and iterates throu it - until you found a position which have enough room for your node.
Or using raycasts … .Omg :)
Another option: Waypoints I think. But … yeah… you know.
I dont want to say more about it. Maybe you get the point.
But if you reaaaally want to use a physically way… You should read more about navigation meshs - you
could feed your node as an obstacle - and the navigation mesh builder will build a new way around the
obstacle - in a few ms!!!
The grey spots could be a node - (Think about an “inifity” plane - you set each node / leafe as obstacle, and build the navmesh from it. On the blue polygons, you could add new nodes / leafes.
-> Or even moves with a character on the grey shapes. Without touching nodes of course.
But … Maybe this is good idea - or not. I really think that a few alogrithm could solve your problem.
( Of the positioning …)