Jump to content
Posted 18 July 2012 - 02:18 PM
Posted 18 July 2012 - 03:01 PM
I was wondering if it is a good idea to design the rendering system so that each game entity and interface element that should be rendered registers its visual representation every frame, or should they register and unregister as appropriate? Give that the objects typically change a lot, as their positions move and the like, I'd imagine that first option would result in simpler logic and better performance. Or am I completely wrong with how rendering systems usually are designed here?
Posted 18 July 2012 - 03:14 PM
Posted 18 July 2012 - 03:49 PM
You dont want to reupload/register data that doesnt change. Only update data that changes (like position).
Posted 18 July 2012 - 04:03 PM
Posted 18 July 2012 - 04:59 PM
Edited by omercan, 19 July 2012 - 02:11 AM.
Posted 18 July 2012 - 05:31 PM
Posted 18 July 2012 - 05:53 PM
Posted 18 July 2012 - 07:28 PM
Edited by ZBethel, 18 July 2012 - 07:59 PM.
Posted 19 July 2012 - 03:30 PM
Is adding a bunch of objects to a list every frame really going to cause performance issues? You don't need to allocate space for the array every frame, you could have an array that grows (like a variant of std::vector, or just use that). Besides, you could have one renderable for a set of instanced meshes if you're going to have tons of similar objects onscreen.
Posted 19 July 2012 - 09:39 PM
Posted 20 July 2012 - 12:51 AM
I guess that's implementation-dependent. The physics API I use does not allow that natively. Just pointing out.
Only moving objects will register and unregister with the quad- or oc- tree, and this is done every frame, but insertion should be instantaneous, and the same quad- or oc- tree can be used for multiple subsystems, from graphics to collision detection.
Posted 20 July 2012 - 01:19 AM
Peace and love, now I understand really what it means! Guardian Angels exist! Thanks!
Posted 20 July 2012 - 04:42 AM
In the past, I've used std::multimap to sort things by their material, where materials consist of a pair of shaders, and a list of textures.
For a small game, the multimap solution (with a predicate based on the shader ID and then the texture ID's ) is plenty fast.
There's no longstanding registration/link between renderable objects and the renderer.
Just because spatial partitioning schemes can be used to accelerate rendering does not mean that is all they can do.
There is no physics API able to return a list of visible items? O_O
Edited by L. Spiro, 21 July 2012 - 12:17 AM.
Posted 20 July 2012 - 04:17 PM
Posted 20 July 2012 - 05:56 PM
What are you registering/deregistering items with? Is this equivalent to adding objects to a "will be rendered" list?
I rebuild my "objects to be rendered" list from scratch every frame, and throw it away at the end of the frame. There's no longstanding registration/link between renderable objects and the renderer.
Culling/collecting 2000 renderables, updating their state, sorting them on multiple conditions, and then executing the D3D commands required to draw them, takes about half a millisecond...