3D Artist's needs

[Christian Reiniger <warewolf@mayn.de>]

As promised, here's the report from my talk with the Q3A map designer.
Things are definitely slanted towards FPS, but much can IMHO also be
"transferred" to other areas.

1) Tools
========

He's using almost exclusively a 3D map editor and the Q3 map compiler.

Editor:
-------

According to hime q3radiant (http://www.qeradiant.com/ (the "e" is not a
typo)) is the best in this area (Q3 maps). He demoed it a bit and I can
at least agree that it seemed to be very good. Taking it as example for
how a 3D editor should be is IMHO a good idea.

Especially important features etc he mentioned are:

- A good 3D preview window
- Immediate feedback on actions in all the windows (3D preview & 2d views)
- A good grid, with objects (optionally) snapping in to it. Spacing
  adjustable & automatically adjusting when zooming in and out
  (preferably in some predictable way ;). He emphasized this one
  (the grid) several times.
- Keyboard shortcuts for all (important) functions & keys for moving the
  views around, zooming etc. So that something like the movement *in* a
  FPS is possible (using mouse and keyboard completely parallel). For most
  of the people using such editors (at least those who produce good
  output) it's their most-used app, so the eventually increased learning
  curve isn't that important here
- CSG support (Constructive Solid Geometry? Boolean operations on objects)
- Simple way to split an object into two at some plane (eg one quickly
  drawn as line in a 2d view)
- Copy-n-paste of *parts* of objects (take this box out of obj Y and copy
  it to there)
- Grouping of objects (hierarchical). Preferrably also with "display only
  group outlines instead of all geometry inside of it in the editor"
  option (display uncluttering)
- Autosave function and other ways preventing the loss of the last hours'
  work (!)
- Elegant handling of "impossible" input. E.g. when distorting objects in
  ways not allowed by the 3D engine it should either automagically insert
  the proper additional polys to make it valid again or simply don't let
  the distortion go too far. "This is invalid" popups and allowing the
  objects/scene to get into an invalid state are absolute no-nos
- "Knowledge" of the 3D engine's limits/capabilities/quirks is a definite
  bonus.


Map Compiler:
-------------

One single point: Speed. He said compile times of over 24h are not
uncommon (Athlon 600, 256M RAM). If the map/object/whatever needs some
preprocessing, this step has to be fast. He's often keeping his maps
rather simple not because they'd give worse frame rates but because it
would take too long to preprocess them otherwise.
Apart from speed (and robustness of course) everything else is
irrelevant. The Quake map compilers are simple cmdline tools, and
everyone's fine with that.




2) 3D Engine / Game Engine
==========================

Things are a bit less structured here...

a)
Q: Why he develops for Q3A instead of Unreal/Halflife/...
A: Used to it (he already worked with Q1 and Q2), Q3 handles high
   polygon counts better and , well, ...

b)
I showed him CrystalSpace screenshots. His reaction: Nice visual
effects, but the scenery was always quite coarse polygon-wise. Also
frame-rates were given only seldomly, so it's hard to compare to Q3.
Possibly doing some Benchmarks with imported Q3 maps would help. Even if
they show that CS is a good deal slower, these people at least get a
"still not ready, but worth to be monitored" impression.
That should apply to all kinds of game engines.

c)
How easy is it for the level designer to use nonstatic stuff, how much
support does the engine give him for this? Examples: breakable glass,
elevators, doors, explosions leaving craters, ...

d)
Object movement/animation should be scriptable very flexibly (eg. weapon
reload / idle animations). I remember this was one of the big problems
mod designers had with Quake2.

e)
Easy import of 3rd party objects, preserving them as "object" so that
others can again grab it for *their* level. Exchanging models and, more
often, textures seems to be rather common in that scene (-> similarity to
the OSS scene).

f)
One of the limits of the Q3 engine nerving him the most are its limits on
map/scenery complexity (large open distances in maps / long preprocessing
times for complex scenes etc)

g)
Another thing he's had quite some problems with is that Q3 seems to be
quite "dumb" about determining potential visibility. Example: Large house
in a map, but not reaching completely up to the sky plane. The engine
sees that there's still some free space on top of it, so it determines
that players *can* look potentially over it => Everything behind it is
treated as potentially visible (and thus rendered by the engine), just as
if the building was transparent or just a little bump in the street.
So the possibility to give the engine hints about these cases can
increase frame rates significantly (he showed me an example where ~2000
polys were rendered, with about 2/3 of them being obstructed (i.e. not
visible)).



Well, that's about it. I think most of this is similar in other (non-FPS
/ non-3D, perhaps even non-graphics) areas.

-- 
Christian Reiniger
Coordinator/Coder, PenguinPlay (http://sunsite.auc.dk/penguinplay/)
Coordinator,       LGDC        (http://sunsite.auc.dk/lgdc/)

God is real (unless declared as integer).

---------------------------------------------------------------------
To unsubscribe, e-mail: linuxgames-unsubscribe@sunsite.auc.dk
For additional commands, e-mail: linuxgames-help@sunsite.auc.dk