Support for collision detection?

[axelson]

What problem does this feature solve?

I am working on a simple game to try out scenic. Since scenic already maps an input coordinate through different translations, it would be nice if scenic was also able to accomplish collision detection. In addition to games this might be nice for developing custom responsive ui's.

What is your proposed solution?

Scenic.Graph.collisions(graph) would return all the components that had a collision along with their "final" coordinates.

Notes

Of course it may be reasonable to consider this out of scope for Scenic. It may be too difficult to support permanently.

[cortfritz]

Shouldn’t this exist in a separate module? Many Scenic applications would not use it.

[boydm]

This would definitely go in a separate module.

First, isn't targeted at games (ok if it is used for some tho!), so wouldn't want to fill up the main lib with game targeted code.
Second, not sure there is a "right" way to do it that solves enough game types. Seems game specific to me??

[axelson]

Yeah, those are definitely fair points. Do you have any pointers on getting the transformed coordinates for scene components out of a graph? Or do I need to eschew all the transforms and model all the primitive shapes in my user code? (or just pretend everything is a square)

[cortfritz]

A separate collision detection module seems smart.

Initialize the module as a scenic remote of the viewport.

Register has_collided functions with the CD module. These will reference 2 or more specific primitives, groups, etc in the graph of the viewport to be monitored for collision.

Scenic remoting will replicate graph changes to the CD module.

CD module will respond to incoming graph changes pattern matching on the render against the items marked for possible collision

If a match is made, then math is performed to determine if the change to the referenced graph item has collided with another.

If they have collided then we call the appropriate has_collided func

Right? Wrong?

[ejc123]

A separate collision detection module seems smart.

Initialize the module as a scenic remote of the viewport.

Register has_collided functions with the CD module. These will reference 2 or more specific primitives, groups, etc in the graph of the viewport to be monitored for collision.

Scenic remoting will replicate graph changes to the CD module.

CD module will respond to incoming graph changes pattern matching on the render against the items marked for possible collision

If a match is made, then math is performed to determine if the change to the referenced graph item has collided with another.

If they have collided then we call the appropriate has_collided func

Right? Wrong?

I've been lurking because I started a game and quickly started wanting collision detection.
I really like this idea and using a remote view is brilliant.

[axelson]

Yeah, a remote view sounds like an interesting approach, although I do wonder if there's some overhead that could be avoided. I'll have to think about it some more and look at the remote view docs to understand it better.

[boydm]

Don't know how it would be hooked in yet, but I was imagining an api where you register graph/primitive tuples that you want to track to see if they are colliding. (This gives a minimal set of data that needs to be tracked/reduced at run time). Then when it fines a collision, it would send a message to the requesting scene.

The pro of building this as a driver is that the communication machinery is all there and is fast.

The con of building it as a driver is that it would need to expose an api to the scene. I've tried so far to have the scenes not need to know about drivers. This would break that model, although it is only a philosophical one, not a hard enforce thing.

Thoughts?

[cortfritz]

can the game process be outside of Scenic, materializing scenic elements. my game process materializes a ship and a bullet and stuffs them "into" scenic and stuffs them as a tuple into the CD process. But I still imagine the CD process is a remote viewer of the viewport. It's pattern matching everything that moves as the telemetry comes in to run the math to determine if the "elements" have intersected. Then it calls back to the game process, not scenic.

right?

[cortfritz]

@boydm: it might be good to be able to put in a filter in the telemetry send pipeline. Only relevant changes get sent. In the above scenario the "game" would put the your graph tuple in the CD module and also put the tuple into a filter in the pipeline in the telemetry being sent from scenic to the CD module. The function put in would have the tuple, would inspect the change to see if a parent of one of the graph items had changed, thus translating the graph item, or if one of the graph items had itself changed. Then pass that on.

This would minimize events sent over wire to CD module.

Not sure if that's needed or helpful, but it occurs to me that a general pipeline for remoting on the scenic side would be helpful for filters or other purposes. May already exist.

[crertel]

I'd argue you'd probably want to have the dumbest-possible/flattest scenegraph, and use scenic just for the input/rendering layer. Like, you might be better off just keeping the scenegraph under the control of your physics code and occasionally walking the important bits and sending them back to scenic for rendering.

[crertel]

Closing this as aged-out for now.