ray intersection with current collisions?
Moderator: Moderators
- jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
ray intersection with current collisions?
We now have the niffty Ray / Box Intersection scripts provided by Diki with Kjell,. however I was wundering if we could see a scripting integration of this sort of thing with the built in collisions? My thought is that since the engine is already keeping track of all the models and can do the OnCollision stuff based on this,. then perhaps having a script function like lineCollide(CollidedCategory,x,y,x2,y2) that would trigger a collition of the given CollidedCategory would not be too hard to implement. Also usefull would be a pointCollide(Category,x,y),. I suppose these could work either or both directions,. i.e. function returns true if there is a collision were specified and/or causing the OnCollision of the model were specified. This is just something I would find very usefull.
iterationGAMES.com
These kind of GM-style functions would be great to have. However their use would be limited if they only returned true or false depending on collision, they should return the model that caused the collision (or even better a list of all models that the ray crosses). And to make that possible we first need to solve the problem of nr 6 on Kjells list: Clone access. That has always been high on my priority but it requires lots of changes in scripting so I cannot promise when it will happen.
Hmm,
From my experience the intersection point is the most important result from a ray intersection ( which can be the origin+velocity when no intersection has occured ), but you're right .. you usually want to use a combination of results that such intersection check generates ( in which case it makes more sense to make it a Component, so you can collect the values from read-only properties ).
For example, here's what the "component" looks like in Virtools ( normalized direction vector+depth instead of velocity ).
K
From my experience the intersection point is the most important result from a ray intersection ( which can be the origin+velocity when no intersection has occured ), but you're right .. you usually want to use a combination of results that such intersection check generates ( in which case it makes more sense to make it a Component, so you can collect the values from read-only properties ).
For example, here's what the "component" looks like in Virtools ( normalized direction vector+depth instead of velocity ).
K