Dynamic object creation
by Gary Preston · in Torque Game Builder · 09/05/2005 (11:49 am) · 3 replies
My actual question is near the end of this post, the following is just to explain what I've attempted so far and plan to try next:
I'm playing around with a world that has 40k objects distributed within 8000x8000 units. Since T2D not suprisingly grinds to a crawl fps wise, I've created a way of paging in objects as they enter the viewable camera area (or potentially entering).
I've done this by subdividing the world in sectors allowing me to cull large numbers of objects via a few tests against the small set of sectors. Any sector that becomes partially visible has sprites created for all the objects within it. Likewise as sectors leave the visible area, their sprites are deleted.
This works quite well, giving virtually no fps hit since at any time I've now only got around 500 sprites created and of that usually < 100 are actually been rendered by T2D. Also because the sprites are static I've turned off physics which has improved the frame rate considerably.
As an additional improvement I've been looking into storing my object data using a QuadTree with each leaf node storing up to X objects. When X becomes too large, this can be split into amongst four more child nodes. This way densly populated sections of the world will be split into a number of sub-levels, whilst sparsly populated areas may have no sub trees at all.
I'm planning on creating a class in the engine to store all the objects which will then test for whether any sprites need to be created/destroyed whenever the camera view area changes.
Bearing in mind that the 40k used above is an arbitary figure choosen to stress my machine and may potentially be larger, I plan on eventually having the object data streamed in from disk as and when a parent further up the quad tree enters a potentially visible state. Rather than relying on storing all the objects in memory all the time. But thats an optimisation I'm not worried about at this stage.
I'm fairly sure my above plan will work well, since the quick torque script test implementation using only a few subdivisions and a hook in UpdateScene incurs virtually no frame rate hit, but not knowing the internals of T2D I started to wonder whether there is a better way for me to add in this sort of support.
Since at this point I probably can't see the wood for the trees :) As a number of posters here seem to have delved into the bowls of T2D, I thought I'd throw this question out to see if anyone has any better ideas for how to add/extend the engine support such a large number of objects.
I'm playing around with a world that has 40k objects distributed within 8000x8000 units. Since T2D not suprisingly grinds to a crawl fps wise, I've created a way of paging in objects as they enter the viewable camera area (or potentially entering).
I've done this by subdividing the world in sectors allowing me to cull large numbers of objects via a few tests against the small set of sectors. Any sector that becomes partially visible has sprites created for all the objects within it. Likewise as sectors leave the visible area, their sprites are deleted.
This works quite well, giving virtually no fps hit since at any time I've now only got around 500 sprites created and of that usually < 100 are actually been rendered by T2D. Also because the sprites are static I've turned off physics which has improved the frame rate considerably.
As an additional improvement I've been looking into storing my object data using a QuadTree with each leaf node storing up to X objects. When X becomes too large, this can be split into amongst four more child nodes. This way densly populated sections of the world will be split into a number of sub-levels, whilst sparsly populated areas may have no sub trees at all.
I'm planning on creating a class in the engine to store all the objects which will then test for whether any sprites need to be created/destroyed whenever the camera view area changes.
Bearing in mind that the 40k used above is an arbitary figure choosen to stress my machine and may potentially be larger, I plan on eventually having the object data streamed in from disk as and when a parent further up the quad tree enters a potentially visible state. Rather than relying on storing all the objects in memory all the time. But thats an optimisation I'm not worried about at this stage.
I'm fairly sure my above plan will work well, since the quick torque script test implementation using only a few subdivisions and a hook in UpdateScene incurs virtually no frame rate hit, but not knowing the internals of T2D I started to wonder whether there is a better way for me to add in this sort of support.
Since at this point I probably can't see the wood for the trees :) As a number of posters here seem to have delved into the bowls of T2D, I thought I'd throw this question out to see if anyone has any better ideas for how to add/extend the engine support such a large number of objects.
#2
Knowing T2D might support something like this in the future means I can always move onto prototyping the rest of the game and come back to this in the future when T2D either supports it, or I have a pressing need to add it myself.
Although I think before I go any further with my original plan it's worth having a better dig into the existing code to see if I can work around that. If nothing else, it makes for a good excuse to get more familiar with the engine :)
09/05/2005 (1:45 pm)
Is there anything you havn't got planned for T2D :)Knowing T2D might support something like this in the future means I can always move onto prototyping the rest of the game and come back to this in the future when T2D either supports it, or I have a pressing need to add it myself.
Although I think before I go any further with my original plan it's worth having a better dig into the existing code to see if I can work around that. If nothing else, it makes for a good excuse to get more familiar with the engine :)
#3
Seriously though, I think there's a good chance I'll get the "seperate list for disabled objects" feature in, it's the change of the scoping rules I'm not sure about.
Either way, I'll mark this thread against the work-item and post back when it's done.
- Melv.
09/05/2005 (11:24 pm)
Well, planning is the easy bit, finding the time is the challenge. ;)Seriously though, I think there's a good chance I'll get the "seperate list for disabled objects" feature in, it's the change of the scoping rules I'm not sure about.
Either way, I'll mark this thread against the work-item and post back when it's done.
- Melv.
Employee Melv May
Also, I've partly implemented the ability for objects that are disabled to be placed into a completely seperate list so that they take no processing time whatsoever when disabled. I removed some of this code as I was getting a few issues related to the container system but it's nothing that can't be rectified. Disabled objects take minimal time to process at the moment but with 10's of K objects, this can obviously accumulate.
These are things that I wanted to look to get working for the next release although I'm not sure if I will get the time but most of the code will already be there. I'd love to get this feature ready, especially as I've just finished a whole bunch of performance stuff. This would take it to the next level.
I know this isn't a direct solution to you but hopefully you'll take comfort in knowing that this will become a core feature very quickly as I want to allow T2D maintain large object scenes with ease (and a little configuration).
- Melv.