OpenFlightLoader

Still a work in progress. I had to port over SwitchNode & some variations of it for the LOD and Appearance switches(uses CullHint to control which nodes are visible), but its starting to get functional. Once complete I’ll hand over the loaders and supporting primitives for integration.



Flight models are very Node heavy, so I’m pretty sure thats impacting performance. I’ll have to hook-up the profiler to it to verify. The triangle&vertice counts don’t seem to reflect the CullHints. The model in view is only 3-4k polys.

Yay! When you start to put out “usable” versions send me a note, I will add it to the jMP contributions repo as an import plugin.

cool. Nice work



Yes I think you should try to merge some geometries, 1600 objects is a bit heavy for a model and surely impacts performances.

This is really promising!

keep up the good work :wink:

Hm, could you explain for the not involved what openflight models are?

@nehon

I can only merge certain geometries. The model includes all LoDs as individual nodes. Each damage state has its own switch node. Animations (usually lame billboarded fire/smoke animations) are a collection of nodes switched on and off in sequence. Models are usually separated out by their articulated parts:



[java]

-Hull node

-Hull switch node

-Normal node

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-Mobility Kill node

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-Mobility Firepower Kill node

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-Catastrophic Kill node

-Controllable LoD node

-0-250m node

-smoke animated switch node (1-30 unique meshes usually)

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-Turret node

-Turret switch

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-M2 switch

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

-M60 switch

-Controllable LoD node

-0-250m node

-more nodes and geometries

-250-500m node

-more nodes and geometries

-500-1000m node

-more nodes and geometries

-1000+ node

-more nodes and geometries

[/java]



I’d like to possibly give the RenderManager knowledge of the SwitchNode so I can just query it for active children instead of cycling thru all children only to hit CullHint.Always. I’m also considering adding code to re-organize the Tree to have damage state as the first Switch, followed by LOD and add ability to programatically replace some external references (The M1 model references smoke.flt as the common smoke animation for cat-kill) and/or node names with a different spatial (smoke/fire particle system) or remove them.



In jME 1.0 I was able to keep the frame-rate high by adding code to onDraw, updateWorldBound and updateGeometricState to limit which parts of the tree update and are attempted to draw.

Finally have working implementations of SwitchNode (extends node, displays 1 node at a time), masked switch node (extends switchnode, displays nodes according to a binary mask), and ControllableDistanceLODNode (extends switch node, can display multiple LODs). I also modified RenderManager.java to give it knowledge of SwitchNodes, so it can process only the active nodes for scene rendering, shadows, etc.



Here is a dump of the scene hierarchy for the tank model. At the bottom you’ll notice Nodes as leafnodes, those are external model references that are left out currently (usually the M2 .50cal has its own model, smoke, muzzle flash, etc. are also separate models). As you can see there is plenty of room for mesh compression at the node levels where there is geometry (FlightMesh extends Geometry btw). Currently I just have mesh compression turned off until I get everything working at the base level again in jME3. The primary issue is coming in from bounds/translation/light refresh flags on some of the nodes.



www.gravityresearch.us/m1a2.flt.txt

Uhm, shouldnt “SwitchNodes” just be LOD levels of one Geometry?

Not necessarily. The controllable LOD nodes could probably be converted over to multiple LOD geometries in some cases (1 LOD node would become multiple LOD geometries due to different meshes&textures). The SwitchNode itself is using to switch much higher level in the scene graph between the 5 visual states in this case: Normal, Mobility kill, firepower kill, mobility firepower kill, and catastrophic kill. It almost always has multiple geometies, models, etc. underneath of it. OpenFlight is not game optimized at all.

Okay, get it :slight_smile: Still as said, this massive node/geometry-ing is not very rendering friendly :frowning:

With the compression techniques I used in jME 1.0 the rendering wasn’t too bad – primary problem I had with jME1 were all of the different calls to setup gl textures. I had plenty of culling/bounding and update* methods overridden to prevent updating unnecessary portions of the large tree.