Vector-Based Collision

[Admins]

Ok I understand, don't know why the function should care about the rotation of the colliding line though, since movements must be linear anyway (by setting positions explicitely or using the move command).
The simpliest way would probably be to just check for the tiles by script (several onwall checks along the line in steps of 1 tile). That way you can also theoretically detect diagonal walls. I can add some command for easier collision detection though, but it should be made so that it can be used for many different cases of collision.

[Kaimetsu]

Originally Posted by Stefan

Ok I understand, don't know why the function should care about the rotation of the colliding line though, since movements must be linear anyway

Well, moving linearly from point A to point B between two frames is just an approximation to a smooth, continuous motion. There'd be a difference between a curved path and a linear one, even if it's relatively small.

The simpliest way would probably be to just check for the tiles by script (several onwall checks along the line in steps of 1 tile). That way you can also theoretically detect diagonal walls

Yeah, it kind of works, but you can't get much precision unless you use dozens of checks. Recently I made a little system that scans through the level and builds an array of vectors representing walls (like, if there were a bush in a level then it would define a wall vector for each of its sides). Then I used some fairly simple vector calculations to find out exactly where and when a collision would occur between a wall and a moving object. It's very fast and extremely precise, but it can't handle dynamic objects (players, movable tiles, etc) or NPCs with weird shapes. It's really only good for minigames.

Out of curiosity, how does collision detection work in Graal3D? I haven't had a chance to play with its scripting engine yet

[Admins]

Originally Posted by Kaimetsu

Yeah, it kind of works, but you can't get much precision unless you use dozens of checks. Recently I made a little system that scans through the level and builds an array of vectors representing walls (like, if there were a bush in a level then it would define a wall vector for each of its sides). Then I used some fairly simple vector calculations to find out exactly where and when a collision would occur between a wall and a moving object. It's very fast and extremely precise, but it can't handle dynamic objects (players, movable tiles, etc) or NPCs with weird shapes. It's really only good for minigames.

Would be interesting to see that script We plan to soon add an automatic movement and collision system for showimgs for making client-side games. For serverside it could be interesting to add more shape modes for the setshape command (circle, oval, centered box) and make a function for knowing with which objects the npc/player collides if moved along a specified vector, with options for which objects should be handled (only npcs, only players, only tiles etc.) and returning the impact position, the distance the npc moved, and eventually the collision normal or reflection vector.

Originally Posted by Kaimetsu

Out of curiosity, how does collision detection work in Graal3D? I haven't had a chance to play with its scripting engine yet

It is using the polygons of the objects and is handled by engine. It is taking the polygons of the player and the velocity, and is colliding it against near objects, getting the polygon that touches the thing and the distance. Currently it is not very fast though, so it's basicly taking a box for the players. Only the interior objects (houses, caves) have are more optimized collision detection and use all polygons for collision detection. We will need to change that sometime, to use better collision libraries and make the player movement completely scripted.

[Kaimetsu]

Originally Posted by Stefan

Would be interesting to see that script

Okay. I attached it to this post.

As a sidenote: It would be nice if there were an event that triggers on the clientside when the board is updated (if there isn't already - I'm a little out of the loop). Since my script just scans the level once when the player enters, it can't deal with changes like when somebody picks up a bush.

We plan to soon add an automatic movement and collision system for showimgs for making client-side games

Hm, sounds like a good idea. If it were my decision, I think I'd just add a single function that takes two images and their positions and tells the script whether or not they intersect. Then it'd be pretty easy to work into minigames, but it would also be flexible enough to use for other applications (like, if you want to check a possible collision without actually drawing an image).

For serverside it could be interesting to add more shape modes for the setshape command (circle, oval, centered box) and make a function for knowing with which objects the npc/player collides if moved along a specified vector, with options for which objects should be handled (only npcs, only players, only tiles etc.) and returning the impact position, the distance the npc moved, and eventually the collision normal or reflection vector

That sounds pretty good. Maybe also some way to define the shape and rotation of the player?

It is using the polygons of the objects and is handled by engine. It is taking the polygons of the player and the velocity, and is colliding it against near objects, getting the polygon that touches the thing and the distance

Hm, that raises an interesting point. Does G3D use varying LOD meshes? If there were a simpler mesh used purely for collision, it'd probably make things a little faster.

We will need to change that sometime, to use better collision libraries and make the player movement completely scripted.

Yeah, sounds like a pretty significant improvement. I had a rough design for a G3D playerworld, but it wouldn't work unless I had a large amount of control over the player's movement.

Originally Posted by Googi

Would it work online?

My vector thing? Yeah, I guess. But it's not very useful in its current state.