Map Editor Specific Question

Well, most engine's store the level layout as brushes for editing sake, however nearly every game I know of stores and batches the polygons out as triangles.

Indy

Quote:

Original post by Arelius Well, most engine's store the level layout as brushes for editing sake, however nearly every game I know of stores and batches the polygons out as triangles. Indy

I have one more question
How can they render non hullconvex polygons right on the editor include Texture. Do they triangulate it before they render it.
If so, that would require more CPU proccesing . Coz hardware cant render such polygons correcly.

In the case of the Unreal Editor, you have to regularly hit the Build Geometry button or when you use the builder brush to see updates in CSG(Constructive Solid Geometry). Basically what it does is take the brushes and converts them into triangles, taking care to make sure only triangles that'll be seen are made. In the editor you have several different views, you'll see Brush Wireframe and regular Wireframe, as well as other views to help you look at other parts individually.

All brushwork must still be convex, so any concave areas are simply just several convex brushes. I've seen some brushwork that is concave sometimes it works, but most of the time it messes up other unrelated geometry.

If you happen to get the UT3 Collector's Edition, the level design VTM's have a part where they instruct you to make part of the ceiling a concave brush. Every time I did it the way they did, other geometry would randomly disappear.

Now a lot of engines do a post production phase where it really cleans up a lot of stuff that doesn't need to be there. Hammer and Radiant (id Tech level editor) has it's compiling tools, Unreal does it's Cooking process. With Hammer and Radiant you'll have different settings for faster compiling because their engines need a compiled version of the level that is much different than the one the editor uses. Unreal has always used the source file as its final product so usually you don't have to go through a long compile process. This is changed somewhat with Unreal Engine 3 in that Cooked packages are introduced. The game engine can still read and use the source files, although by default most games don't allow it, you have to pass in certain flags to make it happen. Cooked packages are just very highly optimized versions of the package for faster loading and streaming.

Whew boy did I rant. Didn't mean to go that far off. Send me a message if you've got any further questions on level editors and such.

That quite interests me.
In fact, I like detail people

I got one question about Lighting
Everytime user put Light in the scene or Moving the light,do the Editors recalculate the light Map for the Wall and update the scene. I though I was gonna do that for ,but I wonder if that is the way most Editors do. More important ,calculating LightMap would be time consuming. So I think editors would have another way more efficient ?


In your experiences should I learn how to use an Editor Before I write my own?

Have you written any Editor ? If so would you recommend me the way you went by so I can follow. If not , do you have any sugestions about what I should learn in other to write an Editor like people wrote?
Thanks

It would really be good to experiment with different editors first because some do other things better and editors can be pretty specific to the game. I'll give a list of ones I've used and I'd try to get a bit familiar with at least one from each category.

FPS(First Person Shooters)
Unreal Editor for UE3(UT3, Gears of War, Roboblitz)
Unreal Editor 3.0(UT2003/UT2004)
Radiant, GTKRadiant, DoomEdit, etc(Doom III, Quake 4, Enemy Territory)
Hammer/WorldCraft(Quake 1, Half-Life, Half-Life 2)

RPGs(Role Playing Games)
Aurora Toolset(Neverwinter Nights)
Neverwinter Nights 2 editor(can't remember the name)
TES Construction Set(Elder Scrolls III and IV)

That's what I can think of off the top of my head.

Lighting in your editor is gonna really depend on how closely tied the editor is to your engine because the lighting models different per game. Most editors that are separate from the game engines usually can only do a best guess as to the lighting, the compiler will do the real work for making the accurate lighting.

Also games use both static and dynamic light so again it's tied to the game engine. Static light comes in the form of lightmaps, materials that simulate lights that never move and don't cast shadows from moving objects.

Unreal Editor has a huge amount of lighting options for each light and since you're basically running the game engine while running the editor, you can get the accurate lighting feedback and it even lets you jump into the game from any point in the map.

When you add a new light to Unreal Editor it is dynamic in the editor, but if it is a static light, when you rebuild the lighting, similar to how you rebuild the geometry, the lightmaps are created. If you add additional lights to the scene after a lighting build it checks if it effects the current lights in the scene. If it does, it seems to turn all lights in the editor back to dynamic and you'll have to rebuild lighting(you'll have to do this anyways every time you make a change to the lighting). Also when the lights in the editor are dynamic you actually just get that best guess lighting with lights that are supposed to be static.

One of the nice side effects I've found to the lighting is if your lighting is taking an incredibly long time to build, it usually indicates an error in the geometry. You can leave the error but you might get a huge performance drop as the level continues to be constructed. The error kinda reminds me of how Intellisense stops working in Visual Studio if you've made a syntax error.