Find Target

Blitz3D Forums/Blitz3D Programming/Find Target

Jack(Posted 2012) [#1]
I hope I can explain clearly.

Let me strart buy saying that for various reasons I do not want to use the command "Point Entity" after each move.

There is a hill on which both the entity and target are located.
The entity needs to move horizontally across the hill to the target.
Since the hill is sloped (yep really) the entity,which is on the gound,
will tend to move toward the bottom of the hill.
My collision detection is working fine.

Since I want the entity to finish exactly on the target I need to compute how far up the hill to aim using "PointEntity" at a "temporary target".Of course I know the height of the hill at each move point and need not consider gravity,friction,force,etc.,for this particular calculation.

Sure hope this make sense and any help would be great.


GfK(Posted 2012) [#2]
Not sure i understand but DeltaPitch() and DeltaYaw() might be what you need to determine the angle from one entity to another.


Yasha(Posted 2012) [#3]
If you want to move your entity without regard for gravity, is there a reason why you can't just have gravity or sliding collisions not apply to it while making this movement?

If possible it's better not to involve the collision system at all, rather than try to undo its work.


Jack(Posted 2012) [#4]
Gfk
I have tried using DeltaPitch() and getting that "number" at each point the object moves.

However,that alone gives no way to find an aim point. I have tried making a cumulative total,by adding each DeltaPitch() number together but this gave no reasonable number.

Advanced math skills have long vanished for me but it seems there should be a way to use some formula to do this.

Thanks for the reply Gfk.


Jack(Posted 2012) [#5]
Yasha...

Right about not involving the collision system. That is what I have been doing in my code. I meant to indicate that when I mentioned the collision
factor.

I guess I should have worded it in another way since it would be the gravity that makes the object head toward the bottom of the hill. That is what makes me need to find the aim point higher on the hill.

I have the DeltaPitch form one spot to another but I need to be able to aim higher on the hill based at each point on the hill.

This too may be a lousy explaination which is why I try to stay away from texting rather than talking.Of course there is no choice on a forum.

Thanks for the input Yasha.


RGR(Posted 2012) [#6]
.

Last edited 2012


Stevie G(Posted 2012) [#7]
I think this is what you need:

http://warpycode.wordpress.com/2009/10/10/aiming-a-projectile-uphill/


Jack(Posted 2012) [#8]
Stevie G

Thanks for the reply.

That math is way over my head but it unless I am missing something that is not what I need. My object must follow the path of the ground and stay on the ground. Like a rolling ball.

Maybe that code could be used someway but like I said my math is not good enough to understand how to make it apply.


Floyd(Posted 2012) [#9]
This should not be too hard for a very simple case, such as the ground being a tilted plane. Other simple shapes would be more difficult but still not too bad.

If the ground is an arbitrary terrain then the problem sounds intractable.


Kryzon(Posted 2012) [#10]
Can you make a diagram of how you want things to behave? I don't understand what the problem is exactly.

EDIT: Take a look at LinePicking with PickedX, Y and Z.

Last edited 2012


Jack(Posted 2012) [#11]
Floyd & Kryzon....thans for the reply.

"from Floyd " - "If the ground is an arbitrary terrain then the problem sounds intractable"

Yep -- thats what it is and I'm beginning to think you are right.

Kryzon.... I have no problem getting the values. Its putting them to use that is the problem.


Stevie G(Posted 2012) [#12]
So you're not shooting a projectile?

If you just want an entity to move to a target when either point is on the terrain I don't understand why this is an issue? It is essentially a 2d problem.

Something along the lines of...

if  entitycollided( Entity, TYPE_TERRAIN )
  if entitydistance( Entity, Target ) > 5 ; change 5 as required
    Dy# = deltayaw( Entity, Target ) * .25 ;use .25 to get smoother turn
    Turnentity Entity, 0, Dy, 0
    Moveentity Entity, 0, 0, 1 ;change 1 as required
  Endif
Else
  Translateentity Entity,0, -.05, 0    ;simulate gravity
Endif


If you have sliding collisions on then it may be that the slope is too large for the speed of movement to overcome. Try using collision response 3, instead of 2.

If the entity is being aligned to the terrain, you could parent the entity to a pivot and only apply the yaw changes to the pivot.

If I've misunderstood the problem again please give alot more detail.

Stevie


Floyd(Posted 2012) [#13]
I think the problem is essentially "make a putt on an undulating green". You may have to aim some place nowhere near the target.


Jack(Posted 2012) [#14]
Floyd -- Thats about it. Good description and thanks.

Stevie G --- I used something like you mentioned but that sometimes makes for funny movement. Probably a little more tinkering might make
that work but it would seem to be an artificial way of reaching an answer.
Thanks for your input. I appreciate it.


Stevie G(Posted 2012) [#15]
@ Jack,

If you'd described that in the first place you may have got a decent answer ;)

As you say, there are too many variables to consider to simply find a single solution mathematically.

What you could do (without rendering) is an iterative approach which will theoretically converge on the result. Start with an angle which is directly to the hole and pick a good guess at the speed based on the distance to the hole and terrain. Give the result a score for angle, based on whether the ball ends up to the left or right of the hole*. For speed, score it based on how close to the hole it got**. Rince and repeat, adjusting the angle and speed by small steps each iteration until the ball goes into the hole. There may be situations where it's impossible to converge on a solution so you should limit the maxmium iterations. If you hit a solution and then need to dumb it down just add a random factor to the angle and to the speed.

* At the start of the process place a pivot at the hole position and use pointentity to point it to the balls starting position. Once the ball has stopped you can then use tformpoint 0,0,0,Pivot,Ball. Tformedx() will tell you how far left or right the ball ended up in relation to the hole.

** Similarly, tformedz() will tell you how far infront or behind the holw the ball ended up.

Last edited 2012


Jack(Posted 2012) [#16]
Stevie G

from Stevie G.----"If you'd described that in the first place you may have got a decent answer ;)"


Whoa.

I appreciate your help but I thing that was unnecessary.


Jack(Posted 2012) [#17]
Stevie G

Just to add. Since your comment was irritating.

An eaiser way is to just turn the object a small amout and give it a test run till the object hits the target. Not very time consumng
when no rendering is done.

I did this before ever asking the question.But for various reasons I thought possibly there might be a math answer.


Stevie G(Posted 2012) [#18]
You were irritated that I suggested that you hadn't described your problem in enough detail? Did you notice that almost everyone who posted included a 'not sure I understand' or 'I think the problem is'? Ho-hum.


Jack(Posted 2012) [#19]
yea.


Kryzon(Posted 2012) [#20]
Hi Jack, don't worry about it. Stevie G is a great guy and I'm sure he didn't mean to irritate you.

(I'd attribute the misunderstanding to that blinking smiley. I think they do more harm than good, so I don't even use them.)


Jack(Posted 2012) [#21]
Thanks Kryzon. Appreciate it.

It is a good bunch here at Blitz. Real good.