[DiscordArchive] Hi, im who opened the PR and thanks for the discussion on git, what would be the best or accurate wa
[DiscordArchive] Hi, im who opened the PR and thanks for the discussion on git, what would be the best or accurate wa
Original source
```diff
@@ -712,35 +712,47 @@ float GridTerrainData::GetHeightAccurate(float x, float y, float radius) const
G3D::Vector3 U = B - A;
G3D::Vector3 V = C - A;
G3D::Vector3 n = U.cross(V);
- float nz = n.z;
- float const eps = 1e-6f;
-
- if (std::abs(nz) < eps)
- return getHeight(x, y);
-
- if (nz < 0.0f)
- n = -n;
-
- n = n.unit();
-
- float d = -n.dot(A);
- float z = (radius - d - n.x * P.x - n.y * P.y) / n.z;
-
- if (!std::isfinite(z))
- return getHeight(x, y);
-
- return z;
+ float const eps = 1e-6f;
+ if (std::abs(n.z) < eps)
+ return getHeight(x, y);
+
+ float d = -(n.x * A.x + n.y * A.y + n.z * A.z);
+ float zPlaneAtCenter = (-d - n.x * P.x - n.y * P.y) / n.z;
+
+ float nzAbs = std::abs(n.z);
+ float slopeL2 = std:
qrt(std::max(0.0f, n.x * n.x + n.y * n.y)) / std::max(eps, nzAbs);+ float z = zPlaneAtCenter + radius * slopeL2;
+
+ if (!std::isfinite(z))
+ return getHeight(x, y);
+
+ return z;
}```
I think it's still cheap
rektbyfaith
09-23-2025, 06:36 PM #31Archived author: Elitia • Posted: 2025-09-23T18:36:50.823000+00:00
Original source
```diff
@@ -712,35 +712,47 @@ float GridTerrainData::GetHeightAccurate(float x, float y, float radius) const
G3D::Vector3 U = B - A;
G3D::Vector3 V = C - A;
G3D::Vector3 n = U.cross(V);
- float nz = n.z;
- float const eps = 1e-6f;
-
- if (std::abs(nz) < eps)
- return getHeight(x, y);
-
- if (nz < 0.0f)
- n = -n;
-
- n = n.unit();
-
- float d = -n.dot(A);
- float z = (radius - d - n.x * P.x - n.y * P.y) / n.z;
-
- if (!std::isfinite(z))
- return getHeight(x, y);
-
- return z;
+ float const eps = 1e-6f;
+ if (std::abs(n.z) < eps)
+ return getHeight(x, y);
+
+ float d = -(n.x * A.x + n.y * A.y + n.z * A.z);
+ float zPlaneAtCenter = (-d - n.x * P.x - n.y * P.y) / n.z;
+
+ float nzAbs = std::abs(n.z);
+ float slopeL2 = std:qrt(std::max(0.0f, n.x * n.x + n.y * n.y)) / std::max(eps, nzAbs);
+ float z = zPlaneAtCenter + radius * slopeL2;
+
+ if (!std::isfinite(z))
+ return getHeight(x, y);
+
+ return z;
}```
I think it's still cheap
Original source
I gotta get better at math
rektbyfaith
09-23-2025, 06:39 PM #32Archived author: Bench • Posted: 2025-09-23T18:39:11.248000+00:00
Original source
I gotta get better at math
Original source
was about to ping you lmao
rektbyfaith
09-23-2025, 06:53 PM #33Archived author: Kitzunu • Posted: 2025-09-23T18:53:45.183000+00:00
Original source
was about to ping you lmao
Original source
I’m not an expert in this area, but I’d like to add some thoughts.
From what I see, this change applies to regular terrain heightmaps, not vmaps, which are used in most capitals and instances. Shouldn’t we also consider cases where a sphere intersects multiple heightmap cells (on cells boundaries)?
Also, in my blink tests, I didn’t find cases where the client considered current serverside calculated Z as under the map. The issues I noticed were more in the logic before the final Z calculation. Still, my perspective may be limited, since I focused more on vmaps or maybe the client’s collision logic covers inaccuracy between different collision approaches. If anyone has concrete examples where the current serverside height calculation fails, that would be very useful for testing this change.
rektbyfaith
09-23-2025, 07:19 PM #34Archived author: walkline • Posted: 2025-09-23T19:19:59.160000+00:00
Original source
I’m not an expert in this area, but I’d like to add some thoughts.
From what I see, this change applies to regular terrain heightmaps, not vmaps, which are used in most capitals and instances. Shouldn’t we also consider cases where a sphere intersects multiple heightmap cells (on cells boundaries)?
Also, in my blink tests, I didn’t find cases where the client considered current serverside calculated Z as under the map. The issues I noticed were more in the logic before the final Z calculation. Still, my perspective may be limited, since I focused more on vmaps or maybe the client’s collision logic covers inaccuracy between different collision approaches. If anyone has concrete examples where the current serverside height calculation fails, that would be very useful for testing this change.
Original source
It's already on the discussion opened by <@160329888107069440> if i don't recall:
https://github.com/azerothcore/azerothco...sions/3971
[Embed: [DEV] Use sphere-plane collision tests for movement spells · azero...]
This issue is supposed to be a discussion about heightmaps, height checks and navigation. Movement spells include blink, shadowstep, charge etc. I have been looking into height testing on WoW terra...
https://github.com/azerothcore/azerothco...sions/3971
rektbyfaith
09-23-2025, 07:28 PM #35Archived author: Elitia • Posted: 2025-09-23T19:28:04.222000+00:00
Original source
It's already on the discussion opened by <@160329888107069440> if i don't recall:
https://github.com/azerothcore/azerothco...sions/3971
[Embed: [DEV] Use sphere-plane collision tests for movement spells · azero...]
This issue is supposed to be a discussion about heightmaps, height checks and navigation. Movement spells include blink, shadowstep, charge etc. I have been looking into height testing on WoW terra...
https://github.com/azerothcore/azerothco...sions/3971
Original source
Well, i did a test with a cylinder vs triangle and a test with upside-down pyramid, there are results:
1st pic: upside-down pyramid
2nd pic: cylinder vs triangle
![[Image: image.png?ex=690c5250&is=690b00d0&hm=519...86e32e943&]](https://cdn.discordapp.com/attachments/284323424032129024/1420134228519026738/image.png?ex=690c5250&is=690b00d0&hm=5199a2acc43341eae83c129648b923b9c18d989bf5e767a4c8e99e286e32e943&)
![[Image: image.png?ex=690c5250&is=690b00d0&hm=18a...e3b343ddf&]](https://cdn.discordapp.com/attachments/284323424032129024/1420134228875546855/image.png?ex=690c5250&is=690b00d0&hm=18a2a2651c2427f035f96f2a2462ef1445df768011b3d2026ae26a0e3b343ddf&)
rektbyfaith
09-23-2025, 07:46 PM #36Archived author: Elitia • Posted: 2025-09-23T19:46:25.050000+00:00
Original source
Well, i did a test with a cylinder vs triangle and a test with upside-down pyramid, there are results:
1st pic: upside-down pyramid
2nd pic: cylinder vs triangle
Original source
(Note it's a very steep slope)
rektbyfaith
09-23-2025, 07:47 PM #37Archived author: Elitia • Posted: 2025-09-23T19:47:43.812000+00:00
Original source
(Note it's a very steep slope)
Original source
```"From what I see, this change applies to regular terrain heightmaps, not vmaps, which are used in most capitals and instances. Shouldn’t we also consider cases where a sphere intersects multiple heightmap cells (on cells boundaries)?"```
Good point. Yes the vmap checks should also use a sphere. And yes I guess there could be edgecases where we need to care about more triangles than the one we're standing on. But I don't think the previous implementation took this into consideration either?
```
Also, in my blink tests, I didn’t find cases where the client considered current serverside calculated Z as under the map. The issues I noticed were more in the logic before the final Z calculation. Still, my perspective may be limited, since I focused more on vmaps or maybe the client’s collision logic covers inaccuracy between different collision approaches. If anyone has concrete examples where the current serverside height calculation fails, that would be very useful for testing this change.
```
These cases are hard to find, because this problem has been left to fester for so long, and a lot of people have taken the same decision as you did last time you looked into this and decided to sidestep the fundamental flaw in what test is being done to solve the issue of falling through terrain in another way, like nudging where the ray starts or applying a stupid constant to the result.
rektbyfaith
09-23-2025, 07:48 PM #38Archived author: Pursche • Posted: 2025-09-23T19:48:57.849000+00:00
Original source
```"From what I see, this change applies to regular terrain heightmaps, not vmaps, which are used in most capitals and instances. Shouldn’t we also consider cases where a sphere intersects multiple heightmap cells (on cells boundaries)?"```
Good point. Yes the vmap checks should also use a sphere. And yes I guess there could be edgecases where we need to care about more triangles than the one we're standing on. But I don't think the previous implementation took this into consideration either?
```
Also, in my blink tests, I didn’t find cases where the client considered current serverside calculated Z as under the map. The issues I noticed were more in the logic before the final Z calculation. Still, my perspective may be limited, since I focused more on vmaps or maybe the client’s collision logic covers inaccuracy between different collision approaches. If anyone has concrete examples where the current serverside height calculation fails, that would be very useful for testing this change.
```
These cases are hard to find, because this problem has been left to fester for so long, and a lot of people have taken the same decision as you did last time you looked into this and decided to sidestep the fundamental flaw in what test is being done to solve the issue of falling through terrain in another way, like nudging where the ray starts or applying a stupid constant to the result.
Original source
Basically, the piles and piles of hackfixes and trying to avoid actually fixing the issue has made it VERY hard to point to an exact spot where you still fall through the terrain. I'm sure they exist, but if they have been reported in the past 6 years I've been advocating this kind of change, they would have been hackfixed by now.
rektbyfaith
09-23-2025, 07:51 PM #39Archived author: Pursche • Posted: 2025-09-23T19:51:29.750000+00:00
Original source
Basically, the piles and piles of hackfixes and trying to avoid actually fixing the issue has made it VERY hard to point to an exact spot where you still fall through the terrain. I'm sure they exist, but if they have been reported in the past 6 years I've been advocating this kind of change, they would have been hackfixed by now.
Original source
What would be the best scenario <@160329888107069440>, testing with blink?
rektbyfaith
09-23-2025, 07:57 PM #40Archived author: Elitia • Posted: 2025-09-23T19:57:22.694000+00:00
Original source
What would be the best scenario <@160329888107069440>, testing with blink?
1 Guest(s)
1 Guest(s)