GPU RayShooting and autonomous racer in track without waypoints

[Petr Schreiber]

Hi,

as I know how problematic it is for mobile robots to move in space according to ray shooting, I was a bit afraid it will not work so good for the race.

But the results look promising so far!

Let me introduce first dummy "I do not know anything about track, lets trust sensors" example.
I do not calculate any ray-triangle intersections, I do simple ZBuffer rayshoot query.

The "racer" has just front and left/right sensors.

Hope you will like it, keep in mind this is just beginning. I know the vehicle moves like drunk :)


Petr

UPDATED ATTACHEMENT

[ErosOlmi]

Well, it is just a beginning but ... wow ... what a beginning :o

[Michael Hartlef]

:o That proofs that my idea works. Great!

[Petr Schreiber]

:)

Your idea was very good Mike, it can save us some work.
It is simply great to know we can throw the object to any environment and it is able to navigate without need for any details.


Petr

[ErosOlmi]

The idea can open lot of new possibilities.
And maybe the idea of rays can be encapsulated in entity system directly as native feature ( attention ... Petr will kill you ! :-X )

[Petr Schreiber]

No,

I do not kill people ... usually ;D
That reminds me ... did you sent me that Beretta already Eros?


Petr

[ErosOlmi]

Yyyyeeeees ... that remember me something !
Attention guy, I'm Italian 8)
;D

[kryton9]

That is cool Petr.

I think it could be easier and faster if you just have it balance the distance from left and right sensors and have it move forward.

In the race, when the front sensor senses another vehicle for instance, it could then use more sensor input to determine which side to pass on or if not enough room to brake or slow down.

[ISAWHIM]

I was having a problem with the car driving through the first turn, and driving through the one on the bottom. (Your distance code is also causing unnatural "hopping", which is why I multiplied it by 10. It gets progressively slower as it approaches a target, then zooms full speed the further the target is away. EG... 40MPH, 30MPH, 20MPH, 10MPH, 5MPH, 1MPH, 0.5MPH, 0.1MPH, {Target hit}, 100MPH, 90MPH, 80MPH...)

The problem may be that you have two "Continuity" values. (Time)... Game-frame = time and distance-per-frame = time. (Essentially, your SPEED is powered by 2 times... thus, as it nears, is progressively slower, not linear, as the use for Game-frame is intended.)

You will still need waypoints, or it will not know where to go, or if it is headed in the correct direction. (Humans use them, why would a program not use them? The lines on the road, posted signs, and knowledge of the destination are our track-points.)

If anything, feelers and a track-point system as one, might maximize the operation.

(Drop the ship outside the track... It NEEDS way-points.)

The points have to be there to determine if we, or the AI, are stuck or are finishing without cheating. (Driving across the field, taking a shortcut, or after being flipped into a shorter destination, like through an overpass.)

The feelers would be great from a "Thinking" perspective, because an AI could "Ride the wall" to cut time, but not hit the wall, and be slowed-down... while being able to detect that it needs to pass someone else riding the wall. But, I do not see the feelers alone, operating the AI to win a race.

Not sure if you go here... but I find a lot of the info real helpful for my simulation programs. (Not the specific page, but the site in general.) LOL, I forgot to put the link!

Here it is...
http://www.gamedev.net/reference/list.asp?categoryid=28

I don't entirely know how these "probes" work... but is it based on this concept?
http://www.gamasutra.com/features/20000210/lander_02.htm

I failed horribly at attempting to modify any of the numbers in the formula. (Not sure why you have speed resetting to 0.)

I am following this (The method), still, with strong interest. (I learn from all your code.)

[Petr Schreiber]

Hi Kent,

you are right about the balance, that would be better.

Jason,

as I said, this is just concept demo, not final AI or anything. I just needed to test if sensors are way to go, not provide perfect AI at this moment. After reading your post I want to hang myself :D



