Bungie explains 'bumpy floor' problem in forge.

[Blakeumz]

Quoted directly from www.bungie.net.



Enter the Engineer

The Problem

When using double walls (or some other objects) to create a "floor," sometimes the objects become "bumpy" after saving and reloading the map.

The Cause

There are a near-infinite number of possible orientations that an object can be placed in. While you are editing a map, the objects are allowed to be in pretty much any orientation. When we save the map, we quantize the orientation in order to save space in storage. What this means is that the orientation you get when you load the map might not quite be what it was when you saved it.

Specifically, we store what direction the object's 'up' vector is pointing, and a rotation around that vector from its default position. When you first create an object in forge, its up vector is pointing straight up, and its rotation is zero. If you leave the object in a straight-up position, we use a special quantization method that preserves more precision for the rotation.

But if you tilt it (on its side, for example), then more of the storage space has to be used for that direction, and the rotation can lose precision. What this means is that when you are creating a floor out of walls, it's using the less precise method. The good news is that it's usually easy to predict which way the quantization error will go.

"Why can't you fix this?"

This problem is really inseparable from the way we store Map Variants on the disk. If we change the way the maps are encoded, then all the content saved in the old method could become invalid. It's a complex problem, and complexity means high risk. And risky changes are not something you want to make in a patch to a console game.

The Forge engine was built before we ever knew that maps like Foundry and Sandbox would exist. And this problem, of course, has been present since day one. It only now became apparent because people are building truly amazing maps and demanding more fidelity out of Forge.

"How about some good news?"

As outlined above, you should leave objects pointing 'up' if you can. If possible, create your floor out of double boxes instead of double walls. No effort, no bumps!

If you must use double walls for the floor, pay close attention to the location and direction of the helper gizmo (the blue/white orb that shows the origin of the object). When saved, walls placed horizontally tend to rotate such that the "forward" end of the gizmo is pointing slightly downward. You can use this to your advantage by placing walls that are end-to-end rotated 180 degrees from each other, so that both edges will be either high or low. Walls placed side-by-side should have the same gizmo orientation. See the following diagram:

http://www.bungie.net/images/News/Inline09/041709/views.jpg


Again, this is an issue that only crops up when you are rotating objects around their Z-axis, and most commonly, when shifting objects out of their initial orientation (i.e. laying a wall onto its side). The easiest solution is to make such shifts to orientation as sparingly as possible, or if you must, to simply follow the diagram Cable has laid out, juxtaposing the objects based upon the "gizmo," so that any variation you come across becomes uniform and therefore, less noticeable to players who traverse your map.

Yanking the network cable from the back of your Xbox 360, as some have suggested, does not resolve this issue.

*sigh*.

[ssshakedown]

Can't they just patch it so that the wall's default orientation is the way it would be used to make a floor?

[Blakeumz]

Can't they just patch it so that the wall's default orientation is the way it would be used to make a floor?
In the update its stated that they could, however it could fk up the game.

*Should've tested forge a tad more before release*.

[ssshakedown]

In the update its stated that they could, however it could fk up the game.

*Should've tested forge a tad more before release*.
I thought what they said was changing the way stuff is saved could mess it all up.

[Blakeumz]

I thought what they said was changing the way stuff is saved could mess it all up.
Oh, yeah I see that now. Well I'm sure if they could do it, they'd do it... so probably no easy solutions to this forge mess.

[FlaiReeZ]

old man bungie is getting a bit senile.

[Dragod]

That's a real shame... Especially considering this only helps when you have square or rectangular floor to make... Warlock? I'll probably have to find a different way to do the plats.. It's a shame that there is nothing with similar dimensions to that of a double wall that is slightly thicker, or something... A huge block is the only thing relatively close, and that would be way too low for my Warlock.

[Zanno]

I've known this and have talked about it for months now. The sandbox wall glitch also happens on foundry it's just more noticeable on account of how the wall object itself is actually built.

A much better way to resolve the problem than what bungie suggests is to just deal with the tilt, and build your floor on an incline. z-axis variation tends to make BR battles more difficult because you have to aim in two directions, anyway.

