[FIXED] CWorld::Intersect / Raycasting in 1.12

[Valediction]

Hi all,

I'm having some difficulty getting World::Intersect to work in 1.12.

I am calling it like this (this is pseudocode for the actual code but verified with a debugger):

float[] points = {p1x, p1y, p1z, p2x, p2y, p2z};
float[] intersect = {0, 0, 0};
float distance = 1.0f; // Tried different values, like 10.0f too, in case it's not the usual normalized parameter
int flags = 0x1e; // Tried many others, including 7fffffff, some suggested by Apoc, etc. 

// I call it as a fastcall, first 2 args are in ecx, edx, next two on the stack
// Actually I reserve memory for intersect, zero it and pass the pointer
// EDIT: prototype
sub_6aa160(points, &distance, intersect, flags);

The function proceeds to calculate the distance between p1 and p2 (correctly) but starts calling other functions and I end up losing it.
It always returns (as a byte) 0x00 and as an Int I sometimes see 0x6a0000 (if 0F000FFh & flags == 0) or 0x1900 otherwise.
EDIT: After using the right prototype it returns proper booleans but it always comes out as zero.

I've tried to raycast from char to ground or between walls of a house, with identical results always. Adding Player.Height to Z components doesn't make a difference.

First of all, from a recent post in 1.12's thread:

So World::Intersect located at 0x6AA160. It's a little bit different from traceline that we all know, it takes 4 parameters World::Intersect(Vector3[] Line, &Vector3 Intersection, float Distance, int Flags). And flags are different too, didn't check them all.

After inspection of the function, I see it's fastcall with Vector3[] Line referring to 6 float's with layout:

struct arg1 {x1, y1, z1, x2, y2, z2}

As demonstrated by:

.text:006AA166                 mov     esi, ecx
.text:006AA168                 fld     dword ptr [esi+0Ch]
.text:006AA16B                 xor     bl, bl
.text:006AA16D                 fsub    dword ptr [esi]
.text:006AA16F                 mov     [ebp+var_4], edx
.text:006AA172                 fld     dword ptr [esi+10h]
.text:006AA175                 fsub    dword ptr [esi+4]
.text:006AA178                 fld     dword ptr [esi+14h]
.text:006AA17B                 fsub    dword ptr [esi+8]

