Skip to main content
GameDev.net gamedev.net
🔒 Locked 🎮 Unity

engine design: rendering & culling

Started by Hiewk Apr 4, 2005 at 2:34 PM 4 replies 700+ views
Original Post
Hiewk
Hiewk
I'm writing a 3D game engine (or maybe should call it "wrapper"), and in this stage i've some questions, regarding tothe engine design: 1. When culling objects (so they arent called for render) should they still be fully updated in the frame in anything else, like its matrices, position/state/mode variables, or just some key variables? I mean, what do you do when culling objects off screen? In mine engine, i call each frame a update() method for each object, that updates its variables according to input and time, and then call render() just if it hasnt been culled. 2. Also about rendering objects, is it common to have some kind of a render manager, wich all objects to be rendered should regist themselfs, and then these manager culls some objects out rendering the remaining ones, doing also maybe some sort of optimizations, like agroupping those who use the same directx render states (avoiding been constantly changing states)? This is just an idea I had, currently i havent implemented nothing like this, so how do you manage this problem of rendering many objects? thanks for reading this
dmatter
dmatter
Even if an object is culled its update should still be called. Imagine an object moving from the far right (out of view) into the scene moving left. While the object is out of view it is culled but if you did not call its update then the object might never actually update its position and therefore never move into view when in-fact it should do.

It is common to use a render queue in which all object to be rendered are added, often the render queue will implement some sort of sorting scheme (ie sort by render state) in order to optimise rendering.

If you use a scene-graph then you can update, cull and render all objects simply by traversing the hierarchy. The render function would add the object to the render queue where it is sorted and then actually rendered.
robert_p
robert_p
I've used an update area bigger than the view, then use random numbers for stuff outside of it. Without doing this it's pretty hard to get like 1000 entities in your world.
Hiewk
Hiewk
Writing a Scene manager seems in fact to be a very good solution.

robert_p
You mean giving less importance to the entities that are far from view area, thus applying a less accurate but faster update method to them?
robert_p
robert_p
yea, or don't even update them... prety much depend on your game.
kburkhart84
kburkhart84
To keep it more realistic, I'd update whether you render or not. That way if an enemy isn't in your sights, He can still shoot you. But then, in some games, you might not need to update. In the case of a particle fountain that is a special effect but constantly runs, you only need to update it if you are looking at it. But in the case of an explosion type, it needs updated because it only happens once(per explosion anyway). What would you do if you saw an explosion particle effect, turned around, waited a minute, then turned back around to still see the particles floating around like when you turned around the first time. But then a water fountain done by particles wouldn't matter because the player expects to see it the same way. Apply this same property to other things in the world. In most cases, the enemies will be updated but some game objects won't.


Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.