[_TaK_]

That's a real shame... Especially considering this only helps when you have square or rectangular floor to make... Warlock? I'll probably have to find a different way to do the plats.. It's a shame that there is nothing with similar dimensions to that of a double wall that is slightly thicker, or something... A huge block is the only thing relatively close, and that would be way too low for my Warlock.

Wood Bridges, sure they may look like **** but they work. Also making an entire floor out of them acctually looks kinda cool, I think the plats may kinda suck though.

Either way like Zanno said, this has always been known and is just now more evident, another way to solve it is to make everything on a very slight angle so that the low side tilt of one wall matches up with the high side tilt of the other, but it's a pain to buuild.

[Dragod]

Wood Bridges, sure they may look like **** but they work. Also making an entire floor out of them acctually looks kinda cool, I think the plats may kinda suck though.

Either way like Zanno said, this has always been known and is just now more evident, another way to solve it is to make everything on a very slight angle so that the low side tilt of one wall matches up with the high side tilt of the other, but it's a pain to buuild.
Wood bridges tilt just as bad as double walls, unfortunately.

[_TaK_]

Wood bridges tilt just as bad as double walls, unfortunately.

Definitely untrue, spawn a wood bridge in the air and save quit without moving it. Then reload up the map, put a double wall down on top of it and save quit and then you will see it. The wood bridge tear drop is facing up so it saves flatter.

[Takn Risks]

In the update its stated that they could, however it could fk up the game.

*Should've tested forge a tad more before release*.


agreed sir

[II7_HUNTER_II7]

i would have thought this would be an area bungie would have tested alot because its an obvious feature of forge :/ oh well anyways man i just wanted to say i already posted this a while before you :P not wanting to be a jerk i just thought i would say

http://www.mlgpro.com/forum/showthread.php?p=5217177#post5217177

[RC_5213]

i would have thought this would be an area bungie would have tested alot because its an obvious feature of forge :/ oh well anyways man i just wanted to say i already posted this a while before you :P not wanting to be a jerk i just thought i would say

http://www.mlgpro.com/forum/showthread.php?p=5217177#post5217177

Your post was exactly two minutes before his, he was probably typing while you posted.

And yeah, you would have though Bungie would have tested that particular feature a little more. Though, this does finally explain why the hell my walls were tilting on a Foundry map.

[my pet dinosaur]

How would they have tested for this when Forge was never meant to be a mapmaker in the first place?

[WMDistraction]

I'm going to have to side on Bungie with this one. When dealing with that many variables, the placement simply cannot be precise if you want the game to run smoothly. They could have probably made a more precise system, but it would demand a hell of a lot more performance out of your 360 than it currently does.

[BlackDeath10]

I found i pretty good way to deal with this problem,

1st of all raise your map ontop of something, like use 2 single walls or double boxes or something to lift your map away from the grid.

Now, when you place a double wall put in ontop of another object, like using a T-wall as a base for your double wall. This works because of the texture of the items, the text of the items are not completely flat, so your walls will not be completely flat, they will only be slitly croaked, which will take care of the Z-axis problem. Your walls will not be completely straight, but they will not be completely croaked. Your walls will barely be croaked, so when playing the map a player will not be able to tell that the floor is not completely striaght.

[bmx123r]

i dont understand why they dont just do what they did in halo 2 with desolation and tombstone, i understaned it might mess up peoples forge stuffs but id rather lose my forge stuff rather then have to walk on bumpy walls every time i play sandbox

[WMDistraction]

i dont understand why they dont just do what they did in halo 2 with desolation and tombstone, i understaned it might mess up peoples forge stuffs but id rather lose my forge stuff rather then have to walk on bumpy walls every time i play sandbox
I fail to see your reasoning? Forge didn't exist in H2. It's a whole different problem than what you're describing. H2 didn't have variable landscapes in it like H3 can have, so the z-axis gets screwed up because there is just too much stuff to consider. With this situation, you have two options:

1. Do a rounding sort of deal that, while making the map a little less accurate, increases performance by decreasing memory usage.

or