(Your distance code is also causing unnatural "hopping", which is why I multiplied it by 10

What did you multiplied by 10? Could you provide code?



The problem may be that you have two "Continuity" values. (Time)... Game-frame = time and distance-per-frame = time. (Essentially, your SPEED is powered by 2 times... thus, as it nears, is progressively slower, not linear, as the use for Game-frame is intended.)

How do you know what was intented :D
If I shift anything at 10 / FrameRate, it is basically moving at 10 m/s.



(Drop the ship outside the track... It NEEDS way-points.)


Why I would do that? I like on this approach the track designer is not obligated to set waypoints.
I agree GameDev is good resource.


Petr

[ISAWHIM]

LOL, don't hang yourself... :'(

I was just saying that the drunk mouse doesn't know which way is forward, or if he is even on the track. (I know you were just playing with the feelers. I was being a smart {Fill in bad word here}.)

The "Distance", value in the formula... Which is +(distance), and I put +(distance*10).

You are setting a specific distance, over a timeframe... (Distance is (speed over time)) which you than again, divide by time... (You add the distance form the point to the speed, and then divide by time?)

Distance form the point should be used to adjust speed, only when the distance from the point is within range, and only if adjustment is required. (I am not sure why you add the distance from the target, to the target PUSH value.)

MIN(slow,fast) will not be good for actual game-play... because that turns the player into a brick-wall if you collide into them. When you are hit from behind, you move faster than your max-speed, and 0 is min? (I may not understand the implementation of that code, but multiplying the distance * 10 was the only solution that produced realistic motion, no matter what speed the vehicle was moving. I am starting to think that is just a generic code you use to test... but I thought it was part of the AI code, which would be moving the other players.)

I am working on the physics values, which you should be able to use without having to re-formulate for every style of sensor calculation. You only have to output the FORCE modification of the sensor/control. I will make a separate post for GAME PHYSICS, since they are not specific to AI, but part of it.

I LOVE the sensors... I just didn't understand how they work, and the movement code was not helping me understand, since it stopped the mouse as it was trying to move forward.

I still don't understand how this code knows if it is going the correct direction. (Without way-points, it will still take the shortest path, if it can feel its way there. Like at an intersection where it could be bumped onto a shorter destination, or if it were flipped out of the track, onto the scenery.)

[Petr Schreiber]

Hi Jason,



LOL, don't hang yourself...

Ok, I won't :)

Thanks for explanations!



The "Distance", value in the formula... Which is +(distance), and I put +(distance*10).


Did you mean this part?


Speed = MySensors(%sensor_front).distance
' ...
TBGL_EntityPush(%sScene, %eVehicle, 0, 0, Speed/FrameRate)

I must admit my naming of variable was dirty indeed.

In fact the Speed/FrameRate equals to:


<distance> / ( 1 / <timeOfFrame>)


which equals too


<distance> / <timeOfFrame>


which is basically speed shift. Like from that velocity = distance / time basic formula.



I LOVE the sensors... I just didn't understand how they work

Time for explanation ... :)
When you render image using OpenGL, you are able to retrieve x,y,z value of every pixel rendered.
So ... to get distance sensor-obstacle, I used dummy camera put at place and direction of sensor, rendered image ( at supertiny resolution ) from there ( just to memory, not to screen ) and read the x,y,z value of center pixel. Then I calculated distance sensor-(x, y, z) ... and that is what goes into sensor.

I am looking forward to your physics calculations, I am currently working on particles again, to go according to plan :)

How the drunk cube knows where to go?
We take as fact the track has left and right border. Then in case distance from left sensor is too small, we turn right; if distance from right sensor is too small we go left. That keeps the object on "drunk man straight line aproximation".

The front sensor is used to calculate that controversial speed :) - if there is lot of space in front of cube, it can afford to go faster, if little space, it is going slower.


Petr

[Michael Hartlef]

So ... to get distance sensor-obstacle, I used dummy camera put at place and direction of sensor, rendered image ( at supertiny resolution ) from there ( just to memory, not to screen ) and read the x,y,z value of center pixel. Then I calculated distance sensor-(x, y, z) ... and that is what goes into sensor.


Rendering the image all the time and for every sensor would mean a lot of performance eaten by that when you have up to 7 vehicles (my guess as max vehicles on the track) to calculate.

Why don't you look into ray cast collision?

[ISAWHIM]

Which direction...

If it gets hit and faces the wrong way... (How does it know that left is not left, and right is not right?)

I am sure it will follow the wall quite well, backwards, staying equal distance from the left/right, which is now right/left. (I sort-of get the camera thing... I didn't realize cameras could be "unrendered", but I am familiar with mirror/cam tricks for reflections.)

Sorry, the distance comment was towards the other AI, with the track. (That trick did not work here. LOL.)

Found a small glitch with the game-timer also... (If not called initially, it is 1 on the first cycle. If time is greater than 1FPS, the value is 1. EG, 0.5 FPS = 1FPS... Would eminently cause a crash, when the game should be seeing that as an excuse to shut-down, or lower detail. Compared against the highrestimer from the core. Actually, the game timer is a frame-speed killer. It takes more time to process than a normal compare of the core highrestimer.)

For multiple cars, couldn't you just move the camera to each cars position, render, calculate, and cycle through the next? (With 60 FPS, you could check even-cars one round, and odd cars the next... trusting that your last scan value was good for 1/30th a frame. If looking ahead, and setting a destination... you could do one car per frame.)

[Petr Schreiber]

Rendering the image all the time and for every sensor would mean a lot of performance eaten by that when you have up to 7 vehicles (my guess as max vehicles on the track) to calculate.

Why don't you look into ray cast collision?


Hi Mike,

of course I am looking into it :)
I just wanted to do dummy test before work to see how it will be used and so on.
Jason asked me about how this posted script works ( at least that is how I understood it ), so I explained it.

