RE: 3D Artist's needs

[Erik <br0ke@math.smsu.edu>]

Ok, here comes my slew of halfassed pointless comments and off remarks :)


On 28-Jun-2000 Christian Reiniger wrote:
> 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)

these two make me think that opengl is going to play an important part in game
modelers.

> - 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)

I'd think that csg support has much much much more importance to an 'inside'
game like quake that uses BSP to break stuff apart, as opposed to an 'outside'
game like tribes that uses poly meshes or bezier surfaces. After all, building
a BSP tree is basically a specialized form of CSG, unless I'm mistaken :)

> - Simple way to split an object into two at some plane (eg one quickly
>   drawn as line in a 2d view)

again, an artifact of using BSP based systems :) Given an octree engine, he'd
be saying 8 cubes. Given a bezier, he'd want immediate access to control points
:) depends on the engine (non-artist) imho

> - Copy-n-paste of *parts* of objects (take this box out of obj Y and copy
>   it to there)

based on vertices? polys?

> - Grouping of objects (hierarchical). Preferrably also with "display only
>   group outlines instead of all geometry inside of it in the editor"
>   option (display uncluttering)

I've seen options in modelers where an object can be displayed onscreen as
  * smooth shaded
  * flat shaded
  * wireframe
  * bounding box

> - Autosave function and other ways preventing the loss of the last hours'
>   work (!)

hehehe, but the os we use doesn't have the nasty habit of falling out from
under you ;) Autosave would be nice to avoid 'oops' situations, tho.

> - 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

this could be very difficult to implement well (and very easy to screw up). The
only way I see to really meet this requirement would be to let it make a mess
while the peice is moving, then clean up later with some kinda reduction
algorithm. 

> - "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.
> 

quake* tools do a lot of very complex 3d precalculation. Some games use no
precalculation, some can do it very fast. IIRC, all the quake tools build BSP
trees from the scene, perform a detailed 3d radiosity render which is converted
into a lightmap, etc etc etc... :) However, this goes back to strong internal
computation with an emphasis on effecient algorithms and accuracy. These are
things I think the open source community has a strong grounding in (this gets
closer to the science part and most linux geeks are either csc students or
computer science enthusiests). This kinda stuff is up our alley :) UI's are a
bit more alien

> 
> 
> 
> 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, ...
> 

I'd think it's 99.9% familiarity... :)

> 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.
> 

one good solid game built on the cs engine would probably do a whole hell of a
lot for cs, opensource, and linux in the video game aspect. Now I gotta go
check out the cs site to see if I can spot any probably 'killer' games :)

> 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.
> 

c and d are issues I've never really looked at. Do the level builders want
control of this stuff? mod scripters/programmers? Should tools have an 'object
creater' with sliders for differnet aspects, like 'shatterability' and 'life
points' and 'pushability'? Or should plugs be made via a scripting system?

> 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).
> 

I'd hope all artists in any medium, be it 3d models, maps, 2d images, or source
code, would keep lossless formats in the original format. 'native models',
proof images, source code... We never know when we gotta tweak something down
the road, and I really hate reimplementing to make one little tweak :)

(snip a couple gripes about q3)

I felt like this turned out to be more of a review of geradience and the q3 map
tools rather than an insight into modeler design. I know the nameless q3a map
designer has his preferred tools, and that's what he uses. We all do that. I
feel that philipps idea about having him review current linux tools might be a
lot more useful. My only concern is few of the tools on linux are actually
ready for use, so he's going to see half-done programs that he really can't do
anything with. :/

> 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

        -Erik <erik@smluc.org> [http://math.smsu.edu/~br0ke]

The opinions expressed by me are not necessarily opinions. In all
probability, they are random rambling, and to be ignored. Failure to ignore
may result in severe boredom or confusion. Shake well before opening. Keep
Refrigerated.
        

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