fine collision detection

[niccokunzmann]

Currently, we have a collision detection that checks the rectangle of the obstacle. This leads to a lot of hits even if there are no. See #4 for suggestions.

The new collision detection reduces the number of wrong hits. Comment if you would like to do this.

[vikasTmz]

Hey, One way to do this is using the below ABBA collision. I've done one in Opengl (using glm vectors).
A similar one can be implemented using vector.js (a 2D vector maths library).

[hkveeranki]

I would like to work on this Issue.

[niccokunzmann]

114 implements the collision detection by @vikasTmz.

[niccokunzmann]

I would propose further changes for fine-grained collision detection:

Context
Obstacles can be a group <g>. This is the same as a group in Inkscape.

Proposals

• We can check every element in this group for this kind of collision detection, maybe go deep to a certain level or until we have a certain amount of obstacles checked. This would e.g. test each arm of a cactus instead of the whole cactus itself.
• If we do this kind of collision detection, we would also need to document it for people who create obstacles in this task.

Problems

• This can mean that we need to re-group the obstacles for best performance. We would need to check if this still works. [by harry-7]
• Not all obstacles are groups or need to be groups. This approach would need to check if the obstacle is a <g> element before looking at the insides. [by harry-7]

[hkveeranki]

@niccokunzmann sounds like a great idea. But that needs that we need to change the existing obstacles. Also in inkscape we cant group a single item right. Wont that be a problem?

[niccokunzmann]

@harry-7 I integrated your concerns into a new problems section. Do you agree?

[hkveeranki]

@niccokunzmann Yes . Also it will be better if we rely on attributes like class/id when obtaining obstacles rather depending on grouping. In that case we group obstacles for convenience of moving etc but still check independent elements on collision. What say ?

[niccokunzmann]

@harry-7 What would this look line on dom level?

currently, we have, I believe

<g inkscape:groupmde="layer">
    <g><!-- here comes an obstacle -->
    </g>
    <rect> <!-- here comes an obstacle -->
...

[hkveeranki]

@niccokunzmann In the level we have the groups with the group will also come as obstacle so we do unnecessary checks. How ever if we do some thing like this it will be good

<g inkscape:groupmde="layer">
<g class='obstacle'> <!-- here comes an obstacle -->  </g>
<rect class='obstacle'> <!-- here comes an obstacle --> 
...

Then we will be able to do the collision checks efficiently.

[niccokunzmann]

What is the goal you want to achieve? You wrote "better" or "good". How would you measure it.

More context: obstacles are grouped in layers. Once a layer is used as an obstacle, child of it becomes an obstacle.

In case your goal is to make collision detection finer than ABBA with the whole group, this would be to me that we look into the group. I do not understand how adding a obstacle class improves collision detection.

[hkveeranki]

@niccokunzmann By good I mean it will reduce unnecessary collision checks we make.

I ll add class to the most fundamental part of the obstacle. the child which no more has any groups in it. I wanted to add class because

• I am not sure whether we can access the child elements when we get the obstacles by the tag name <g> .
• If we add a class we can get all those things at once without going recursively.
• If an obstacle is not a group then also we can get them as obstacles which we cant do if just get all elements with <g>.
• This will deal with the case if a group is not obstacle as well. (This is already handled by other technique currently but still it will be usefull)

Does this make sense ?

[niccokunzmann]

If we add a class, this must also be easy to do in Inkscape.

We access child elements if zou look here https://github.com/fossasia/flappy-svg/blob/gh-pages/javascript/layers.js#L7.

Am 30.07.2016 um 17:28 schrieb Hemanth Kumar Veeranki:

@niccokunzmann https://github.com/niccokunzmann By good I mean it will reduce unnecessary collision checks we make.

I ll add class to the most fundamental part of the obstacle. the child which no more has any groups in it. I wanted to add class because I am not sure whether we can access the child elements when we get the obstacles by the tag name || . Also if we add a class we can get all those things at once without going recursively . Does this make sense?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fossasia/flappy-svg/issues/71#issuecomment-236371275, or mute the thread https://github.com/notifications/unsubscribe-auth/AAieIOT-XQ4x5Kxb3OfDVSLX9Hz9bFUwks5qa22SgaJpZM4HVEK3.

[niccokunzmann]

@harry-7 Could you help me analyze the situation, so we can make sure we talk about the same? I also loose track when the conversation gets longer.

I would split up the problem like this:

1. How do I find out if an SVG element is an obstacle?
2. How do I find all obstacles that flappy could collide with?
3. If I have an obstacle, how can I detect collision?
4. If I have an obstacle, how can I reduce the computation that is performed for collision all the time?

Can you split up the problem into more questions? Then, we can refer to them and tackle the separately. This can help me not getting confused.

[hkveeranki]

@niccokunzmann I think those will be enough. We currently have the idea of the third topic. My suggestion of adding a class to all obstacles will help in 1 and 2.Coming to issue 4 we can proceed to implement collision to detect each obstacle object instead of whole group as you mentioned here

Proposals We can check every element in this group for this kind of collision detection, maybe go deep to a certain level or until we have a certain amount of obstacles checked. This would e.g. test each arm of a cactus instead of the whole cactus itself.

[niccokunzmann]

(3) Given that we know the boundary of the obstacle, the term for this collision detection is "polygon intersection". We do not need an algorithm that computes the polygon intersection, we just need one that tells us if there is a polygon intersection. Implemented e.g. by this library there may be others for JavaScript.

[hkveeranki]

@niccokunzmann We already have implemented the collision for rect's right. I don't get the idea why we need a polygon collision.

[niccokunzmann]

I do not require polygon collision to be implemented. I would like to outline the differences in granularity:

Evaluation: Polygon intersection and recursive rectangle are not so different. The question is the run-time of the implementation.

Am 05.08.2016 um 09:58 schrieb Hemanth Kumar Veeranki:

@niccokunzmann https://github.com/niccokunzmann We already have implemented the collision for rect's right. I don't get the idea why we need a polygon collision.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/fossasia/flappy-svg/issues/71#issuecomment-237781879, or mute the thread https://github.com/notifications/unsubscribe-auth/AAieILnlAkelciXoo_8mq4aYS-E8prtWks5qcu0xgaJpZM4HVEK3.

[abishekvashok]

@harry-7 updates