Reworked the tool sets and cleaned all of that up, and also created a separate tool for panning. I've also imposed a level size limit of 1000 units in all directions. One reason is technical (simplifies grid rendering), one is aesthetic (avoid stupidly large levels) and one is arithmetical (I avoid people going crazy with the editor and stealing precision from my floats). Snap-to-grid should be done before lunch time, I have it sorted out mentally (I hope).
Snap-to-grid is done. It did involve a couple of subtleties (select clicks should not snap to grids, for instance) but seems to be robust at the moment.
Time to start planning the bridge between the editor's LevelWrapper and the game's BaseLevel. This is possibly really complicated, since it is code that will be heavily modified throughout the project. There are also multiple paths through it:
* Output to editor-only file (this is an object graph dump native to the editor).
* Output to game-loadable XML file (XML tree for loading in-game).
* Output to run-in-editor (instantiated BaseLevel object created from a partial BaseLevel and LevelWrapper)
My initial plan was to let the editor's "internal" transfer be done by piggybacking the XML output, but that's pretty redundant: I already have an "almost" proper representation, excepting the floor geometry. On top of that, the object graph dump is not necessary, I can let the XML representation do that, which also ensures data consistency.
So, for now I'll keep working with the BaseLevel object I already have. […] Compiling the level and switching between the editor's renderer and the game's renderer works fine, if crudely.
I've been kicking some ideas around in the back of my head regarding polygon creation in the editor. For a while, I contemplated limiting the editor to triangles and quads, but then I remembered that I toyed around with the GLU tesselator a couple of years back. By piggybacking that, I could allow for arbitrary polygons. Then again, do I need that? gluTess is not exactly trivial. I guess I need to take a moment to plan out the editing tool more properly, now that stuff starts to fall into place. Then again, an hour or two to write a couple of unit test would be nice...
Free drawing: plotting polygons of 3/4 valence.
Polygon drawing: creating regular polygons of any valence by giving a center and radius.
Filling: creating a polygon given three or four vertices..
Extruding: extruding edges into quads.
Splitting: breaking a polygon edge into two, and creating either three triangles from a quad or two triangles from a triangle; splitting a quad into two quads or splitting a quad into two triangles; flipping the diagonal in two adjoined triangles.
Merging: merging two selected vertices; merging all vertices below a certain treshold..
I think those are all the ideas I've been mulling over. They're thirteen actions, but most of them can be made context-sensitive. By far most complex is the splitting, but it can be simplified into either splitting an edge (in which case the result is well-defined) or splitting a polygon (in which case the only choice is whether to split a quad across edges or corners).
The first step in implementing this is to extend the geometry proxies a bit, and add polygon and edge proxies. Edge proxies would simply point out two vertices and re-route drags to them. The edges need to be rendered through the proxies... Selecting an edge should select its vertices as well; selecting two vertices connected by any edge should select the edge. Likewise, selecting a polygon should select all of its edges which in turn should select their vertices..
Detecting the selects should be simple: edges just construct an oriented bounding box and caches it, and makes sure that the point is inside.
No comments:
Post a Comment