Quote: "
I like the sound of the combined frustum/lod functionality Jason, good luck with that!"
Me too - it's still in the works - and I'm constantly trying to think of ways to prevent "redundant" anything in this culling system. Its one of those things that get so complex - the best way to do it it is to make the simplist pieces work - and the advanced stuff (like regions) designed in such a way that the whole thing works with or without the advanced stuff.. build with legos where possible!
Quote: "
By the way, seemingly DBPro, and presumably DGDK, does back face culling. There is a command dbSetObjectCull(objID,Flag) which seems to control this. Do you know if it’s on by default or do we have to explicitly set it for each object?
"
Pretty sure default is on. Case-n-point - make a dbMakeObjectPlain - flip it around... invisible? I think it will be!
Quote: "
Also, have you tried you existing frustum culling routine in levels with thousands of object/limb combinations.
"
Not there yet - getting STUPID linking errors - not with external stuff... getting junk like this:
------ Build started: Project: GameClasses, Configuration: Debug Win32 ------
Compiling...
jgc_terrain.cpp
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : error C2504: 'JGC_OBJECT' : base class undefined
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C2143: syntax error : missing ';' before '*'
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(64) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(83) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(83) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(113) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(114) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(118) : error C2039: 'ID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.cpp(118) : error C2039: 'LastID' : is not a member of 'JGC_TERRAIN'
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : see declaration of 'JGC_TERRAIN'
jgc_frustrumculling.cpp
test_bitmapfonts.cpp
jgc_vector.cpp
jgc_rgba.cpp
jgc_object.cpp
d:filescodecppprojectsjegasllcgameclassesjgc_terrain.h(21) : error C2504: 'JGC_OBJECT' : base class undefined
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C2143: syntax error : missing ';' before '*'
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
d:filescodecppprojectsjegasllcgameclassesjgc_common.h(343) : error C4430: missing type specifier - int assumed. Note: C++ does not support default-int
jgc_image.cpp
jgc_daddy.cpp
jgc_common.cpp
jgc_bitmapfonts.cpp
Generating Code...
Build log was saved at "file://d:filescodeCPPProjectsJegasLLCGameClassesDebugBuildLog.htm"
GameClasses - 15 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
But the JGC_OBJECT is DEFINATELY decalred - and the include file for it is EVERYWHERE! grrrrrr... How can you not have circular references? I know - ONE HUGE source file! slows down the editor - and compiling time though - decision decisions. everything is so tightly woven - the compiler LIES to me! grrr
I'm just wondering if you have a feel for where it starts to cease to increase fps due to the sheer time spent computing the exclusions?
I'm convinced of a few things (forgive obvious stuff):
1: Machine Speed determines how fast/big a list of things is processed. The key is - make the lists smaller!
2: checking the FRUSTRUM stuff is EXPENSIVE - So check as little as possible! (QuadTree/Portal'ish Type Logic - is my means to an end here - Via Region. I have invisible "BOXES" - that have lots of smaller ones inside. If that Invisible BOX is not in the Frustrum then I skip to another REGION - this eliminates TONS of unneccesssary checks.) I also try to limit how many levels DOWN I use because past experience showed me it takes a lot of trial and error to get the right combination if regions etc. You don't want 5 levels of checks before you hit your first REAL object.
3: Logic Dictates - Region Based - Quadtree/octtree - Portal based stuff Frustrum Code only "Touches" stuff that "Qualifies" to be flipped on. What about flipped off? I think this needs to be somehow made as fast as possible - because this is the REAL WORK (easy - but - has the most things to touch each loop - always more offscreen then on! Wel... guess that depends but.... I want to work it out so that this is done in such a way - that if a "Region" was "all Off" from a previous check - and that Whole Region is STILL not in Frustrum - then move on - But invalidate when it becomes in VIEW - to basically t4ry to have as lean and smart a CULLING SYSTEM on both sides of the COIN - "In the frustrum" and "out" Goal ofcourse - to do as little actual processing as possible.
I'm also thinking - it might not be the best way - but Static objects always fall into the rules I just said I was trying to follow above - While Dynamic objects I'm treating as a straight up list. I thought Regions for these also - (and I may revisit this idea) but you would have to make it so everytime an object moved - you would need to check what region it should be in - this seems to be as much work as just checking the frustrum for it and calling it a day. Especially when you add DarkPhysics into the picture + LOD. Ok - Objects move without your control - (Forget Region thing here... just Cull like I said but - with LOD - and DarkPhysics you ALSO need to check what moved - then if its in LOD 2, 3, or out of frustrum - you display the correct OBJECT - with orientation etc based on the excluded/hidden object that the physics engine is moving around. 2 birds one stone - might as well do LOD Physics aligning, and Culling in one system. Maybe this demonstrates some reason for this kind of approach - but its tricky.
A hard rule for when to much is to much? Dunno - Again - my last working Quadtree system - was a balance of 2-4 levels of quading - and then a limit to the objects/limbs mattered. I say tweak because the settings I imagined would work best for my design sucked - but variations to it screamed - either way - beat the pants of not doing it at all.
Quote: "
Also, I might have done LIT an injustice in my previous statement regarding vertex color lighting on the meshes.
"
He's a pretty resilient fellow.
Quote: "It does look like it is working to some degree, its just that the colors are a little subdued, I'm going to see if I can improve this.
"
Weird - but good news. you saying shadow mapping might be working....sorta? Or did I misunderstand?
Quote: "
Might be able to do something like I did with the terrains which would involve converting all the limbs to objects and using blending commands to gain the increased flexibility.
"
There's an improvement we could use - Limbs with just as much control as objects - but if you do an object command - (I definately understand/appreciate/utilize if) have that override the last limb commands... like SET LIMB LIGHT zero, would do what it sounds like but afterwards something like SET OBJECT LIGHT 100 would override - kinda a global.
Quote: "
It’s the strangest thing, but so far increasing the object count at the expense of limbs has only improved the fps! Not what I'd been led to believe at all!
"
This is a good thing! I look at like this:
1: Create/Delete Objects as LITTLE AS POSSIBLE
2: Too MANY objects (ids in use) Can cause a slow down
3: Create Limbs unless its really complex unless rule 2 biting you.
Quote: "
However, as I currently clone the mesh objects I might lose a lot of efficiency in converting all the limbs to individual objects, but it’s the only way to get greater control over the texture blending
"
Well sir - this is a VERY interesting point. I have an idea. You Might want to KEEP the code as is with the Limbs AND add support the other way - and allow the user to control which method to invoke during the load. This kinda makes a win win in the long run. If someone finds one way works best for their level - fine - or what if TGC fixes the Object Count thing? Then tons of objects is great! What if they give us that extra limb control? then you just add the same code you applied to the individual objects to the limb "method" and you are back to the user picking what they like most.
Running out's a time - need to get back to my code! LOL