fine collision detection about flappy-svg HOT 18 OPEN

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).

from flappy-svg.

I would like to work on this Issue.

from flappy-svg.

#114 implements the collision detection by @vikasTmz.

from flappy-svg.

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]

from flappy-svg.

@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?

from flappy-svg.

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

from flappy-svg.

@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 ?

from flappy-svg.

@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 -->
...

from flappy-svg.

@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.

from flappy-svg.

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.

from flappy-svg.

@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 ?

from flappy-svg.

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
#71 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAieIOT-XQ4x5Kxb3OfDVSLX9Hz9bFUwks5qa22SgaJpZM4HVEK3.

from flappy-svg.

@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.

from flappy-svg.

@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.

from flappy-svg.

(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.

from flappy-svg.

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

from flappy-svg.

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
#71 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAieILnlAkelciXoo_8mq4aYS-E8prtWks5qcu0xgaJpZM4HVEK3.

from flappy-svg.

@harry-7 updates

from flappy-svg.