Jason,



Actually, the game timer is a frame-speed killer

I am not sure what do you reference as game timer. If you mean TBGL_GetFrameRate, then please know it basically does exactly the same ( even uses same API ) as HiResTimer on most PCs.
It just limits the value to never return zero, to avoid division by zero. It also detects architecture it runs on during module load, so if performance counters are not present, it uses getTickCount safely.

The speed impact it does is microscopic and does not degrade game performance in serious way.

It cannot forcast rendering time for first frame, if you like, move the TBGL_GetFrameRate after render, and initialize FPS variable with your estimation to be used for first frame.

I will continue work on math approach on rays ( and collision generally ) in next weeks.


Thanks,
Petr

[ISAWHIM]

When I said it was a frame-speed killer... I was talking about the impact of using the value it returns, to calculate the XZ position. Not the FPS... The result of calculated speed, (distance traveled in a second), from low return values.

At 200 FPS, you are moving 1/200th, and that allows for good formula math.

When it falls to 60 FPS, you are moving 1/60th, and jumping through objects and wall detection can look spastic.

When it goes to 10 FPS, you are moving 1/10th, and if 1/10th is 3x your body-size/sensor-length, you fly through most objects.

This is why I set the gameTimer value to be >2 (That is 1/2 a second. or 2 FPS), But I will have to change that to a higher value, once actual collision detection begins. At 20 meters per second (72KPH, or 44.73MPH), 1/2 a second or one gameFrame is 10 meters. Walls, and other players would have to be 20 meters thick, to detect collision, and sensors would have to be equally as long.

However, at 60FPS, 20 meters per second is only 0.33 meters of motion per game-frame. We can be 1/3 of a meter thin, and be borderline of evading collision detection. (EG, your sensor only has to look ahead about a foot, or your probe only has to be a foot long to see a wall fast enough, and make adjustments.)

I am just trying to bring this into view, before we wonder why our code works with one ship, at 600+ fps, but fails when the FPS begins to drop.

For your sensor... if you just used it to pick a valid spot to move to... (Like a portable track), but selecting a spot in the distance... You would not have to check every frame, only when you reach your set destination, or come close to it.

EG, (Based on how I think it works, or is possible of working.) This would be an alternative to scanning unlimited distance, and seeing "Space", which might not register. Also, as opposed to looking only a fixed distance. (Your velocity should be a factor in how far you look. If you are going 2 MPH, no point in looking a mile ahead, same if you are going 40MPH, no point in only looking one meter ahead.)

Camera on nose... Clipped distance view of about 100 meters... Set a sprite on your nose, and push it away until it is gone from view... At that point... you rotate the camera Left and Right, until it comes back into view.

The more time there is left, the more you keep pushing it back, until you reach the 100 meter limit.

That will let you avoid other players on the same Y axis, and allows you to select a location towards an inner-turn, or an outer turn. (Provided that you looked ahead to know the turn direction. Actually, the track builder can calculate that for us.)

Not sure how well that will work on an incline... but it can completely add a thinking element to the AI for avoiding collision, prior to it happening. (If something is in front of your destination, you can select a position to the left or right of it.)

[ISAWHIM]

Sorry to dredge-up an old post... but until the intersect code is finished, I am playing with this camera model to get the required values needed. (Only using it for floor and gravity at the moment. I don't trust that drunk mouse. LOL.)

Petr, I noticed in the demo, that there is code for fonts... But I don't see any text in the demo. Is this a bug or is that part of the code incomplete or turned-off somewhere? (I don't have a clue how to use the fonts here.)

Just a curiosity, about the fonts... Do you have separate code so we can use fonts inside the 3D area, and another set of fonts or a layer for the 2D (Screen) area? I am envisioning 3D words flying around the screen like sprites, but also envisioning GUI notices being unbound to 3D, positioned on the screen directly. (Thinking back to your FOV font issue.)

[Petr Schreiber]

Hi,

with latest ThinBasic, the script from first post of this thread shows green text in upper left corner of the screen, as seen on screenshot.

TBGL provides 2 approaches for fonts, have a look in TBGL help file on Functions list/Fonts and text plotting.

I would like to ask anybody to redownload script from first post of this thread and tell me if there is any problem with displaying text.


Thanks,
Petr

[Petr Schreiber]

Continuation of this topic, related to ATi XPRESS issues can be found here:
http://community.thinbasic.com/index.php?topic=2268.0

Petr