   Level Editor?
  Hi,I've been puzzled over this for quiet some time and I was wondering onanyone's opinion on the best way to write a level editor (of virtually any kind)using Direct3D? As we know that unlike OpenGL you usually have to use Index andVertex Buffers, thus this brings me to a bit of a snarl, when adding, editing, orremoving geometry, do I have to reconstruct the entire map's geometry or isthere some other method? Do I even have to use Vertex Buffers at all forwriting a level editor?Thanks!   
  Using vertex buffers should not be a problem at all when writing a level editor. It may require that your buffer management be a bit smarter than simply doing things in a naieve OpenGL way, but if you wanted decent performance under either API you'd have to go with some kind of compiled geometry.Even while the user is interactively editing the level geometry, they'll likely only be modifying a small subset of the overall geometry. As a result, you should only have to modify a small vertex buffer out of all of your vertex buffers.For example, if you think of something like a heightfield editor (common part of level editors), you could pre-construct your vertex and index buffers for a tessalated mesh representing the granularity of your heightfield. Once that's done, when the user pulls and pushes the heightfield it's just necessary to modify the vertex buffer (which you created as "dynamic") and just those vertices they're editing. The index buffer goes unchanged.If you're thinking of a "brush-based" level editor (ala Radiant or Qed), then your work will be a bit more involved as you'll be creating new geometry. This geometry will either be self-contained (inject a new primitive into the scene) or an extension of existing geometry (extruding the side of a box).In the case of self-contained geometry, you can simply create a new "object" in your level editor's scene graph and associate it's own vertex buffer (or a range in a large pooled vertex buffer) and create your object that way.In the case of an extension to an existing piece of geometry, it'll depend a lot on your underlying buffer management. If your level editor's scene graph is composed of "objects" (similar to Max or Maya scenes), then it may be the case you have a vertex buffer for each object. If the user's actions requires new verts to be added to the object you could (trivially) create a new vertex buffer or (more involved) "grow" your vertex buffer.When I say "grow" your vertex buffer, I don't actually mean something akin to a realloc at the D3D API level. I'm thinking more of classic memory management techniques. In reality, you'd probably have a large dynamic vertex buffer that you use as a "pool" of vertices for editing dynamic geometry. When you "grow" your vertex buffer, in reality you're just increasing the range of vertices it uses from the pool. And like standard memory management stuff, if there's no room to grow your object in the pool, you either relocate it in the pool (a realloc) or create a new pool and stick in there. For other ideas, see description of "small object allocators."Of course, you won't want to leave the artwork in the fractured setup you use for design-time editing. If the bulk of your level is static geometry (often is in level editors), then you simply need to "bake" everything into a single vertex buffer (or whatever the scene culling strategry of choice is).The point is that you'll only pay for the "dynamic" buffers when they're necessary, when the user is actually editing a piece of geometry. Worst case, you get a drop in framerate when the user first starts to edit a piece of geometry that you have to reallocate vertex space for. But, assuming your level editing tools don't spew vertices by the truckload, that'll be a one-frame hit that you'll only hit rarely. You could in fact avoid it altogether with proper "priming" of your small allocator so that all "objects" have rooms for instant growth.;  Thanks for the reply,one of the first things I wanted to do was create a Tomb Raider type environmentand Tomb Raider is split up into a series of tiny "rooms" where in the editorthe artist can place blocks and raise them, lower them, slope them, etc....So I take it using this combined with your suggestion I would create a vertexbuffer for every room in the level editor and then of course when the level isfinished and loaded into the actual game (or whatever else) I would then add all the premadegeometry into one vertex buffer?Then adding blocks to or removing them from a room would simply consist of reconstructingto room's vertex buffer (not realloc but just refilling the buffer with new vertices) and editing a block would simply be editing the existingvertices?   ;  Hi, I am working on a mapeditor as wellI wrote a class "mesh_editable" that handles all operation performed on a meshselection deletion of faces vertices ....transformation of faces .....and of course rendering itthe way i handle it is pretty easyI use std::vector to store all the vertex and index information since they guarantee sequential ordering of elements as you need it for vertex arraysand its got the advantage of easy modification :)The whole mesh class is part of a free library i am working onI am currently looking for people to test this library so I can increase code quality and improve reliabilityCheck your private message for my contact infos