Spark
<b>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.</b>
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.
<b>Snap-to-nearest command</b>
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!?
<b>Command-Line</b>
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.
<b>Implementing command line</b>
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"
<b>And finally...</b>
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?
<b>Edit:</b>
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 ):
foreach( vertex in vertices )
{
vertex.x = round( vertex.x / snap ) * snap;
vertex.y = round( vertex.y / snap ) * snap;
vertex.z = round( vertex.z / snap ) * snap;
}
And simply return an array, in the same order, that denotes the new positions of each vertex.
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.
<b>Snap-to-nearest command</b>
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!?
<b>Command-Line</b>
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.
<b>Implementing command line</b>
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"
<b>And finally...</b>
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?
<b>Edit:</b>
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 ):
foreach( vertex in vertices )
{
vertex.x = round( vertex.x / snap ) * snap;
vertex.y = round( vertex.y / snap ) * snap;
vertex.z = round( vertex.z / snap ) * snap;
}
And simply return an array, in the same order, that denotes the new positions of each vertex.
Comments
One thing you may be making some error on is using a grid size that is too small. When I build my map, each floor section is divisible by 16, which means I have large sections made from measurements like 128 x 512 or 256 x 256. You should be breaking your map up this way, not fitting planes to an entire room.
Why? Well at a glance, you know how big your room is. You can tally a distance up quickly by adding the 256 sized blocks. Also, this is what keeps you snapping to the grid, because everything breaks when you get into the 2 or 1 sized grid. Another thing, don't scale more than one plane at a time, because rarely will it divide evenly, and you will be off the grid. Try not to manipulate single vertex unless creating a triangle. What you should do is manipulate the line connecting the two vertices instead, because it'll take you half the time. Another thing to consider, the translate tools operates on a different grid than the scale tool. Translate first, then scale the last half.
Many people also do not know you can change the origin from which you translate from by using the < > keys. Also, if rotating you can change the origin as well with : " keys.
Lastly, your idea is cool and all, I've always wanted to make a map in notepad lol, but I think you're forgetting something, you also need to input the location within the void, which is not exactly intuitive even if working from 0, 0. I can only promise you one thing, and that is you will eventually enjoy mapping and find it very efficient. I also mapped for World Craft and Hammer, and I simply cannot go back without missing a lot of what Spark gives you.
AutoCAD has a handy-dandy solution to this; you can place your points of origin, revolve axis and whatnot using the cursor to plot one or more vertices.
I've been using a grid of 64, which I scale down to 32 for "detail" (obviously it isn't really detail yet as I'm still just grey-boxing)
Spark is brilliant, and I'm definitely enjoying putting my map together. But some things still seem needlessly complex. I've only been using it for a few hours, though, so you're probably quite right; there's a learning curve associated with the finer points of geometry.
Edit: Moving a line instead of two vertices is a massive protip, thank you!
One thing that bugs me, is how the translation arrows overlap each other when you're at an odd angle, and you sometimes need to move the camera to select the correct directional arrow. I wish the translation arrows rotated to your view so you could always select the correct one without moving the camera. This only happens in the perspective view, but I do 90% of my mapping there.
Another major thing is how grouping works. Right now it's just not as useful as it could be. I do not enjoy having to go into a grouping window to select as a group. This is a problem because sometimes you only need something grouped for a single mapping session, you don't need to name the group and keep it. In Hammer editor you could just group something, then select anything in that group and have it all selected. If you didn't want to do this, you'd turn off group select. In my opinion this is the most intuitive way, but I also enjoy the aspect of being able to name groups. A sort of blending of both methods is probably best.