lineintersects == broken?

[bad benson 1733]

i'm working on some context sensitive movements and i need to detect objects, or rather collision in general, in front of the player.

lineintersects seems to be very unreliable for some reason though. i started working on this in arma 2 and had no problems like this.

this is the basic code to detect a head/shoulder high wall in front of a unit. put it in a trigger set on a radio signal and repeatedly and see for yourselves.

pos = player modeltoworld [0,1,1.8];

pos2 = player modeltoworld [0,3,1.8];

hint format ["%1", (lineintersects [pos, pos2])]

weirdly i had to use [0,1,1.8] instead of [0,0,1.8] to get any intersection at all on a house wall. so basically it works in some places with odd settings but it's no where near reliable or logical.

i wasn't sure if i might be messing up the position so i placed objects there with attachto to check. the offsets seem to be fine.

any ideas? i would really appreciate the slightest hint since this is keeping some awesome stuff from being finished. here's a little teaser.

EDIT: another observation: the hint seems to return true a lot inside buildings even if not close to a wall and also in niches like seen here.

http://i.cubeupload.com/AwSJwm.jpg

http://i.cubeupload.com/rjoQBc.jpg

Edited April 18, 2013 by Bad Benson

[Larrow 2808]

Yep thats FUBAR alright, as you say just putting something like

nil = [] spawn {
while {true} do {
	sleep 0.03;
	start = player modelToWorld [0,1,1];
	end = player modelToWorld [0,3,1];
	helper1 setPos start;
	helper2 setPos end;
	hint str (lineIntersects [start,end,helper1,helper2]);
};
};

in the player init and running around Marina gives all sorts of weird results. Helper1 and 2 are just empty->object->10cm spheres

As you say house walls are not detect until start point is touching the wall.

Going inside a house returns true all the time even if there is nothing between start and end.

Running over a bridge returns all sorts of values.

Any thing over the gully walls all ways returns true.

Most garden walls are not even detected.

Placing the start position over the edge of a walkway like the shop fronts returns true.

It almost like its not doing a trace from start to end but just at point start and also as if its detecting whether it within an objects bounds rather than a visual lod.

Although that does not explain the gully walls unless there bounds are huge in the vertical??

Like the vid though that looks awesome for when you finally get it working :)

Edited April 18, 2013 by Larrow

[super-truite 54]

for some reason, I have better result with lineintersects using the eye position of the player (eyePos player).

Before I was attaching an object to his head and I was using lineintersects with the position of this object and it was not working which look like a bug to me.

You should try eyePos.

[Tankbuster 1733]

I couldn't get any sensible results out of it either, and gave up.

[Radioman 6]

In that loop, try running http://community.bistudio.com/wiki/drawLine3D to draw a line between the two points, to make sure the offset is correct.

modeltoworld offsets behave rather oddly.

[Larrow 2808]

Ok after making sure everything seemed to be lining up properly using drawLine3D i decided to take modelToWorld out of the equation and try eyepos with vectorDir player to get a position out in front of the player also lineIntersectWith to get a list of everything I was supposedly looking at.

First thing I noticed is that eyepos is about 3 meters above the players head. On changing the position by taking roughly 3 meters off of the z value i was back to rubbish results from the trace even though the line appears to originate roughly around the position of the players eye. I changed eyepos back to what ever the engine was returning as the value and done a trace straight out in the direction the player was facing.

Voila i get a list of everything thats in front of me down to the smallest sign post, wall, fences etc etc. mmmmm

So whats up here?? are visual models and lods not aligned in the engine or is there something else going on here. Try it out for yourself, add this to the players init and have a walk around town. Youll notice the array in the hint shows what ever is in front of you at eye level but the 3Dline is about 3m above you.

nil = [] spawn {
while {true} do {
	sleep 0.03;
	start = eyepos player;
	pdir= vectorDir player;
	{
		pdir set [_foreachindex, ((_x*5)+(start select _forEachIndex))]
	} forEach pdir;
	end = pdir;
	drawLine3D [start,end,[1,0,0,1]];
	hint str (lineIntersectswith [start,end,helper1,helper2]);
};
};;

[Radioman 6]

http://feedback.arma3.com/view.php?id=5463

[Tankbuster 1733]

I've found eyepos to be unreliable too. I think it's more for use by vehicle mounted gunners rather than dismounted soldiers.

That said, you've managed to get a list of things in front of you, nice job.

[bad benson 1733]

for some reason, I have better result with lineintersects using the eye position of the player (eyePos player).

yea i noticed the same. what i do now is read data from the aimpos (works better for me than eyepos) position array and modify it do get the positions i need. it works like this for some strange reason even though i don't just use aimpos directly but just the data from the position array it gives me.

another thing worth adding is that it seems to only check for viewlod geometry and not geolod geometry when i use it like this. this means that i can't jump over those fences anymore (only the pillars of them as you will see in the video) but it works perfectly with solid walls now.

it's almost seems like the lineintersects command was made kind of flexible depending on the data you feed it with. maybe they use it more for the AI now or something. i hope we get a simple position based one that checks for collision geometry and not view geometry later on though.

