Off-grid vertices
Mendasp
I touch maps in inappropriate placesValencia, Spain Join Date: 2002-07-05 Member: 884Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Gold, NS2 Map Tester, Reinforced - Shadow, WC 2013 - Shadow, Retired Community Developer
I touch maps in inappropriate placesValencia, Spain Join Date: 2002-07-05 Member: 884Members, NS1 Playtester, Contributor, Constellation, NS2 Playtester, Squad Five Gold, NS2 Map Tester, Reinforced - Shadow, WC 2013 - Shadow, Retired Community Developer
Okay, so since I was quite worried (and maybe I should say obsessed) about this issue I started doing some tests, first to figure out where in the .level files the vertices were being stored, and then a few simple tests to determine the origin of this issue.
You may have noticed that sometimes you have slightly off-grid vertices in your maps (I remember seeing them in Summit and Tram, too, not sure if the authors have taken the time to fix them), causing micro-cracks, you can see them as little dots that let you see into the void.
It was suspected that it was caused by rotating or moving multiple objects (specially when the multiple selection has props, which makes the center go a little off), but I found out it actually happens with a single face being selected too.
First, the levels store the coordinates and distances in meters. But that didn't seem to be the issue, since when I switched to a metric grid the same issue happened. The test was very simple, I made a square, then proceeded to move it from the center and saved, then I cycled the movement origin to one of the vertices and moved it around and then back to the original place (to realign), when compared, it shows how the vertices go slightly offgrid when moving from the center (default).
<img src="http://i.imgur.com/BGu9N.png" border="0" class="linked-image" />
<img src="http://i.imgur.com/bxyfe.png" border="0" class="linked-image" />
It also happens with the rotate tool (no matter where you rotate from) and the scale tool all the time. See a few posts below to see another (different?) issue with the scale tool.
I actually wanted to make a tool to take the coordinates and if they were "off-grid" more than 0.0001 or something to re-align them, I almost found this by accident. You'd need to convert to inches and then back to metric (unless the map was done in a different grid, since they do not line up).
You may have noticed that sometimes you have slightly off-grid vertices in your maps (I remember seeing them in Summit and Tram, too, not sure if the authors have taken the time to fix them), causing micro-cracks, you can see them as little dots that let you see into the void.
It was suspected that it was caused by rotating or moving multiple objects (specially when the multiple selection has props, which makes the center go a little off), but I found out it actually happens with a single face being selected too.
First, the levels store the coordinates and distances in meters. But that didn't seem to be the issue, since when I switched to a metric grid the same issue happened. The test was very simple, I made a square, then proceeded to move it from the center and saved, then I cycled the movement origin to one of the vertices and moved it around and then back to the original place (to realign), when compared, it shows how the vertices go slightly offgrid when moving from the center (default).
<img src="http://i.imgur.com/BGu9N.png" border="0" class="linked-image" />
<img src="http://i.imgur.com/bxyfe.png" border="0" class="linked-image" />
It also happens with the rotate tool (no matter where you rotate from) and the scale tool all the time. See a few posts below to see another (different?) issue with the scale tool.
I actually wanted to make a tool to take the coordinates and if they were "off-grid" more than 0.0001 or something to re-align them, I almost found this by accident. You'd need to convert to inches and then back to metric (unless the map was done in a different grid, since they do not line up).
Comments
Heh, yeah, it's a great tool :D
psykoman just told me about a problem he was having with the scale tool and apparently the scale tool goes a little crazy the further away from 0,0,0 you go. You don't need a hex editor to try this one. Make a rectangle in 30000, 30000, 30000 (easiest way is to create an entity and change the origin to that, then using "Zoom to selected objects" you'll be there), now, scale this rectangle for a while and you'll see how in the status bar the sizes start getting strange things like 352.04" or 351.99" and crazy stuff like that. It seems to happen with the metric grid too, but I needed XVI32 to see how off it was (.0005).
I tried near the origin 192,192,192 and it seemed fine. It's really looking like a precision/conversion problem.
EDIT: It's actually not fine if you look in a hex editor.
2^24-1 is ~17 million. The minimum step between two floating point numbers(1 ULP) where one of the numbers is 30000 is 30000/(2^24-1) ~ 0.002.
This error should still occur near the origin when you rotate or scale stuff unless there is some snapping involved(e.g. if vertex is close to the grid than 0.001, snap to grid). If no snap is involved, then the error will be too small to be displayed in the editor, but you should still see it in XVI32.
If you always snap to grid within some small epsilon, then there is a region of the map within which you should not see precision errors from rotating by 90 degrees; scaling up by an integer; rotating by an arbitrary angle and rotating back again by the same angle or scaling by an arbitrary factor and scaling back to original size. If you had an epsilon of say, 0.01 and limited the map size to +-65536 in all directions and had trigonometric functions guaranteed within one ULP(i believe x87 fcos and fsin are) then if I'm not mistaken and there's some rare corner-case you should not see these precision errors(but of course, could still generate off-grid vertices by scaling by arbitrary factors, rotating by an arbitrary angle or moving without snap).
The fun thing is that since everything's in metric, those 30000 (inches) are actually 762 (meters) in the .level file. But somehow the scale tool (with snap to grid) goes crazy, and crazy enough to be noticeable right away in the editor, sometimes you don't even need to see the status bar, it's clearly off-grid. The rest seemed to work exactly the same in those coordinates (move, rotate tools -- with the "normal" bugs, as I mentioned).
EDIT: I just got the off-grid issue with the scale tool near the origin of the map, I had to look in XVI32, though. I actually only tested the move tool before posting the thread, and assumed the rotate tool would be the same. I just took a "deeper" look and it happens with all 3 (move/rotate/scale). The rotate tool seems to go wrong all the time, no matter where you rotate from. For some reason, after rotating in X/Z, the Y coordinate got moved too -3.5 turned into -3.4999971.
cos(90) will probably not evaluate to zero, because 90 degrees is not perfectly expressible in radians without an infinite precision(pi is trancendental).
<!--quoteo(post=1891695:date=Dec 26 2011, 09:40 AM:name=Mendasp)--><div class='quotetop'>QUOTE (Mendasp @ Dec 26 2011, 09:40 AM) <a href="index.php?act=findpost&pid=1891695"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->The rotate tool seems to go wrong all the time, no matter where you rotate from.<!--QuoteEnd--></div><!--QuoteEEnd-->
When you're rotating at anything but multiples of 90 degrees and back again by the same amount it is almost unavoidable that vertices end up off-grid unless you use some small snap for vertices that are very close to a grid point.
Many modern applications of the entertainment kind use even dodgier approximations of sin and cos than the already somewhat dodgy fsin and fcos X87 instructions because they can be made blazing fast and far more accurate than is necessary in most functions of a game(e.g. who cares if a model is rotated 37.063436 degrees when it should be rotated 37.063477 degrees if latency means it is already 2 meters from its real position and rotated 30 degrees wrong). The compiler may have built-in support for this, in case you don't want to roll your quick and dirty math library.
(/fp:fast and /arch:SSE2 in MSVC don't seem to be that bad at least).
<!--quoteo(post=1891695:date=Dec 26 2011, 09:40 AM:name=Mendasp)--><div class='quotetop'>QUOTE (Mendasp @ Dec 26 2011, 09:40 AM) <a href="index.php?act=findpost&pid=1891695"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->For some reason, after rotating in X/Z, the Y coordinate got moved too -3.5 turned into -3.4999971.<!--QuoteEnd--></div><!--QuoteEEnd-->
cos(0) should always evaluate to 1; but for particularly quick and dirty approximations it might evaluate to 0.99999986 or something similar. The rotation matrix should 'mix' coordinates from the plane of rotation; i.e. it should have a 1 somewhere on its main diagonal, with all other elements in the same row and same column having all zeros. If either cos(0) doesn't evaluate to 1 or sin(0) doesn't evaluate to 0 you need to use a special case to handle these.
This error should still occur near the origin when you rotate or scale stuff unless there is some snapping involved(e.g. if vertex is close to the grid than 0.001, snap to grid). If no snap is involved, then the error will be too small to be displayed in the editor, but you should still see it in XVI32.
I'll take a better look and see if I can find other issues that might be causing this...
Well I feel lucky then, I practically only work with the line tool, each face connected to the adjacent. If you look at turtle you will see the whole thing is one geometry model. I then removed faces and connections by replacing them by models at places like doors to divide the geometry model into parts for better performance.
For cracks, like you point out, an easy way is to overscale props sometimes by just a few units. If you have cracks in geometry well use the line tool. Your method of copy/pasting faces is cool, but I think the engine prefers if it is all connected. It also doesn't need as much lines and vertexes.
Trying to edit connected stuff is a big pain in the ass, specially if you spend time aligning textures and such, if you have to delete a big piece you'll waste a lot of time carefully removing stuff, or even adding new geometry... :P I don't know, it should work no matter how you do it.