   Graphics Organisation
  HiCan anyone tell me how to organise my graphics in C++/Direct X.What I mean is if I have a large city say, should I split this into 'blocks' and only render 'blocks' near the camera, or is this taken into account by the view distance anyway.(I suspect it isn't as the city area would be massive compared with what needs to be rendered)But I would like to be sure, as I am aware of the overhead in switching textures, and I dont want to be shifting data to the GFX card all the time. Cheers   
Quote:Original post by trotski...should I split this into 'blocks' and only render 'blocks' near the camera, or is this taken into account by the view distance anyway......as I am aware of the overhead in switching textures, and I dont want to be shifting data to the GFX card all the time...You answered your own question? ;-)Yes, the purpose of any spatial representation (quadtree, octree, binary space partitioning tree, ...) aka scene graph in every graphics/game engine is to minimize the data size, which gets send to the gfx card for the next render call, because the data I/O bus becomes the bottleneck for large datasets like terrain geometry (if the whole terrain doesn't fit into the gfx cards own memory).Then again there are useless draw calls, which slows down the overall framerate because of drawn data, which isn't inside the viewport (this data have to be computed by the gfx cards, otherwise it wouldn't know that it is outside the viewport).   ;  ... wrong button (quote instead of edit) ... mmh, that happens a lot for me ... did i become old? ^^...   ;  In my games I traverse though the scenegraph and only render the items that are less than a specific distance away from the player.  This works great but you have to be careful when it comes to transparent objects.Since you need to render the items that are further away first before rendering the closer ones, I have a separate section that sorts and renders these.  Code for all this is available in the videos my website.   ;Quote:Original post by mmakrzemIn my games I traverse though the scenegraph and only render the items that are less than a specific distance away from the player.  This works great but you have to be careful when it comes to transparent objects.Since you need to render the items that are further away first before rendering the closer ones, I have a separate section that sorts and renders these.  Code for all this is available in the videos my website.Well, if you're doing Z-buffered rendering this is actually a really bad idea. Assuming, of course, we are indeed talking about opaque objects :) With transparents back-to-front is the correct approach.Remember, Z rejects are faster than accepts; this sounds rather arbitrary until you realize that if the Z test passes, you will actually need to update the nearest Z value AND compute/store lighting/g-buffer data/what-have-you. Hence, you actually want to render front-to-back so as to reject as many pixels as possible. Obviously if you're using this simply because you don't have Z-buffering as an option, it's probably still acceptable. I would probably suggest other methods to reduce overdraw (there are alternate algorithms, though their respective costs may outweigh the gains) regardless.