On 1/17/2012 5:10 PM, David Barbour wrote:
On Tue, Jan 17, 2012 at 2:57 PM, BGB <[email protected]
<mailto:[email protected]>> wrote:
game art doesn't need to be particularly "awe inspiring", so much
as "basically works and is not total crap".
It can't be awe inspiring all the time, anyway. Humans would quickly
become jaded to that sort of stimulation.
partly agreed (although, maybe not "jaded", but more like what is "awe
inspiring" one year becomes mundane/mandatory the next).
actually, it is also an issue with many "classic" map generation
technologies:
people become used to them, and used to seeing more impressive things
being generated by hand (often with uninteresting aspects increasingly
subtly offloaded to tools).
once something "better" takes hold, it is harder to keep interest in the
older/simpler/more-mundane technologies.
so, now many people take for granted technologies which were novelties
10 years ago (real-time rigid-body physics / ragdoll / ..., the ability
to have light-sources move around in real-time, ability to have dynamic
shadows, ...), and possibly unimaginable 15 or 20 years ago.
if a person went directly from being exposed to games like, say,
"Wolfenstein 3D" and "Sonic The Hedgehog", ... to seeing games like
Portal 2 and Rage, what would their response be?
but, to those who have lived though it, it seems like "nothing
particularly noteworthy".
15 years ago, the "big new things" were having 3D modeled characters,
colored lighting, and maybe translucent geometry. 20 years ago, it was
having any sort of real-time 3D at all (well, that and FMV).
The quality of a game map depends on many properties other than visual
appeal. A program that creates maps for a first-person shooter should
probably have concepts such as defensible positions, ambush positions,
snipe positions and visual occlusion, reachable areas, path-generation
for AIs.
yeah. path-finding data can be built after the fact, just it tends to be
fairly expensive to rebuild.
One might express `constraints` such as:
* a spawn zone should not be accessible from a snipe position.
* a capture-the-flag map should ensure that every path from the enemy
flag to the base moves past at least one good snipe position and one
good ambush position.
* there should be some `fairness` in quality and quantity of
defensible-position resources for the different teams.
* the map needs to occlude enough that we never have more than K
lights/triangles/objects/etc. in view at any given instant.
yep.
actually, the bigger issue regarding performance isn't really how many
lights/polygons/... are visible, but more like the total screen-space
taken by everything which needs to be drawn.
a single large polygon with a whole bunch of light sources right next to
it, could be a much nastier problem than a much larger number of
light-sources and a large number of tiny polygons.
it is stuff right up near the camera which seems to actually eat up the
vast majority of rendering time, whereas the same complexity model some
distance away may be much cheaper (although LOD and similar may help,
although interestingly, LOD helps much more with reducing the
computational costs of animating character models than it does with
renderer performance per-se).
also, using fragment shaders can be fairly expensive (kind of a problem
in my case, as most of my lighting involves the use of fragment shaders).
currently, there are multiple such shaders in my case (for per-pixel
phong lighting):
one which uses the OpenGL lighting model (not used much);
one which uses a Quake-style lighting model (for attenuation), but is
otherwise like the above;
one which uses a Quake-style lighting model (like the above), but adds
support for normal and specular map textures (renderer avoids using this
one where possible... as it is expensive);
one which uses a Doom3 style lighting model (box + falloff + projection
textures) in addition to normal and specular maps (not currently used,
considered possible reintroduction as a "special effect feature").
the issue is mostly that when one has a shader pulling from around 6
textures (the falloff texture needs to be accessed twice), the shader is
a bit expensive.
note that the normal is actually a bump+normal map (bump in alpha), and
the specular map is a specular+exponent map (specular color, with
exponent-scale in alpha). in all cases, these are combined with the
normal material properties (ambient/diffuse/specular/emission/...).
for related reasons:
adding a normal or specular map to a texture can make it nicer looking,
but adding a normal map also makes it slower (and a possible performance
feature would be to essentially disable the use of normal and specular
maps).
there also seems to be a relation between texture size and performance
as well (smaller resolution == faster).
it is also a non-linear tradeoff:
a large increase in texture resolution or use of costly rendering
features doesn't necessarily result in a similar increase in the
perception of visual quality (it may actually make things worse, as the
drop in frame-rate may actually be much more obvious).
But, in my practical understanding, these issues are not so distinct
from visual appeal. It's all subject to the same search, recognition,
and refinement aspects I described initially.
very possibly.
the issue is mostly that my engine pulls off worse framerates on
current hardware using the stock Doom3 maps than the Doom3 engine does
Doom 3 engine is hardly an obsolete technology (even used in Brink in
2011), and its developers have a lot of expertise. There are certainly
metrics by which a new engine could compete for performance -
eliminating load-zones, dynamic and runtime-extensible environments,
moving water, etc. - but I'd be surprised if you beat the Doom 3
engines at Doom 3's own maps!
fair enough, but one could argue that Doom3 was released in 2004, making
it arguably "dated" with it now being around 8 years later (even if, for
me personally, it wasn't until maybe 2 years ago, where I could play it
without being annoyed by its poor performance). now I am more just
annoyed by it being overly dark, overuse of jump-scares, and overuse of
"noisy" as a sound-design criteria.
but, yeah, I suspect maybe Carmack put a lot of effort into trying to
make it all perform well, and has much more experience (I know much of
what I know about 3D engines having learned from his code to begin
with), so maybe it is not too much of a surprise that I can't outperform
Doom3 using its own maps with an admittedly "not particularly efficient"
and "kind of bodged together" engine design.
but, hell, I just recently had a case where performance was being fairly
bad (for a large map, namely Doom 3's "Delta Labs" map) because, among
other things, the renderer was doing dynamic type-checking during an
inner-loop (related to object-index lookups in the renderer), followed
by several instances where a lot of time was being used up by linear
searches.
but, typically the engine is not CPU-bound (CPU load increases relative
to drawing time mostly on larger maps).
Anyhow, you go into a lot of interesting specifics about your engine
which seem a bit off-topic for this subject line. I might e-mail you
to discuss them externally.
yeah.
keeping on topic is not my strong area...
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
