Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Dark GDK / Frustum culling in DarkGDK?

Author
Message
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 4th Oct 2007 20:36
Link
A while back I integrated Lost In Thought's Frustum Culling (field of view) routine for DBPro into my early game engine and got an impressive poly reduction. Now I've made the jump to DarkGDK I was wondering if anyone had any working frustum culling routines or had attempted porting his code?

No matter how good your code is, someone will improve on it
Back to top
Profile PM
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 5th Oct 2007 01:30
Link
Nope - but I was JUST about to post a problem in DarkGDK (I think its a problem - it is for me) regardling this sort of thing.

Let me start by saying I haven't read EXACTLY what frustrum culling is - but I'm making a Terrain loader for Iron Infantry - based around T.Ed (Terrain editor sold here) and I tried to "Upgrade" my "Distance based" culling to use "dbObjectInScreen" and it seems like it might work ok for "trees" and stuff like that but for terrain - it would remove a tile off the screen when it wasn't quite the right time to do so! Like if flying over a square of terrain, and more than half way - it would disappear to early.

I'm with you - you can really bring the frame rates up - but I need to figure out my own "OnScreen" function - ... which begs the question - is that what you did in DBPro?

I need to take the FOV into account along with some magic to know when any part of an object (AT ALL) is on the screen or not - so I know whether to hide it or show it.

I hope this thread turns into some good ideas for both of us!


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 5th Oct 2007 03:01
Link
Ok - sorry for double post - but I looked up and read a ton about various Culling techniques - and I think with DarkGDK - the BackFace culling in addition to Frustrum culling is probably best for open landscape terrain (outdoor or space). They mentioned some pretty trick algorythms - even some where having two kinds if coded right will sometimes cull something together where alone said item wouldn't qualify - but whatever - I'm just trying to keep frame rates up while showing a bunch of stuff - and not slowing the cpu down to much because I want to add alot of stuff in the way of trees, huds, ai, and some home grown physics and possibly some physic engine stuff.

So - you mentioned a DBPro version of frustrum culling - I may help take a C++ stab at it if you post the code


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
Morcilla
21
Years of Service
User Offline
Joined: 1st Dec 2002
Location: Spain
Posted: 5th Oct 2007 12:04
Link
Hey Lost in Thought's code is not ported (as far as I know), but I do not see any problem to do so. Here is the link to the code snippets thread:

[DBP] Frustum Culling ported to DBP

It is confirmed that it does a performance boost, so we all should give this a try sooner or later...
Back to top
Profile PM Email Website
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 5th Oct 2007 12:56
Link
Thanks for posting the link Morcilla, that's the code I integrated into mine and I can confirm that it works pretty well, I typically got poly counts down to half or a third of the original.

If you would like to see it in action Jason download the modified '3D World Studio Inca Pro' demo, that Lost In Thought produced, from the following link:

http://forum.thegamecreators.com/?m=forum_view&t=73134&b=1

The post with the link is about 3/4 of the way down the page.

This shows an impressive frame rate increase in a fairly representative gaming environment.

I would look at porting the code myself but I'm still tied up at the moment with trying to get the release version of the DarkGdkODE physics library up and running. Although, if the indications in the latest TGC News Letter are to be relied on, it looks as if they are working on releasing most of the DBPro plug-ins for DarkGDK within the next 3 - 6 months which would be good news!

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Red Ocktober
20
Years of Service
User Offline
Joined: 6th Dec 2003
Location:
Posted: 6th Oct 2007 03:58
Link
this is interesting... i'm sure i'm gonna wind up needing to apply this... or something like it...

good thread... thx

