Questions - overdraw reduction and portalisation
by Andrew Kerr · in Torque Game Engine · 04/05/2005 (3:58 am) · 3 replies
1#
I am thinking of a game idea for which Torque appears ideal; however the missions I am planning would have a great many enterable buildings, and thus massive overdraw. As we all know, overdraw is caused by overlapping polygons being drawn in their entirety, potentially wasting much fill rate and bandwidth.
ATi and nVidia use overdraw reduction techniques which benefit from front-to-back sorting of polygons.
My question then is - does Torque (TGE or TSE) do any kind of sorting? A relatively simple method would be to roughly sort visible DIF objects by depth in screen space, or at least find the nearest and render it first.
2#
Concerning portalisation and terrain...
If a four sided building had rooms in each side such that the room in (e.g.) the North face could only be seen into from the North, and if a player were to stand in the terrain on the North side of the building - would the engine also render the invisible rooms in the East, South and West walls?
I guess I'm asking whether the terrain is considered one big zone. I further guess that it is.
Also, Quake 3 engine has a command (r_lockpvs 1) to "fix" the currently visible zones, so even if you cross a portal no new zones can be rendered, leaving a HOM effect in place. This is useful for checking whether the portalisation was sensible. Does Torque do anything similar? I know about "setInteriorRenderMode(7);", but it doesn't help with what is considered visible from where.
I am thinking of a game idea for which Torque appears ideal; however the missions I am planning would have a great many enterable buildings, and thus massive overdraw. As we all know, overdraw is caused by overlapping polygons being drawn in their entirety, potentially wasting much fill rate and bandwidth.
ATi and nVidia use overdraw reduction techniques which benefit from front-to-back sorting of polygons.
My question then is - does Torque (TGE or TSE) do any kind of sorting? A relatively simple method would be to roughly sort visible DIF objects by depth in screen space, or at least find the nearest and render it first.
2#
Concerning portalisation and terrain...
If a four sided building had rooms in each side such that the room in (e.g.) the North face could only be seen into from the North, and if a player were to stand in the terrain on the North side of the building - would the engine also render the invisible rooms in the East, South and West walls?
I guess I'm asking whether the terrain is considered one big zone. I further guess that it is.
Also, Quake 3 engine has a command (r_lockpvs 1) to "fix" the currently visible zones, so even if you cross a portal no new zones can be rendered, leaving a HOM effect in place. This is useful for checking whether the portalisation was sensible. Does Torque do anything similar? I know about "setInteriorRenderMode(7);", but it doesn't help with what is considered visible from where.
About the author
Andrew Kerr