Is there any way to get more infos about the object you collided with?
An idea could be: in ZExpression, one could use the keyword "this" for referring the current model, and a different keyword like "collided" for referring to the other model.
By doing this, one could be sure about position, speed, and so on.
EG: something like
DistanceOnX = this.Position.X - collided.Position.X;
Is it possible to do something like that?
More informations about collided object
Moderator: Moderators
Hi Francesco,
The problem with something like a Collided. reference for ZExpression is that this won't be any good when you could have multiple collisions occurring at the same time. Even the current Category approach is a little limiting as there is a maximum of 32. So giving each instance their own Collision category is only a option when you never need more then 32 instances that utilize collision.
This is the work-around that I currently use. Give all models that cause the same behavior on models they collide with the same collision category. Then for each collision category that you want to collect information of, I create a RenderTransform component which I name appropriately. Then figure out if there are any categories that need support for multiple simultaneous collisions. For those categories create a counter and the appropriate amount of extra RenderTransform components to collect data of those instances. Then on collision let instances pass their data to the RenderTranform according component, which can then be collected by whoever needs it. Make sure to spawn your objects in a order that makes sense ( static objects first ).
It's quite a bit of hassle, but with this approach you can even create all the collision behavior you'd need for a 3d action or platforming game ( using the X/Y as floor, and Z as up due to Rect2D_OBB ).
*I even previously claimed that slopes would not be possible, but using this method it's actually not all that difficult. Attached is a example. Use Arrow Keys to Move, A/D to rotate the camera.
Good luck,
K
The problem with something like a Collided. reference for ZExpression is that this won't be any good when you could have multiple collisions occurring at the same time. Even the current Category approach is a little limiting as there is a maximum of 32. So giving each instance their own Collision category is only a option when you never need more then 32 instances that utilize collision.
This is the work-around that I currently use. Give all models that cause the same behavior on models they collide with the same collision category. Then for each collision category that you want to collect information of, I create a RenderTransform component which I name appropriately. Then figure out if there are any categories that need support for multiple simultaneous collisions. For those categories create a counter and the appropriate amount of extra RenderTransform components to collect data of those instances. Then on collision let instances pass their data to the RenderTranform according component, which can then be collected by whoever needs it. Make sure to spawn your objects in a order that makes sense ( static objects first ).
It's quite a bit of hassle, but with this approach you can even create all the collision behavior you'd need for a 3d action or platforming game ( using the X/Y as floor, and Z as up due to Rect2D_OBB ).
*I even previously claimed that slopes would not be possible, but using this method it's actually not all that difficult. Attached is a example. Use Arrow Keys to Move, A/D to rotate the camera.
Good luck,
K
- Attachments
-
- Slopes.zip
- (37.79 KiB) Downloaded 513 times
ok I have not get how do you do that. I suppose I have some english-related problems or stuff like that 
however, it is not important.
The thing I would like to do is the following: given N balls (N = number of balls) when they collide each other, calculate the "collision point" (the midpoint between the centers of the 2 balls). And I would like to avoid using 32 different collision categories as I would like "clone" for ball spawn.
If one was able to use "collided" that would be really easy.
The multiple collisions are not a big problem, because the collided. reference would change like the App.CollidedCategory does...
More: you can always keep the App.CollidedCategory alive for backward compatibility...
PS:
Maybe I have not understood your objection
however, it is not important.The thing I would like to do is the following: given N balls (N = number of balls) when they collide each other, calculate the "collision point" (the midpoint between the centers of the 2 balls). And I would like to avoid using 32 different collision categories as I would like "clone" for ball spawn.
If one was able to use "collided" that would be really easy.
The multiple collisions are not a big problem, because the collided. reference would change like the App.CollidedCategory does...
More: you can always keep the App.CollidedCategory alive for backward compatibility...
PS:
Maybe I have not understood your objection Hi Francesco,
I understand what you're asking for, but that method won't cut it as soon as there will be multiple collisions occurring on one instance. I've attached a image illustrating such a situation. If you'd have a ZExpression on the Pink Sphere using Collided.Position.X .. would it have to return -1 ( Aqua ) or 1 ( Yellow )?
K
I understand what you're asking for, but that method won't cut it as soon as there will be multiple collisions occurring on one instance. I've attached a image illustrating such a situation. If you'd have a ZExpression on the Pink Sphere using Collided.Position.X .. would it have to return -1 ( Aqua ) or 1 ( Yellow )?
K
- Attachments
-
- Spheres.jpg (30.44 KiB) Viewed 10630 times
when you are in the same situation using App.CollidedCategory, how does current collision works?
Prove me wrong, but you should get 2 collisions: OnCollision is called twice, one time with App.CollidedCategory = "Category of Yellow" and the other time with App.CollidedCategory = "Category of Cyan".
It should work the exact way: You get two collisions (OnCollided should be called twice) and everytime the collided. reference is different.
PS: I might be wrong but I don't think so
Prove me wrong, but you should get 2 collisions: OnCollision is called twice, one time with App.CollidedCategory = "Category of Yellow" and the other time with App.CollidedCategory = "Category of Cyan".
It should work the exact way: You get two collisions (OnCollided should be called twice) and everytime the collided. reference is different.
PS: I might be wrong but I don't think so
Hi Francesco,
Ah like that Ok, I guess you can just cache all of the Collision values ( + count the amount of Collisions occured ) and calculate the appropriate behavior from all those together afterwards in OnUpdate then. You probably still want to use a component like RenderTranform to easily store all the values in though .. but this would make it a little easier yes.
Would be nice if you could choose a Variable type ( Vector, Matrix ) in the DefineVariable component actually
K
Ah like that
Ok, I guess you can just cache all of the Collision values ( + count the amount of Collisions occured ) and calculate the appropriate behavior from all those together afterwards in OnUpdate then. You probably still want to use a component like RenderTranform to easily store all the values in though .. but this would make it a little easier yes.Would be nice if you could choose a Variable type ( Vector, Matrix ) in the DefineVariable component actually
K
Hey Francesco,
That's the way I use it yes. It doesn't work automatically obviously, you'll have to store which rows / RenderTransformGroups are occupied by which Clones ( each get their own ID OnSpawn ) yourself. But I find it much more convenient then having to define a Float for each variable that you want to push around ( since it's 9 variables per component ). Even though I might loose some CPU time from the execution of those components ( not sure if they check whether they are empty or not ).
K
That's the way I use it yes. It doesn't work automatically obviously, you'll have to store which rows / RenderTransformGroups are occupied by which Clones ( each get their own ID OnSpawn ) yourself. But I find it much more convenient then having to define a Float for each variable that you want to push around ( since it's 9 variables per component ). Even though I might loose some CPU time from the execution of those components ( not sure if they check whether they are empty or not ).
K
-
jph_wacheski
- Posts: 1005
- Joined: Sat Feb 16, 2008 8:10 pm
- Location: Canada
- Contact:
cool idea!
Francesco - indeed that is an issue that has been troubleing me as well,.
Kjell - wow that is neet! I am trying to understand what you are describing,. and I think i kinda' get you,. however I would also lov to see a small example .zgeproj just of how you are passing the values and sorting the instances that touch. No big rush,. just whenever you get around to it, as I would not want to take you away from the joystick implementation
! I am really looking forward to that one!!! peace.
Kjell - wow that is neet! I am trying to understand what you are describing,. and I think i kinda' get you,. however I would also lov to see a small example .zgeproj just of how you are passing the values and sorting the instances that touch. No big rush,. just whenever you get around to it, as I would not want to take you away from the joystick implementation
! I am really looking forward to that one!!! peace.iterationGAMES.com