The second (EDIT: third) argument I guess it's an out parameter with room for 3 floats to be filled with the intersection, if we detect one. Because the function always returns (BYTE) 0x00, I've never seen the supposedly out parameter get filled with anything and it remains set to {0.0f, 0.0f...}.
4th parameter should indeed refer to flags (it's 2nd on the stack due to fastcall):

(...)
.text:006AA1AE                 mov     edi, [ebp+arg_4]
.text:006AA1B1                 test    edi, 0F000FFh
.text:006AA1B7                 jz      short loc_6AA1CA
(...)
.text:006AA1CA                 test    edi, 0F00F0Fh
.text:006AA1D0                 jz      short loc_6AA1E0
(...)

I include all this because I've seen different signatures for this function in newer versions and I wanted to establish this first, if you see any mistakes (including calling the wrong function!) please correct me. Also the layout of the function is different from the Alpha's (CWorld::Intersect), which is a rather short function that calls CMap::VectorIntersect and returns its result.

Thanks

[Sacred]

I'm using it for LOS detection with this flag 0x100111 and it works pretty well.

"push " + (uint)flag,
"mov edx, " + pDistance,
"push " + pIntersection,
"mov ecx, " + pLine,
"call " + (Offsets.Functions.World_Intersect),
"retn"

I have only one issue, this function doesn't check for intersection with bounding models (trees, rocks etc.), i tried every possible flags, but still nothing.
And intersection returns strange coordinates, it's different from world ones.

LOS: false;
Player: (1660,075f, 1668,957f, 141,8493f);
Target: (1678,99f, 1667,86f, 135,7708f);
Intersection: (0,806715f, 0,5634735f, 0,178069f);

LOS: true;
Player: (1668,056f, 1662,937f, 141,1954f);
Target: (1678,99f, 1667,86f, 135,7708f);
Intersection: (0f, 0f, 0f);

[Valediction]

And intersection returns strange coordinates, it's different from world ones.

LOS: false;
Player: (1660,075f, 1668,957f, 141,8493f);
Target: (1678,99f, 1667,86f, 135,7708f);
Intersection: (0,806715f, 0,5634735f, 0,178069f);

LOS: true;
Player: (1668,056f, 1662,937f, 141,1954f);
Target: (1678,99f, 1667,86f, 135,7708f);
Intersection: (0f, 0f, 0f);

I checked the modulus of intersection for the case != 0 and it is 1, so that may be a normalized intersection point in the line defined by your endpoints.

So the collision would be, if my guess is correct, at:

[ p.x + 0.8*(t.x-p.x) , p.y + 0.56*(t.y-p.y), p.z + 0.178*(t.z-p.z) ] (or with reversed sign, that depends on how it actually gets computed).

Are you passing Line as the struct I pointed in my original post? Sadly I'm still getting 0x00 even raycasting into walls at say Ironforge.

[Sacred]

Yes, i'm passing Line as Vector3 struct.

Memory.Write<Location>(pLine, Start);
Memory.Write<Location>(pLine + 12, End);

[Valediction]

I'm using it for LOS detection with this flag 0x100111 and it works pretty well.

"push " + (uint)flag,
"mov edx, " + pDistance,
"push " + pIntersection,
"mov ecx, " + pLine,
"call " + (Offsets.Functions.World_Intersect),
"retn"

[/code]

One thing I've noted after stepping through the function that calls sub_6AA160 (2 hops up) and that now I see your post can confirm is that pDistance is the second parameter, not the third as you wrote in the 1.12 thread. Signature would be:

BYTE __fastcall World__Intersect( float* points, float* distance, float *outIntersection, DWORD dwFlags );

Where points is a pointer to a block of 6 floats and outIntersection is a pointer to a block of 4 floats (the 4th item is a dot product of the normalized collision point with something I'm not quite sure since I made the function generate it artificially).

[Valediction]

I'm using it for LOS detection with this flag 0x100111 and it works pretty well.


I have only one issue, this function doesn't check for intersection with bounding models (trees, rocks etc.), i tried every possible flags, but still nothing.
And intersection returns strange coordinates, it's different from world ones.

Got it working, seems you have to read distance and it will tell you where (0-1) along the ray the collision happened. Haven't tested it thoroughly but that seems to be the way it goes... and yeah, it misses a lot of stuff outdoors like trees and such despite flags.

[luckruns0ut]

Sorry to gravedig but this is useful to people like me who were searching for how to do this. There is another function which will work with world objects so it is not useless, and I think it's worth posting here in a little more detail than what I found. Hopefully it'll save someone else some time...

The function looks like: (Credit to Namreeb for finding/posting it)
bool __fastcall CWorld::Intersect(const C3Vector *p1, const C3Vector *p2, int ignored, C3Vector *intersectPoint, float *dist, unsigned int queryFlags)

And you can call it like this in c++:

struct Vector3
{
   float x;
   float y;
   float z;
}

auto const worldIntersect = reinterpret_cast<bool(__fastcall *)(Vector3* p1, Vector3* p2, int ignore, Vector3* intersection, float *dist, unsigned int flags)>(0x672170);
Vector3 intersect = { 0 };
float dist = 1;
if (worldIntersect(&start, &end, 0, &intersect, &dist, 0x100111)) // if there is a collision between start and end vectors
{
	drawLine(start, intersect); // draw from the start position to wherever it hit
}

It returns true if there was an intersection, and if there was it will write out the intersection point and distance.

The function will scan from start to end (absolute world positions - end is not a direction)

If there was an intersection, the intersect vector contains the intersection point and dist shows you the 0-1 distance at which the intersection occured along the ray.

The dist parameter is strange and I'm still not entirely sure how to use it properly, however if you pass zero then the function will just return false. It seems to be the distance it scans along your start-end line but only for the ground... I think the best value for it is actually the distance between start and end

Edit: I think you also need to check if(dist < 1) when your trace returns true in order to keep it properly accurate. If you don't do that then it will actually scan further for terrain and cause problems

[klee946]

I can't seem to get the function at 0x672170 working correctly. Does this need to be called on the client's main thread? If I pass my character's position as the start vector and an npc's position as the end vector that is directly in front of me without any obstructions, sometimes the function returns true and other times false. I'm setting the distance to 1 and passing everything correctly. The distance returned changes between -1 and 1 and my character can fall through the map if this is called too frequently. This definitely leads me to believe that there's a race going on.