@SunDawg - Really? Wow! Awesome! I hope the progress continues to entertain and you get try the demo when I have one! As for learning experience - Yes- it definately has been a learning experience. If you have been following the progress - you know I'm REWRITE #3!
Rewrite #3 Why? First Edition: DBPro to slow, Second Edition: DarkGDK Much faster - Got up to speed on C++ and learned enough to make a new design faster - (David W actually had a lot to do with pointing out to me that my dynamic Linked Lists might be hurting me more than I was aware - after research I realized he was on to something! It's not that my Dynamic Linked Lists are slow - they are fast as anything.. but slightly slower than arrays for FIRST-thru-LAST iterating (Which is what we do in games constantly) Multiply this slight increase in processing time * NUMEROUS dynamic Linked List Loops that iterate - and - well - that's prcessing I thought I could do without!
This convinced me to go to Dynamic Arrays - and for MOST game things - they are more ideal - as you fill them - and usually navigate via a loop counter not adding and removing all the time. Note: I Love my dynamic linked list classes - and they have their place - they've just been demoted for SPEED critical stuff where an array is more advantageous to keeping Frame Rates up! (Thanx David W!) Considering they were the CORE of my library - and the fact that I learned so much more about how I should set things up for a big project in C++ - how DarkGDK parts should ideally "work together" and various design considerations - I STARTED OVER AGAIN!
@David W - Thanx for that. I'm glad your project is going well too! As for keeping up the hard work - I will but aside from
I'm learning alot about various techniques to squeeze performance out of the system - and I still have a lot to learn with applying DarkPhysics to gameplay yet - but so far I have a workable system to make the sometimes "separate" physics meshs work seamlessly with the frustrum culling, object positioning etc. LOD etc.
Why I'm posting NOW is I wanted to share some findings that kinda shocked me in my Frustrum culling code. I - trying to keep things lean was surprised after adding TONS of CODE - things got faster! This didn't jive with my normal Logic! But here is what's up.
(I am about to Discuss STATIC OBJECTS and Related FIRST)
Frustrum Culling - Be It BOX (in frustrum or camera view) Check (slowest), Cube check (faster), Sphere Check (Fastest - least accurate for various model designs... like a rectangle building) Are WONDERFUL and ACCURATE - but SLOOOWWWW. However Not using these at all is MUCH WORSE as you're rendering stuff you shouldn't all the time - crippling you for any decent frame rates with anything that's a half way interesting scene (with any amount of models).
My first Strategy to cut down on processing was something called QUADTREE - which is a fancy word for seeing if a BIG BOX is in the Camera - then if it is - Checking if the SMALLER boxes inside are on the Screen - if so - ONLY THEN check objects individually.
Makes Sense right? It helped alot - but only to a certain point... Why? Well Once you have a "box of things" you now are frustrum checking each one in the box - On Screen? OffScreen? (via those slow frustrum checks) SO....
What have I done this time? I mixed in a system based on ideas of the quadtree (or the twice as complex - same idea "OctTree") solution and the portal occlusion strategies to arrive at something that seems to TOTALLY KICK .. BUTT!
Like Quad Tree - I have these invisible boxes - called "Regions" - but unlike Quadtree - I can place them anywhere I want. If I want to have a quadtree'ish setup - I can make a region, and put smaller regions inside it (Like a directory tree in windows explorer kinda)... This is how portal Occlusion kinda works - you have a hierarchy. So - this is great - to quickly tell you all the stuff you should be excluding/hiding and which areas you need to pay attention to.
But sometimes paying attention to these areas was still DOGGING me! Some areas (without more than a few models in them) Were BLAZINGLY FAST! While other more populated ones still sucked from a speed perspective. Hmmm...
After a ton of experiments and (keep in mind I was determined to have LOD (Level Of Details - or multiple models at differing resolutions for use when distance from camera makes sense - lower poly for far away stuff - high poly for up close) and the ability to have Physics Work for me REGARDLESS of whether my physics mesh object was the one you actually see OR NOT - I had a surprising end algorythm - for my static stuff - GROUPS!
A Group is like a region EXCEPT it follows a different culling strategy. Note - I can JAM 100 trees into a group in a small area and get awesome frame rates with it so keep reading!
Basically - A Group is a list of objects we do not process individually - and as the name suggests we process as a group - USUALLY! LOL.
A Group is like a region in tahe its an imaginary box. We Frustrum check that box. If Its
On Screen Now but not last frame or
off screen now but was onscreen last time then we frustrum check everything in the region (LOD Included) - however if our new state is ONSCREEN - We don't allow objects to be hidden - Same LOD - just force as if on screen. Now when a group goes out of frustrum - we similiarly force EVERYTHING OFF (Exclude/hide).
Now this is fine but LOD still takes awhile - especially with 80 trees in a small area. Well.. This is where I applied another trick that's used in systems like this - don't do them all at once. We have them onscreen? Ok - so let's lod them - maybe only a tree per loop - or maybe 5 per loop (My default).. Maybe 2 every two loops? All I know is this added a lot of code - "Regions, Groups, Objects for actual culling, flexible - you can make the system as simple or complex as you want - etc... ALL ADDED TONS of code - but everything runs faster now! The burder is on SMART "Arrangment" of the Cull "Directories" and setting up the Regions and groups in such a way that the speed benefits can be utilized. This means literally designing levels and while in there - thinking how each piece of the level should be "registered" in the Frustrum Culling system.
I haven't even discussed DYNAMIC OBJECTS. So far - I don't have a fancy system for them - I just frustrum cull them individually - but if the static techniques and speed gains taught me anything - I know I should give serious thought how to optimize the Dynamic Objects as well.. maybe a loose arrangement of REGIONS - and make object moves automatically adjust what region they are in. (though this sounds CPU instensive to me know - I'm sure the need for a creative means to eliminate the number of frustrum checks for dynamic objects will likely arise.)
Also - frustrum Limb Culling. I don't have Limbs going into individual regions. For Limb Culling - it works like this currectly: If the object to be LimbCulled is getting processed - and the object itself is in the frustrum at all - then ALL THE LIMBS get processed (frustrum culled) - regardless where they are. I do not have a system where half the limbs can be in one region and the half in another region yet - but who knows - maybe that need will arise when I start using Pixel Perfect's 3dWs file loader.
Well - I thought I should document these findings. I hope they are understandable and I'm not stating the obvious - took me a while to get things to click. Now I can a LOT MORE folliage than I thought possible before. Though Game FUN is still the most important - I want a "core" to build on that I don't have to rebuild if I decide to push the envelope later
Hope this posts helps someone.
[edit]fixed limb culling explaination a bit[/edit]