2. Keep the exact figure and eat up a ton of memory.

I think Bungie made the right decision, and that's saying a ton coming from me.

[Ultorskoss]

You would think that Bungie could just make a new forge object designed around the problem with the "gizmo's" axis to use as a floor. They've already identified why the problem occurs after all, and it wouldn't be too challenging to design an object where the "gizmo's" axis is pointing up by default, while at the same time having it act as a floor.

[Zanno]

I fail to see your reasoning? Forge didn't exist in H2. It's a whole different problem than what you're describing. H2 didn't have variable landscapes in it like H3 can have, so the z-axis gets screwed up because there is just too much stuff to consider. With this situation, you have two options:

1. Do a rounding sort of deal that, while making the map a little less accurate, increases performance by decreasing memory usage.

or

2. Keep the exact figure and eat up a ton of memory.

I think Bungie made the right decision, and that's saying a ton coming from me.No they didn't. They cut way too many corners in order to optimize things, forge is just one manifestation of it. The most obvious one is the packet loss = bullet refund issue which is totally nonsensical. They didn't stop to consider that you might want to use a wall for something other than a wall. It doesn't need to be perfectly accurate however whatever increment they use, they should have had the common sense to make sure that any 90 degree iteration is perfectly accurate. They are also totally wrong in regards to it only happening on the z-axis, you can't rotate a double box 90 degrees perfectly on any axis. i tend to use as many single boxes i can on the direction it can't go to create walls to compensate.

[Aggressnyak]

I'm going to have to side on Bungie with this one. When dealing with that many variables, the placement simply cannot be precise if you want the game to run smoothly. They could have probably made a more precise system, but it would demand a hell of a lot more performance out of your 360 than it currently does.
I don't think so. For every bit of quantization you add, the maximum error is divided by a factor of 2. For example, if they stored the orientation and position vectors of forge objects with 12-bit quantization then increasing to 14-bit would reduce the error by a factor of 4. That alone could be the difference between an obvious slant and a nearly undetectable one. It might be true that the extra bits degraded performance or would have required a reduction in forge budget, or it might be an embarrassing blunder on their part.

The crappy part is that they can say whatever they want ... "we can't fix this because <insert reason>" when in reality it's just a pain in the ass to fix and won't earn them any more money. Who knows.

If it's true that the orientation is only stored with lower precision when the object is rotated from default, couldn't they just add a new object to the pallette which is identical to the existing one except with its default orientation on its side (called "double-floor" or something)?

[UnknOWNBAMF]

We f***ed up and we can't fix it, so here is an explanation that we just s*** out of our a***es to waste 5 minutes of your life with.


fixed.

[Baron Saturday]

I dont intend to use walls for floors unless I need floors on a significant gradient.

[-NaStY-]

Bungie is dumb.


The obvious solution is to make sure that the degree separations are not quantized in to an odd number of values. You can take away all the precision you want, but making it so that there's no such thing as a 90 degree rotation is inexcusable. For anyone who actually understands what the problem is, you'll see what I mean.


There's two real solutions to this bug in my mind.

1. When planning your map, see if you can't replace any walls on your floor with blocks. This is probably a much more feasible fix than we might expect. I bet most maps will have enough vertical barriers that your walls can all be upright and still serve the map.

2. Bite the bullet, and build the entire map slightly tilted. Keep all floor walls in the same orientation, but as you move across the floor slowly lower each wall. Might cause some problems for symmetrical maps that you'd have to watch out for. In general you'd try not to make the map symmetrical along the direction that's slanted. If it's unavoidable, then be aware that a steep but climbable ramp on one side might be unclimbable on the other, etc.

[Zanno]

Bungie is dumb.


The obvious solution is to make sure that the degree separations are not quantized in to an odd number of values. You can take away all the precision you want, but making it so that there's no such thing as a 90 degree rotation is inexcusable. For anyone who actually understands what the problem is, you'll see what I mean.


There's two real solutions to this bug in my mind.

1. When planning your map, see if you can't replace any walls on your floor with blocks. This is probably a much more feasible fix than we might expect. I bet most maps will have enough vertical barriers that your walls can all be upright and still serve the map.

