RE: 3D Artist's needs

[Christian Reiniger <warewolf@mayn.de>]

Erik wrote:

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

I don't mean supporting the CSG features of the engine, but the editor
itself changing the geometry via boolean ops. That's pretty independent
of how the data is represented (objects / primitive shapes / heap of
polys / ...).
But you're right that this isn't so important for landscape-centric games.

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

Nope. It's just sometimes useful to be able to seperate some part of an
object and move it somewhere else. Example: You have a phone pole (seen
from the side here):

----
 ||
 ||
 ||
 ||
 ||

Now you split it  (the ~ line)

----
 ||
 ||
~##~
 ||
 ||

and rotate the now seperate upper part:

   \
   /\
  // \
  ||
  ||
  ||

Voila, a broken phone pole.
That's again independent of how the engine handles things.

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

doesn't matter. Example: model of a keyboard. You draw a selection box
around the numeric block, copy, paste and have a new standalone numeric
pad.

For all these geometry ops I'm *not* talking about cutting/whatever only
at verices etc. I'm talking about cutting *somewhere* and the editor
taking care of inserting/modifying polys/objects accordingly.

It ain't simple, but it's a big help for artists.

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

I mean also displaying only the outline in the 2D views.

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

Remember that the editor has to be stable as well. And the power supply
etc. People tend to get quite irritated when they just got it "perfect"
after 4h of work and then suddenly it's gone - no matter why. Oh, and a
good undo function is a must-have, too ;)

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

Have a look at how q3radiant does it - it does *not* make a mess.

>> c)
>> How easy is it for the level designer to use nonstatic stuff, how much
>> d)
>> Object movement/animation should be scriptable very flexibly (eg. weapon

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

Hmmm, I don't know. I guess having the engine support as much of this
directly as long as this doesn't behave limiting is the best way. As
vague as this is.

>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

On the surface it's surely Q3 specific, but the things mentioned for the
editor at least apply to all 3d editors without change, and the *ideas*
behind the other things also apply to many other game/art types.

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

That's also my worry. It'd be propably a 10-second review resulting in "I
can't do X" and "It lacks important feature Y" answers, which are just an
early start. That's why I proposed using q3radiant as a model of how a
modeler/editor *should* be. It's surely easier to build a feature list
from that ourselves and mainly asking the artists what features are
*especially* important to them etc for now.

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

We all live in a yellow subroutine.

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