Game Development Community

[TGB] Quad Tree/Rendering Optimization

by Justin Proffitt · in Technical Issues · 07/07/2011 (10:55 pm) · 1 replies

Hey! So I discovered the principles of quad trees and figured out how to use it to construct destructible terrain, down to 2x2 pixel blocks. It came together pretty quickly and looked very promising, however, I noticed that when I extensively destroy a chunk of terrain the size of the screen, my game (unsurprisingly) drops from an FPS of 120+ to less than 10. I am still very new, and was wondering if since the terrain did nothing except exist and divide/delete itself, I could lower the resource costs of rendering it or somehow cut corners in representing it. As it is, I simply use t2dStaticSprites and the "ActRender" reaches about 7000-10000.

(Though, if I don't thoroughly violate the terrain, it still works fine and I'd recommend it to anyone else new who's interested in destructible objects, this is just an extreme case).

Thanks in advance!
Justin Proffitt's profile picture
Torque Owner Justin Proffitt

About the author

I am a college student majoring in physics. As it so happens I like programming, a hobby which extends my profession in web design.

Recent Threads

  • Scene Event Manager
  • Stacked Objects, Mouse Events and Deletion
  • Scene Event Scheduler (C++)
  • Collision Polygons - 2 Point Collisions
  • SetScreenMode/Focus Crash [Resolved(?)]
    • NextNext Thread
    PrevPrevious Thread
    More from Technical Issues


    Torque 3D Owner Raphael Gervaise
    #1
    07/13/2011 (4:32 am)
    Possible obvious bottlenecks would be the quadtree itself, while it's performing subvisions, or the rendering (e.g. huge amount of drawcalls, poorly batched primitives, no or inefficient texture atlases, etc.).

    Finding the exact source of a problem (logic or performance) is always tricky without "instrumenting" the code. I'd recommend putting in some timers and debug rendering to gather info about your scene.

    Get some profile information (time spent in various modules of your application), and some stats about your quadtree (number of nodes, nodes being rendering, node being culled, etc.), that'll be useful.

    Also, consider loose, sparse and offset quadtrees (basically, variants of "naive" quadtrees to help keep the data structure under control, and avoid zillions of unnecessary nodes, etc.) ; additionally, and if necessary, the quadtree operations can be "time sliced" to be performed over a small amount of frames.