2. Bite the bullet, and build the entire map slightly tilted. Keep all floor walls in the same orientation, but as you move across the floor slowly lower each wall. Might cause some problems for symmetrical maps that you'd have to watch out for. In general you'd try not to make the map symmetrical along the direction that's slanted. If it's unavoidable, then be aware that a steep but climbable ramp on one side might be unclimbable on the other, etc.from my modding adventures i can absolutely tell you that all angles are stored in radians, it's probably clamping the radians to some decimal value, probably to values of .1

[WMDistraction]

from my modding adventures i can absolutely tell you that all angles are stored in radians, it's probably clamping the radians to some decimal value, probably to values of .1
sin(pi)=0
cos(pi)=-1
tan(pi)=0
csc(pi)=undefined
sec(pi)=-1
cot(pi)=undefined

sin(pi/2)=1
cos(pi/2)=0
tan(pi/2)=undefined
csc(pi/2)=1
sec(pi/2)=undefined
cot(pi/2)=0

I fail to see why radian clamping would be the problem for 90 degree angles.

[Mango221]

I fail to see why radian clamping would be the problem for 90 degree angles.

Bingo...unless bungie for some reason set their reference angle (0 rad) at a cockeyed angle?

-Mango

[Aggressnyak]

sin(pi)=0
cos(pi)=-1
tan(pi)=0
csc(pi)=undefined
sec(pi)=-1
cot(pi)=undefined

sin(pi/2)=1
cos(pi/2)=0
tan(pi/2)=undefined
csc(pi/2)=1
sec(pi/2)=undefined
cot(pi/2)=0

I fail to see why radian clamping would be the problem for 90 degree angles.
Good point, but whatever scheme they're using probably isn't exactly "radian clamping" as described above. The standard way to quantize something is with an integer data type X bits in length, in which case you end up with the number of possible values ("representation levels") being 2 to the power X because that's the number unique values you can get with X bits. For example, if I had an audio signal that varied somewhere between 2 and -2 volts that I wanted to digitize into a 4-bit data, there would be 2^4=16 quantization levels on a linear scale: -2, -1.75, -1.5, -1.25, ..... , +1.75 . The "quantization step" is just the total range (4 Volts) divided by the number of levels ( 4 / 16 = 0.25 V).

I'm baffled because this still doesn't explain why they can't do 90 degrees. For example, if you have an angle that varies between 0 and 360 degrees and decided to use 6-bit linear quantization, your values would be 0, 5.625, 11.25, 16.8750, ...., 90, ...., 354.375 . As long as more than two bits are used (defintely it's more than this) 90 degrees always comes up as one of the values. The only explanations I can think of is Bungie either using a nonlinear quantization scale (not sure why they would) or using rectangular coordinates rather than polar coordinates to store the orientations (in which case they would be digitizing unit vectors rather than angles).

As was pointed out, they probably could have sacrifiiced a small amount of resolution such that 90 degrees was possible no matter what.

[Zanno]

sin(pi)=0
cos(pi)=-1
tan(pi)=0
csc(pi)=undefined
sec(pi)=-1
cot(pi)=undefined

sin(pi/2)=1
cos(pi/2)=0
tan(pi/2)=undefined
csc(pi/2)=1
sec(pi/2)=undefined
cot(pi/2)=0

I fail to see why radian clamping would be the problem for 90 degree angles.because pi falls between 3.1 and 3.2

[BlackDeath10]

I have flat walls on my map.............

I guese everyone kind of ignored what i posted on page 2, but thats ok I guese i will get pics and vids to prove it. In the mean time i would recommend people try out my method if you would rather wait i understand, but my method should be at least tested in the mean time.

and yes i have no clue what those numbers mean.......

[Aggressnyak]

because pi falls between 3.1 and 3.2
I thought what he was trying to say was that instead of quantizing the angle itself you could just quantize its sine or cosine. Add two extra bits to say what quadrant it is in. In retrospect I was probably wrong, and it seems kind of doubtful they would do it this way.