Edit: Okay, okay! TL;DR. Summary: Please add a command-line and LUA (or other) scripting support to Spark, so we can attempt to automate common geometry operations.
I'm not sure "Mapping" is the appropriate place, but as this forum is likely full of mappers who will either tell me I'm missing something, or chime in with agreement I'd like to talk about Spark.
First off... the editor is great, reasonably stable (I had one crash in my greyboxing process last night) and quite simple to use... it obviously includes a lot less functionality currently than Valve Hammer Editor and Quake Army Knife so that probably lends itself well to simplicity. I'm pretty sure it's infinitely more usable ( yes, my only frame of reference for mapping is about 10 years old ) and not having to worry about leaks and BSP nonsense is a blessing.
What frustrates me, however, is "The Grid". Snapping seems temperamental at the best of times, and I'll sometimes have to pick up a point twice in order to get it to snap at all. Furthermore, I'll painstakingly snap a piece of geometry to the grid only to have it misalign when I try to translate or copy it.
Am I missing something with grid snap? If I, for example, snap a piece of geometry then move it, the object will move from the point where my cursor was at the time of moving. Causing an offset equal to the distance between my cursor and the nearest grid point.
There would be two ways to solve this; snap the cursor to the grid at all times (why not?) or snap to the nearest grid point before initiating a move.
I think some method of snapping a vertex, or group of vertices to the nearest grid point is needed. All this manual snapping nonsense just so that my geometry lines up when it folds back in on itself is a complete and total micro-management nightmare. Computers are insanely good at dealing with this stuff... why should it even be my concern!?
One of the only times I ever produced anything noteworthy in 3D involved AutoCAD. The reason I got on so well with it was the command line. You could, for example, type "pl" or "pline" to create a polyline out of sets of X/Y co-ordinates. This is not only much more intuitive than farking about with the mouse cursor in 3D space, but is also scriptable.
Same applies to any other command, and I think commands like extrude (which we already have) and even more powerful ones such as revolve could really streamline the whole geometry creation process.
Revolve is a good example, actually. What do mappers currently do if they want a circular column? Sure you could draw a circle and extrude it into a column... but that's dull. What if you want a flange at each end, some ridges, or a taper? With revolve you just draw a "pline" that describes the extreme edge of your column and then simply apply the revolve transformation with a center point and radius as the parameters, plus an optional "stop points" or "faces" parameter that defines how many faces your completed shape will have.
A command such as:
Revolve 128, (64,64,64), 4
Would take the selected vertices and revolve them around the point of origin (64,64,64), creating 3 additional copies at 90degrees. IE: it makes a square pillar. Reduce this to 3 and you have a triangular pillar.
Revolve 128, (64,64,64), 24
Would places points at each 15 degree angle, creating something that comes much closer to describing a circular column.
Implementing command line
I don't propose UKW implement all these commands themselves, though. Give us the tools to do it. Or have you already? I honestly don't know if Spark is scriptable.
Stick a command-line into Spark which simply runs LUA scripts in a /commands dir. Let us then write scripts that take an array of input vertices and translate them how we see fit. We could then have "Cube", "Arch", "Corridor", "Revolve", "Polyline"
Faces! Argh. Am I missing something? Actually getting Spark to turn a set of pretty coherent vertices into a face seems to be a challenge to end all challenges. Why is it so difficult? Why does the triangle method fail so often until I reduce a potential face into a bajillion small triangles?
Regarding "Snap to nearest", if we had an LUA scripting interface that took an array of vertices as an input, we could do ( forgive my non-lua orientated pseudocode ):