Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for collision detection? #91

Closed
axelson opened this issue Oct 21, 2018 · 11 comments
Closed

Support for collision detection? #91

axelson opened this issue Oct 21, 2018 · 11 comments

Comments

@axelson
Copy link
Collaborator

axelson commented Oct 21, 2018

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
Copy link

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

@boydm
Copy link
Collaborator

boydm commented Oct 22, 2018

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
Copy link
Collaborator Author

axelson commented Oct 24, 2018

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
Copy link

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
Copy link

ejc123 commented Oct 25, 2018

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
Copy link
Collaborator Author

axelson commented Oct 25, 2018

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
Copy link
Collaborator

boydm commented Oct 25, 2018

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
Copy link

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
Copy link

@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
Copy link
Contributor

crertel commented Nov 28, 2018

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
Copy link
Contributor

crertel commented Dec 16, 2023

Closing this as aged-out for now.

@crertel crertel closed this as completed Dec 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants