Hello,
I've grasped some people complain about a loss of numeric precision when working with Hammer.
It's probably usually only evident when looking at the textual data of a VMF file, but I can imagine that a bunch of tools making assumptions about the numeric values
can also be thrown off by those numbers.
Clipping brushes can spawn vertices at coordinates that are not at whole units or at coordinates that are not sums of multiples of (positive and negative) powers of two.
Numbers that are not sums of multiples of positive and negative powers of two can only be approximated with the standard floating-point math also used here, so we
like them better when they are "tidy" like that.
From the math standpoint, all the vertices are only derived data and don't matter so much (and they are not actually represented in the VMF files), but they can matter
later for the compiler that has to calculate proper polygons from them.
Brushes are 3D intersections of half spaces (which are 3D too), meaning faces separating a volume of infinite nothingness from a volume of infinite solidity by an
infinite plane.
In a VMF file, each of those planes is represented by three points in 3D space in clockwise order, e.g. "plane" "(0 0 0) (0 -128 0) (128 -128 0)". That's one mathematically stable way of representing a plane that's also friendly to translations (friendly to being moved around) -- you can add 3D vectors to all those points in a brush ("solid") to move the whole primitive.
Each plane can be represented by an infinite number of 3D point triplets (or triangles that are -in- the plane), so you can have two VMF files where a face describing one and the same plane can have completely different plane data. Also, for the final vertices, the order of planes doesn't matter. You can edit a VMF file by hand and change the order of "sides" wildly and end up with the same geometry in the editor and in the game.
In the Doom 3 engine, they've switched to a non-ambiguous but less stable representation: they've basically saved the a, b, c, and d of the normal plane formula
a*x+b*y+c*z = d. This is less stable because to describe the same sloped plane in different locations (meaning different location points are -in- the plane), the d number easily becomes one that's not "tidy" as described above. And if the a, b, c vector is normalized to be really unambiguous, tidy increments on the coordinate axes can
yield completely untidy numbers saved (square root of 2, anyone?). And moving a sloped plane by a simple measure can cause the number to look really ugly/untidy,
whereas in the VMF format, tidy numbers remain tidy when translated by sane and tidy distances (tidy per main coordinate axis).
When you do vertex editing directly in Hammer, the editor works with the derived vertices that don't exist in the VMF data, and upon finishing an edit
(upon finishing moving a vertex), it has to decide on a new set of points to represent each of the planes affected.
When you want to rotate a point in 3D space, described by the coordinates x, y, z, by a certain angle, you end up with widely known formulas that take the
sine and cosine of the angle to form two factors, and add those coordinates together with those factors.
These are not the real formulas, but this illustrates it a bit:
To rotate a point p = x, y, z around the height axis of the world (z in HL2):
z_new = z_old (that coordinate remains untouched)
x_new = sin(angle)*x_old+cos(angle)*z_old
z_new = cos(angle)*x_old+sin(angle)*z_old
Again, these are not the real formulas, they are only for illustration and kinda look like the real thing.
Because this kind of calculation pattern, where each coordinate is a sum of the other coordinates with a factor each is very common in math (z = 0*x+0*y+1*z !)
(common in linear algebra especially), matrices were invented. A matrix is a grid of those factors, and a 3D vector representing a position can be multiplied with the
matrix to "transform" it. There can be matrices for translation (moving), rotation (with sin and cos factors), scaling, etc. The keywords for that are homogeneous
coordinates and affine transformations. They allow all these things to be represented in a standardized manner, so to say.
Now... IIRC, precision problems can be -seen- in Hammer when building a fancy spike, even when the vertices of its baseplate are all aligned to grid and all its sides but
the baseplate are triangles. The problem would become evident by a new ghost vertices or even ghost edges (but no ghost polygons?) forming at the tip.
That's one thing I haven't looked further into.
But here is a thing that I have looked at more closely.
When you rotate a 2D point in a 2D coordinate system by 90° by hand on scaled paper, what you really do is counting the boxes and swapping out coordinates. If you
just invert the +/- sign on a tidy number or swap out tidy numbers, they remain tidy. A tool that pays attention to that would recognize 90° situations and do it just like
this.
Hammer doesn't detect that and does something different.
As shown above, to go from angle to new coordinate, sin and cos are applied. To go from degrees, which we can imagine more easily, to radians, which those functions normally use, we do this: sin(angle) = sin(pi/180*angle), so sin(90°) = sin(pi/180*90) = sin(pi/2) = 1.
That way you get numbers like -1, 0, and 1 from sin and cos by inputting multiples of 90° in them.
But the real world computing has precision problems. 90 is a tidy number, pi/2 isn't, and so in many systems it happens that sin(90) is not precisely 1, but something like 0.999999997263 or 1.000000000032, and cos(pi/2) can be 6.123031769111886e-17 instead of 0.
If hammer detected 90° angles (or approximate 90° angles by an absolutely tiny margin), it could just do the coordinate swapping and sign flipping, but instead it goes
the same math route for all angles and hence uses untidy factors for calculating the new coordinates. And tidy times untidy is untidy. Throw a muddy football into a
basked of clean laundry, and you know the trouble you get yourself into will outweigh the bit of mud that's now "less" on the ball.
If I rotate this thing, which only has tidy coordinates for everything, by 90°:
https://files.facepunch.com/forum/upload/132786/ce78932b-7d6d-4ab6-b5d8-2eb5802be81c/image.png
(Where I've also manipulated the displacement data by hand to read: "... offsets {"row0" "10 0 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"")
I get this (RegEx-search in that document for "\de"):
Line 47: "plane" "(3.8147e-006 -128 0) (128 -128 0) (128 0 0)"
Line 58: "plane" "(128 -128 0) (3.8147e-006 -128 0) (3.8147e-006 -128 96)"
Line 58: "plane" "(128 -128 0) (3.8147e-006 -128 0) (3.8147e-006 -128 96)"
Line 69: "plane" "(-1.78036e-006 0 0) (128 0 0) (128 0 96)"
Line 80: "plane" "(3.8147e-006 -128 0) (-1.78036e-006 0 0) (-1.78036e-006 0 96)"
Line 80: "plane" "(3.8147e-006 -128 0) (-1.78036e-006 0 0) (-1.78036e-006 0 96)"
Line 80: "plane" "(3.8147e-006 -128 0) (-1.78036e-006 0 0) (-1.78036e-006 0 96)"
Line 113: "plane" "(-1.78036e-006 0 96) (32 -32 128) (32 -96 128)"
Line 124: "plane" "(128 -128 96) (3.8147e-006 -128 96) (32 -96 128)"
Line 135: "plane" "(-1.78036e-006 0 96) (128 0 96) (96 -32 128)"
Line 156: "plane" "(128 -128 160) (3.8147e-006 -128 160) (-1.78036e-006 0 160)"
Line 156: "plane" "(128 -128 160) (3.8147e-006 -128 160) (-1.78036e-006 0 160)"
Line 196: "row0" "-4.37114e-007 10 10 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0"
Line 322: "plane" "(3.8147e-006 -128 144) (128 -128 144) (128 0 144)"
Line 333: "plane" "(128 -128 144) (3.8147e-006 -128 144) (3.8147e-006 -128 160)"
Line 333: "plane" "(128 -128 144) (3.8147e-006 -128 144) (3.8147e-006 -128 160)"
Line 344: "plane" "(-1.78036e-006 0 144) (128 0 144) (128 0 160)"
Line 355: "plane" "(3.8147e-006 -128 144) (-1.78036e-006 0 144) (-1.78036e-006 0 160)"
Line 355: "plane" "(3.8147e-006 -128 144) (-1.78036e-006 0 144) (-1.78036e-006 0 160)"
Line 355: "plane" "(3.8147e-006 -128 144) (-1.78036e-006 0 144) (-1.78036e-006 0 160)"
... suddenly the whole file is untidy/dirty, and when these primitives or copies of them are used and transformed further, rotated again, scaled up, etc., those imprecise
and untidy numbers can become worse. The precision errors basically propagate as the data is worked with further.
--
Are you aware of other situations where this happens?
In theory, touching vertices (or moving them forth and back a bit or using a function to align them to grid) in vertex edit mode should be one by-hand way to clean those numbers up.
I dunno why i read that crap. Hammer allows certain imperfections or smart detailing if you want to describe that. If you scale brushes you can get down to roughly quarter inch precision before it triggers merging vertices in the compile even. May explain your numerical errors.
Ok, so you don't care about the topic. But does that really make my write-up "crap"?
Yes and no. I tackle the tools and precision too, but I usually don't and nobody else should care about algebra stuff and precision when you're just building. As long as every brush ends up on the grid, it's all good to go. Not?
"I dunno why I read that crap," says ignorant idiot to the person who bothered to do some useful research. Just how dumb can one person get??
On topic, I feel its a shame we get all these awesome insights and fixes this late into sources lifespan. If we had this kind data back in 2008ish, or even the tools we have today, who knows what the community could have further produced. Now its just a really interesting read maybe.
However, great job presenting this issue in such a systematic way. I really know loads about the engine and its tools, but I don't think I've ever seen anyone dive this deep into the issue at hand.
I'm sorry i triggered something dumb. I tested brush limits months/years ago. You get it? Quarters? Even if you mess or don't mess with vmfs the compiler only takes and compiles a specific format and precision and bakes it. Nothing you think you can tweak in a vmf will surpass the compiler as is. You forgot that? Mess with the vbsp, vvis and vrad code then to get somewhere you think you're going. All nice.
@Grenade Man It's never too late for research.
Just look at Func_Msgboard and their awesome work on new Quake episodes and sourceports!
This thread alone, about toying with entity properties, is pure hobbyist insanity: http://celephais.net/board/view_thread.php?id=37116
I have big plans and goals far out of reach for my program for which I need to understand what's going on
as in-depth as possible. And there are so many more interesting topics. How does the texturemapping
work? (I have the math under control) How to control entity event chains in a way that allows complex
logic without any wait times? (the inverse order of connection properties is key) Can large level sections
be made of skewed and tilted architecture without sacrificing bsp integrity? (they probably can, I just don't
know about the shadowmapping yet)
Those randomly generated future singleplayer and multiplayer levels won't program themselves. P:
They will look very bad at first, but I will feel content about them. The next step is already in the works.
I guess this just has to do with it's age. We are talking about a game engine that is old as dirt, hammer editor existed back in 2004 I believe? The fact is, the editor is basically confined by the grid. To furthure prove it, make a building with 1 inch thick walls, and then rotate it 45 degrees... the walls will micro disalign and lose coordinate accuracy which will cause lighting and brush face compilation errors. This will also cause leaks if it's the confines of your world of course....
This why Valve uses a lot of specific models for specific scenery, in fact it's not a strectch to say that Valve's maps consist mostly of props versus hammer geometry.
I didn't really look at the numbers, but I realized this very thing a while back when I tried to make a Far Cry 2 replica map using only methods for modernday game editors... Let me tell you how much of an adventure that was!
At first it couldn't handle terrain that was by the power of 4 especially since I had over 1000 squares of terrain.... apparently, hammer doesn't know how to compress the physics data of displacements made by the power of 4..... so I had to scrap the terrain and start over...
Foliage is also wonky, since it's done only on 2D sprites without proper optimization.. so I couldn't have thick beautiful grass.. the grass was very few and far between.
Then it came to naturally positioned structures... this is where I found out about hammer losing accuracy over any brush that is NOT 90 degrees, or aligned on the grid.
CONCLUSION: We need Hammer 2.0 from Dota 2 ....If I remember correctly, they got rid of most of these old problems, and added a proper set of AAA game engine software, like a built in model editor...
Sorry, you need to Log In to post a reply to this thread.