anyways. thanks to everyone for your replies. they make this thread useful to people having the same problems.

here's another video of the results i got so far. it's pretty usable for the fact that it's in an engine that isn't made for stuff like that. i need to make some more animations though to make it look better. at the moment i also have to teleport the player at the end of the anims since he switches back to the start position for some reason. and the step on anim is a get in animation i found in the animviewer:D

it's context sensitive which means that everything works with one button.

anyways. enjoy...

here's the code i use to check if something is infront of the player at about shoulder to head height and a second check if the area a bit above that is clear to allow climbing. i use variations of that for my other checks. i know it's pretty messy but it works and is the latest version of my test script. it might change.

_ref2 = aimpos _jumper;

_p = _jumper modeltoworld [0,1,0];

_p1 = _jumper modeltoworld [0,3,0];

_chest = _ref2;

_chest_front = [_p select 0, _p select 1, _ref2 select 2];

_head = [_ref2 select 0, _ref2 select 1, (_ref2 select 2)+1];

_head_front = [_p select 0, _p select 1, (_ref2 select 2)+1];

_roof = [_p1 select 0, _p1 select 1, (_ref2 select 2)];

_knee = [_ref2 select 0, _ref2 select 1,(_ref2 select 2)-0.5];

_knee_front = [_p select 0, _p select 1, (_ref2 select 2)-0.5];

_hip = [_ref2 select 0, _ref2 select 1,(_ref2 select 2)-0.2];

_hip_front = [_p select 0, _p select 1, (_ref2 select 2)-0.2];

edit: then i do lineintersects [_chest, _chest_front, player] and the like...

Edited April 18, 2013 by Bad Benson

[jasin 1]

That video is just full of awesomeness. Nicely done.

[sasij 1]

I've actually had no problem with this function at all. Works great on my end it seems. I've drawn lines and always get the correct eye positions. This is a snippet of the basic code I came up with. Haven't had any issues that I've noticed.

case "Chase":
{
{
	_this doMove (getPos _x);

	if((_x distance _this)<1.5) then
	{
		_state = "Attack";
	};

	if((_x distance _this)>100 || terrainIntersect[ASLtoATL(eyePos _x), ASLtoATL(eyePos _this)] || lineIntersects[eyePos _x, eyePos _this, _x, _this]) then
	{
		_state = "Wander";
		_this setSpeedMode "LIMITED";
	};
}forEach playableUnits;
//drawLine3D [ASLtoATL(eyePos player), ASLtoATL(eyePos _this), [1,0,0,1]];
};

[Larrow 2808]

Just for information incase anyone else sees this thread because their having trouble with weird results from lineIntersects or lineIntersectsWith.

Its because these commands expect a ASL position. e.g

pos = player modeltoworld [0,1,1.8];
pos2 = player modeltoworld [0,3,1.8];
hint format ["%1", (lineintersects [ATLtoASL pos, ATLtoASL pos2])] 

or

nil = [] spawn {
while {true} do {
	sleep 0.03;
	start = player modelToWorld [0,1,1];
	end = player modelToWorld [0,3,1];
	helper1 setPos start;
	helper2 setPos end;
	hint str (lineIntersects [ATLtoASL start, ATLtoASL end,helper1,helper2]);
};
};

or (eyepos actual returns a ASL position so you would just need to fix the 3DdrawLine)

nil = [] spawn {
while {true} do {
	sleep 0.03;
	start = eyepos player;
	pdir= vectorDir player;
	{
		pdir set [_foreachindex, ((_x*5)+(start select _forEachIndex))]
	} forEach pdir;
	end = pdir;
	drawLine3D [ ASLtoATL start, ASLtoATL end,[1,0,0,1]];
	hint str (lineIntersectswith [start,end,helper1,helper2]);
};
};

The discrepency between the 3D line and what Intersects say it was receiving was driving me crazy. Oh for a good nights sleep to make you see clearly. :)

EDIT: yes sasij, beat me to it while i was writing this, had just woken up and immediately realised the mistake :)

Edited April 19, 2013 by Larrow

[l etranger 5]

It looks great.

[norrin 9]

Looks fantastic -very impressed with the animations - just what the game needs

[bad benson 1733]

glad you guys like it. it will be even more fun with more animations that make it look better.

Just for information incase anyone else sees this thread because their having trouble with weird results from lineIntersects or lineIntersectsWith.

Its because these commands expect a ASL position. e.g

damn Larrow and sasij, thanks a lot for keeping at it and figuring it out. i always forget about ASL. i only tried ATL. seems like what i did kept the position data in ASL format and made it work. being able to use modeltoworld will make it a lot less messy though. i also didn't even know about ATLtoASL. how very useful!

EDIT:

_state = "Attack";_state = "Wander";

oh i smell zombies. will you ever release what you got there? looks like a very nice approach for detection!

Edited April 19, 2013 by Bad Benson

[sasij 1]

oh i smell zombies. will you ever release what you got there? looks like a very nice approach for detection!

I dunno. Maybe if I can figure out how to get zombie models into the a3 engine. It works decently but it's not very appealing to see your "zombies" as humans. I just made the zombie code for fun in case I ever felt like doing a mission with zombies.