--Mike
Back to top
Profile PM
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 6th Oct 2007 05:23
Link
Guys - I took a long gander at the Frustrum culling code - and it seemed a bit complex for only really working on cubes - (Or sphere's less accurately) - This Might be the best way to do it for all I know - but - I read that DBPro (So likely DarkGDK) already has a form of "auto" Frustrum Culling - but I'm sure you'll agree its not perfect - just look at the poly counts - and the improvement of hiding objects etc....

My Current strategy is a combination of "Distance Culling" (My own name for a LOD style - Its far enough from the cam - so hide it!) mixed with the "Flawed" dbObjectInScreen. (Which is flawed if you have a "Mesh" terrain... say 5000 wide/deep and a cam max distance of 12000 - and you fly over the center and get close to the edge - but not yet - it disappears - basically to soon. By Combining the Distance thing with the dbObjectInScreen - and tweaking it a bit - I think I might get something reasonable

(This is a work in progress so it will be "logic optimized" later.. currently checks all if you know what I mean)


I hope this at least kinda explains what I'm doing - or I should say JUST starting to do. The distance trick for LOD in Iron Infantry - made for a decent improvement in Frames - if I can get something decent looking and fasty enough - I'll run with it - want to get to the game part but I cant/won't until I have a reasonable terrain "engine" or "sytem" that is pretty high frame rates - even on my slow card.


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY

Attachments

Login to view attachments
Back to top
Profile PM Email Website
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Oct 2007 09:53
Link
Thanks Mike, I think anyone looking to maximise their object count will need to tackle this one way or another.

I kind of agree with you Jason, the code is complicated but in practice does yield good results and I have never seen it cull anything that is genuinely on-screen yet! Conversely, I have seen instances where it still leaves objects clearly not on-screen, so I think the logic is not perfected yet.

However, the dbObjectInScreen function looks like it could form the basis of a workable system so, like you, I think I'll take a bit of time and play around with it and see what can be achieved. Thanks for pointing it out. It would be nice to get something up and running that most people could use.

Bye the way ... your terrain is looking really nice ! Is that a static skybox or is it dynamic?

No matter how good your code is, someone will improve on it
Back to top
Profile PM
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 6th Oct 2007 10:28
Link
Thank you Pixel Perfect - Its Static Skybox - however I'm still "toying" with everything - so I'm still experimenting with just backdrop and matching fog, and other combinations - still trying to get the feel of the "Sweet spots" in DarkGDK - Example - just my experience - DBPro does well with fog and stuff - say in a Cam range 1-16000, Fog 15000-16000 (Pretty far view) but to get the same kind of "Fog look" I had to do Cam range 1-28000, Fog starting at around 25000. Also - Strange things with my NVidia - Terrain 3x3 tiles - Great - Make it 4x4 - frames drop even though they are culled ..offscreen etc. Think when vid ram gets hit maybe it plummets sharply. Hmm.

I'm with you - still tweaking the objectinscreen and seeing what can be done - and then if it simply stinks or one of you says JASON TRY the FRUSTRUM WORTH the TIME! Major Major FPS - .... Then I'll probably bite the bullet then

I've been at it all night - thanx for the compliment - I need to crash ZZzzz...


http://www.jasonpetersage.com/?PAGE=jpsmain&SECTION=IRONINFANTRY
Back to top
Profile PM Email Website
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 6th Oct 2007 12:11 Edited at: 6th Oct 2007 12:12
Link
Actually Zeal ported a version ages ago, though a very old version. It can be found here and used to port over the new code if anyone wants to:

http://forum.thegamecreators.com/?m=forum_view&t=76143&b=22

[edit] At least I think he got it working 0_o

Back to top
Profile PM Email
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Oct 2007 13:39
Link
Thanks for your input Lost and for the great job you did in putting it together in the first place! I'd really like to see this working in DarkDGK projects so I'll take a look at Zeal's port and the possibility of porting your latest code as soon as I get some time.

Always interesting to hear your comments Jason, I've not tried using fog in either product yet. Regarding the tiling I guess pushing your cards on board video RAM could be the explanation, you'd certainly expect to see a drop in fps once it started paging.

I'm still going to try some experiments in the meantime with the dbObjectInScreen function but it may prove to be too inefficient as the number of objects rise.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 6th Oct 2007 15:17
Link
If you want to use the culling on objects as a whole then the object in screen function is faster in most cases. The frustum culling is really designed for limb culling. It works best on objects with evenly distributed limbs and 100-500 polys per limb or so. Though it can help with as few as 6 polys per limb in some cases. The lower number of polys per limb the slower the culling will be vs the time it would have took to just draw them. The higher the number of limbs and DBP will still run slow just from the limb index overhead. I have GDK.net so I can use it with VB, so I will eventually port it over to that. That won't help the c++ users though

Back to top
Profile PM Email
Pixel Perfect
17
Years of Service
User Offline
Joined: 21st Feb 2007
Location: UK
Posted: 6th Oct 2007 23:02
Link
I see what you're saying and yes, that’s a quite important distinction. I'm using world levels designed in 3D World Studio and loaded as a single object so I guess Frustum Culling routines that work at the limb level are probably more applicable to me currently than say Jason's situation, which would probably benefit more from straight object culling.

No matter how good your code is, someone will improve on it
Back to top
Profile PM
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 19th Oct 2007 21:29 Edited at: 19th Oct 2007 21:31
Link
I've been poking around and I'm back here. I think I've read enough to be convinced - its got to be done. I'd rather port the DBPro code LIT wrote because we have multiple people saying it works well. This is the code base I should probably start with. At least if it gets hosed - its my fault and I can hopefully fix it!

Saw the Frustrum Page - I don't get one thing... How does taking all the matrix pairs and multiplying them give you a plane and stuff? That I don't get - WORSE - the whole normalization thing. I think of normalization - I think either smoothing - or "Normals" which are the direction of a polys face I thought.

Maybe I have to read a three inch manual to find out but its more than I would like to forced to read right now - but who knows.

I want to make my game - and need certain things dead fast, pretty, and hopefully wrapped tightly so they are easy to use - "Fire and Forget" if possible. If I REALLY need good looking Terrain, Trees, and the occasional building, tunnel whatever, I think I need a combination of things - some sort of terrain LOD, Some Sort of Poly Reduction tool (Action3d looks good - sold here) and YES frustrum culling one way or another - LIT's Explaination about limbs versus objects I guess means I should make Spheres for each "Limb Piece" in a model say from 3dws, to speed that up, and use object in screen for the basic object occlusion... also thought of a cheap trick and did some tests that suggest this port might be for naught.

After more careful review of Object In Screen, and LIT's own claim of how its faster - One Could Make a Bounding Sphere or Object in DB or DarkGDK, Hide it, and just position it "around" the limb or object and call object in screen on it. This might be easier. Also, for HUGE flat plains/meshs - like a terrain tile - Object In screen tends to get incorrect "falses" effectively hiding tiles that are still in view. After reading the culling tutorial - I can see why. Has to do where the Vertices/Points are. I'm thinking two things - use the dummy object - move it to various strategic locations - and do tests on it OR kitty corner the plain and test again. Perfect? Probably not - but defiantely faster than trying to manually write code to check various "strategic" locations - in short - if I can get the DarkGDK logic to do the testing for me somehow - I will If not - I'll port the famous Lost In Thought Frustrum Port

[edited author's name...blushing...got it wrong first go round] Sorry LIT


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 20th Oct 2007 00:24
Link
Quote: "I don't get one thing... How does taking all the matrix pairs and multiplying them give you a plane and stuff?"


Nor do I, but in order to port and use code you don't really need to fully understand the internal workings of everything. Just it's flow and purpose.

Quote: "That I don't get - WORSE - the whole normalization thing. I think of normalization - I think either smoothing - or "Normals" which are the direction of a polys face I thought."


Normalizing means to take a set of numbers and make them all be from 0 to 1 in size but retain their same scale to each other. Notice the 1/ the 3 plane normals' vector distance. This gives you a base to mulitply all 3 by to make them all be of the same scale to each other but less than or equal to 1.0, you also multiply the distance element by this. It however doesn't have to be less than or equal to 1.0, but needs to be scalled down along with the others.

As far as the porting goes, it should be really easy once DGK has the Get Matrix4 Element() command that DBP has. Which it may have now 0_o I'll be doing some checking into getting GDK, but it may be a while and it may be even longer till I could use it. I need to find some free time somehow LOL

Back to top
Profile PM Email
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 20th Oct 2007 03:40
Link
Thank you very much - I finally know the difference between a normal and normalization and I agree about the porting - just nice when you do know.

When I starte the Ted Loader - I followed the example code verbatum - once I saw what was REALLY going on - I wrote a (IMHO) a much better implementation - and expanded to to do many CUSTOM things in the various CUSTOM SECTIONS.


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Lost in Thought
20
Years of Service
User Offline
Joined: 4th Feb 2004
Location: U.S.A. : Douglas, Georgia
Posted: 23rd Oct 2007 12:42 Edited at: 23rd Oct 2007 12:42
Link
Yeah I always meant to go back and finish the TEd loader, I just based it on the Blitz version and never had time to go back and finish it. Once the 3dw loader is done I am going to go back and add support for TEd to the open source engine, so I'll finish it then

Back to top
Profile PM Email
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 23rd Oct 2007 15:56
Link
You did a fine job. I would of probably would have had three different approaches before settling on what I have now if it wasn't for the work you did.

How goes the 3dws loader? I bet it loads quick when its ironed out with those byte saving lowlevel formats (A pain to debug naturally ...but)

For Frustrum - I'm still letting that sit on my plate - for a conversion to GDK (If anyone wants to take a stab at it) because I'm currently trying to take Visigoth's Satellite terrain to a new level - basically - what he did is awesome - and for reasons (maxing out DarkBasic) the loader has a max "Area" that is approximately 1000x1000 meters or something - I forget - but what I'm trying to do make a way to grab as much satelite info as you want, have it become categorized in a database of sorts, and create various "Resolution" tiles - so in short - you end up with something not to unlike a flight sim - but able to walk/fly around using real coordinates - a sort of high-res google earth

Why? For the Game I'm slowly putting together - it kind of makes a lot of sense. Not trying to do the whole world - but make that a possibility - at least be able to traverse 20+ miles without a hiccup. I will defenayely need the frustrum code implemented to make that work smoothly!

It would be interesting to be able to pick a plot of land and bring it into 3DWS - so a building could be at least modeled as if it was literally "on the Ground" you intend to place it on. Like if you wanted to model a "Boat Yard" you could do it on an actual Shoreline. That would be really neat I think.

Oh - well - I won't geek out on it forever - but I think I can make something CLOSE to a global mosaic - not Microsoft Flight sim - but something workable. Note: Flight Sim Seems to connect and "smooth seams" on the fly dynamically. I'm not sure if db could do that "in game" - so tiles just "adjust" themselves etc. I don't know - I do know that Visigoth's in memory mesh stuff is quite "Trick" - and at least TODAY - I don't know how to do that yet.


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 15th Jan 2008 20:25
Link
@Pixel Perfect in Response to this statement far above :
Quote: "Thanks Mike, I think anyone looking to maximise their object count will need to tackle this one way or another.

I kind of agree with you Jason, the code is complicated but in practice does yield good results and I have never seen it cull anything that is genuinely on-screen yet! Conversely, I have seen instances where it still leaves objects clearly not on-screen, so I think the logic is not perfected yet.

However, the dbObjectInScreen function looks like it could form the basis of a workable system so, like you, I think I'll take a bit of time and play around with it and see what can be achieved. Thanks for pointing it out. It would be nice to get something up and running that most people could use.

Bye the way ... your terrain is looking really nice ! Is that a static skybox or is it dynamic?
"


I found out the logic with LIT's Frustrum Culling - why some things MIGHT OCCASIONALLY disappear to quick, or linger... and its actually ... get this... an Impressive Bug!

I did some work making primitives for the "Cube" mode and the "Sphere" mode and the "box mode" and I could visually see what effect his (i call it the Fudge Factor" was set to 0.5. This made SPHERE and CUBE 50% of the Size of the Object it was to cull.

For Models of bad guys - I get it... For Terrain - not so much - but in playing with these things and basically running up one side of his frustrum code and down the other - I personally not only am a "user of it" I'm a fan - and I've learned alot, written like 10 varioations of it - and I'm still trying to improve it - and integrate it with my "GDK" classes to make it just "Happen" but in a way that is as TIGHT and FAST as possible, ie. a "Index" (Quadtree or whatnot) so that ONLY stuff desired to get gets culled - versus checking "IF MyObj.CullMe==true then Obj.CullMe" etc etc. The list how he set it up is still way sweet and the Quad thing is neat that I've done but I thought I could get some high output with linked linked list and now I'm determined to redo it to a "closed" array - that is .... Set Up Your Quadtree - and let'er rip... all in one tight array so it just screams... Also Quadtree eliminates unecessary frustrum checking but house keeping needs to occur - managed or (IF InFrustrum=false then exclude/Hide) done immediately for all objects. "Managed sounds good in theory - but rpoved a bit hokey in my first prototype - but I think it has merit ... because that idea is to remove stuff a bit at a time so... longest offview stuff first MAYBE... so that game not stiffled just cause you spun around... bad enough you need to show new things - causing yet ANOTHER pause to shut a ton of things off sems a bit much.

Either Way . a straight up array is the FASTEST way to rip through them. I Found results though that gave me the theory that MAYBE EXCLUDING and UNEXCLUDING constantly is possibly taxing in the dbSync routine, yet the benefit is awesome - I'm just saying I think its more then JUST setting a flag "EXCLUDE/NOT EXCLUDE" I get the impression there may be some gfx card overhead to change what's in its mem. (Frame rates and timer around dbSync gave me this impression)


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
tempicek
16
Years of Service
User Offline
Joined: 27th Nov 2007
Location: Prague
Posted: 15th Jan 2008 21:32
Link
Quote: "I get the impression there may be some gfx card overhead to change what's in its mem."


nope, not this case

Quote: "Frame rates and timer around dbSync gave me this impression"


don't ever trust CPU timers around "Present" call (or Sync or Swap or Flip or whatever you call it on any platform); never

Quote: "I Found results though that gave me the theory that MAYBE EXCLUDING and UNEXCLUDING constantly"


use your quadtree and keep information from last frame; if a node of the tree was culled last frame and should be culled again - you don't need to go thru the whole subtree and reset the states of respective objects - they are still valid
Back to top
Profile PM Website
david w
18
Years of Service
User Offline
Joined: 18th Dec 2005
Location: U.S.A. Michigan
Posted: 15th Jan 2008 21:34
Link
I think I am going to have a go at this. I have a few ideas that may work.

The questions I have are. What are the downfalls of dbp/dgdk's auto Frustrum Culling ????

Also, I think that using the object in screen command is not the route to go. Anyways, Like I said I will have a go at this and see what I can do.
Back to top
Profile PM Website
jason p sage
17
Years of Service
User Offline
Joined: 10th Jun 2007
Location: Ellington, CT USA
Posted: 15th Jan 2008 22:01 Edited at: 15th Jan 2008 22:05
Link
Brilliant! - I'll implement that when I try removing linked list and using straight array Good idea! Thank You.

Quote: "The questions I have are. What are the downfalls of dbp/dgdk's auto Frustrum Culling"


It SEEMS to only REALLY Like Primitives you make in DBPro / Dark GDK if you ask me! Try making a mesh yourself, or load a model.... watch poly count. Primitives you make in DBPro seem to DEFINATELY auto "cull" but not anything else - or atleast maybe it workls the primitives it "HAS" the size of, and the auto one uses sphere or cube culling on one "dimension" of model or something... like only height, only width or some such nonsense.

I posted a DarkGDK frustrum port, should be to hard to snag an twist to taste.


http://www.jasonpetersage.com/?PAGE=ironinfantry&SECTION=ironinfantry
Back to top
Profile PM Email Website
Back to top

Login to post a reply

Server time is: 2024-11-17 02:51:35
Your offset time is: 2024-11-17 02:51:35