Tools and Level Editing

Great article, if you belong to the site, hehehe.

http://www.gamasutra.com/features/20000323/rouse_pfv.htm

Remember, only a bad artist blames his tools. But Level design is a science. and science demands the right tool and a high precision tool to get the job done right.

The bad workman blames his tools is a load of rubbish and has no place in computer graphics.

An expert in max will always pee on an expert in milkshape, that is the long and short of it, no matter how you look at it.

So, pointless discussion. Computers are incredibly limited: tools need to evolve a lot and they are doing so all the time.

The humble hammer is actually thousands of years of evolved tool making... so not suprising that 10 years of app making has a lot of catching up to do.

So yes, you can blame the tools (on a computer).

I agree entirely, and that is why you own game's editing tools need to be as high quality as they can be. The better the tool, the more refineing you'll be able to do to your levels and the better they will ultimately look.

The article deals with that and the importance of being able to communicate between the programmers and designers. Which in itself is redundent here, since almost everyone here is both.

Thing is an app like 3dsmax will allow for a far higher ammount of flexibility than any level editing app I have ever used. However there are a couple of plusses for a dedicated editor where you want to leave your game easily modable and build a community around it.

Unfortunately this also means you compromise a lot in exchange for simplicity and ease of use, which is often to blame for the generic look of themajority of FPS games. (quake 4 looks liek the old quakes and has pretty simplistic scenery that doesn't look all that different once you take the lighting out, take a look at the gamespot video lol)

With the 3D app of course, there are other problems like requiring a programmer capable of making the Best use of your 3D application, and the limitations of your game engine and file format.

I personaly prefer something in between the two, where you can actualy use both. But for laying out levels, and anything visual plus simple static gameplay objects and effects, I typicaly prefer to use a 3D app, and only use a editor for the more dynamic things that may change from one game to the next, particularly when reusing locales.

Pudding did a great job with B3d pipeline, if you know how to make best use of both the programming and artside of things, you can do far more with a lot more panache than you could with an editor.

Unfortuynately some limitations in the B3d format mean that you cant create user defined scripts and particle systems in max. But other engines I have used did allow this allowing for some truly amazing sequencing of destruction and particle effects.

In the past I found very few game jobs for level designers that wanted skills with well known level editors, the majority requiring Max or maya experience.

At one time there were 8 max or maya level editing positions for every one that wanted experience with CSG editors.

At the end of the day those developers that use Unreal or Quake engines are still pretty low. Still interesting article.

I agree with One eyed jack. Creating art assets for games is still a very awkward thing, art and computers don't mix all that naturaly.

Tools still have a long way to go before they have the same immediate hands on feel that using traditional mediums offer. And 3D apps typicaly have the most flexible and intuitive tools once your learn their many intricacies.

Most of the companies I worked for that hired new Junior artists, typicly hired them for 6 months without them ever creating anything actualy used in the games being developed.

This is one of the main arguements for a level editor in my opinion. An unskilled person can pick up most editors and make something they passable as a poor quality level within minutes. But a lot of the more extravagant detailed levels you see on occasion could be developed quicker in a 3D app.

I find that programmers who do not work with AAA engines generally have little concept what maps in an FPS game actually are. When you play Doom or Unreal, you aren't just running around in a big polygonal mesh. Map geometry uses brushes, which are an entirely different kind of geometry. It is with brushes that BSP, fast collision, and occlusion can be performed. These operations are impossible or impractical with arbitrary polygons. 3ds max is only a suitable level designer for very simple games that don't push the gfx card limitations very far, or that have no advanced visibility culling.

In a level editor, you create your map walls, floors, and large shapes with brushes. Then you use meshes, created in 3ds max or Maya, to add details to the scene. You don't want to go through and model every little detail uniquely. Instead, you rely on a library of pre-made meshes to place throughout the map.

HL2, Doom 3, and UT2004 all work this way.

I've had a different idea on this theme.

Ask any expert modeller and he'll tell you he still prefers working with general geometry and not bsp friendly brush style geometry.

Here's an idea Josh, let me know what you think:

Basically you make the level however the hell you want it - go to town with it, lightmap it, detail it, whatever -

Then you import this level into an app like 3D world studio and what you do then is make the brushes required to divide the world. So behind the walls in your normal mesh, you create the csg solid brush geometry with quick cubes and wedges, meging it together, etc - without thought and without much care - so long as it divides the world.

Then you hit compile, and what it does is split and clip/split your normal level into detail meshes for you. Then you have the best of both worlds creatively...

This would be a good way of working in the future because scenes are becoming so badass that nearly everything will be a detail brush anyway...

Quite true. I agree with you One Eyed Jack. Though for CSG specifically, it's near impossible. It's unpractical AFAIK to automatically build CSG based worls from polygonal ones. But it's one of the reasons why there are *other* partitioning schemes, which do work with plain polygons. And there will probably be lots of new ones implemented in the near future.

Koriolis,

I think Mark would be interested to hear of polygon partitioning schemes with regards to blitzmax.

Personally I would love to be able to partition and optimise my polygon soup levels. This is one of the drawbacks to Blitz3D

So if you know any really robust poly soup partitioning methods, perhaps you could share them with Mark / the forum for the good of all?

You are suggesting that arbitrary geometry be split into a BSP tree or portals. This defeats the memory usage and speed advantages of referenced map meshes.

Referenced meshes allow you to have a scene consisting of 1,000,000 polygons, while actually only storing 50,000 polygons in memory. By locking a vertex array, and rendering all instances of that mesh, your rendering speed is limited only by fillrate.

Using unique geometry throughout a scene is like using unique textures on everything. It uses far more memory, it renders much slower, and it takes much longer to produce the media.

@One Eyed Jack: I'm certainly not the right person, as I didn't do any serious 3d development since quite a time.

@halo: this is certainly a good solution and I have no doubt you have made a lot of tests and research on the subject, but but isn't Doom3 precisely using portals?
And actually, polygons aren't really necessarily the future of the "use established general purpose modelers and not custom made ones" way. Because it's been a while that modelers work with subdivision surfaces, and with the increasing power and the use of vertex shaders, complete subdivision surface implementations may very well be efficiently done in real time pretty soon. And subdisvision surfaces save a lot of memory. But that's just a wild (but advised I think) guess.

I use a lot of subdiv modelling. Often I will take a mesh thats low poly into Zbrush2 and detail the hell out of it.

What I get back is a set of multi res meshes and of course a displacement map and a normal map.

Zbrush 2 was used for the monsters in Doom3, and also a lot of UT3 content. It's not going away.

check it out: http://pixologic.com/zbrush/interviews/scott_interview.html

I think instanced meshes are fine, but you cannot beat unique level meshes. Unreal 3 engine will mostly feature unique level meshes, with detail meshes where they count.

I don't expect the 3D module to beat unreal3, but I do have every confidence that the 3D module will match Doom3's engine.... I am pretty sure Mark is capable.

What do you base this on? The screenshots I have seen at unrealtechnology.com use a lot of repeating meshes.

Just to show I'm a know-it-all, did you know that the expression 'a bad workman blames his tools' comes from the Middle Ages when ALL workmen made their OWN tools.

Making your own tools was stage one of your apprenticeship into a guild.
If you couldn't make the tools that you were going to use you didn't get any further. You certainly weren't allowed or expected to use someone else's.

So the idea of a workman blaming his own tools was an admission of inadequacy on many levels.

As a contrast - damn! I wish I understood just half of what is being said above.

Perhaps you're right? But I don't know if they still use brush based geometry at all...

you can repeat meshes with arbitrary poly levels and use occluder objects to oclude vast amounts of geometry. I've worked on games with 100's of thousands of polys no problem using these techniques on modern consoles.

Arbitrary meshes do become a problem if you insist on lightmapping everything. Depending on the game your making and the hardware, you might try streaming off of the HD or DVD.

Modern engines seem to be going for hybrid systems which are possible with newer shader 3d hardware and more advanced lighting techniques.

Even in blitz you can create pretty big levels by using instanced geometry in levels created in Max. In the original FMC we had 80 duplicate towers placed around the level using a fraction of the hard storage space, and memory required. All it takes is some time spent on working out an effivcient art path.

Alex's B3D pipeline is a pretty good example which unfortunately is let down a little by blitz3d. Hoping to overcome these in our b3d loader for torque.

It supports instanced geometry, Opcode which were using for concave collisions supports instanced geometry too. Max Xref is supported to some extent in the b3d pipeline which will allow streaming models and scenes off the hard drive on a properly threaded engine. So you can easily have it stream the nearest visible rooms in an interior without loading a level in memory.

Should also be able to use the occluder obscurers, that cull out objects hidden by your obscurer objects. The console game I worked on used a similar system, but was more flexible as it also had negative occluders that opened up windows in culled areas.

more and more people are heading in this direction these days, rather than BSP convex hulls and CSG editors. Once everyone has modern GPU's a lot of the old ways of doing things will most likely disappear.

An artist who is unsuccesful by himself would blame succesful tools.
An artist who is succesful by himself but has to work with crappy software has a reason to complain.

In case of art, which is usually an abstract concept, it's usually a case of being able to put down your idea asap, or it'll flow away with the windy mind. (how poetic ^_^) If the software isn't capable of cooperating with the user (think of a slow mousey application, no handy things, bad navigation etc.) then I can imagine it's frustrating for the user.
Sometimes I think programmers/designers spend way too much time on slick skins and shiny interfaces and way too less on handyness/navigation. As if they aren't working with it themself, or are only surrounded by testers who're just lousy artists themself who can't come-up with real art.

In fact, Blitz is handy for those artists who know a bit of programming.. in the ideal case, artists make their own programs. :P