Java-Gaming.org    
Featured games (81)
games approved by the League of Dukes
Games in Showcase (497)
Games in Android Showcase (114)
games submitted by our members
Games in WIP (563)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  Collision Avoidance  (Read 2223 times)
0 Members and 1 Guest are viewing this topic.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Posted 2002-10-21 16:46:20 »

I have implemented the j3d.org collision avoidance routines in my app.  For some reason it is only pickiing up clossest objects and checking for collisions when I cross the cneter point (0,0,0) of my universe.  It then detects and somtimes shows possible collision iwht the avatar.  Any thoughts?

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #1 - Posted 2002-10-23 15:45:50 »

Further data...

My 'game' will consist of only boxes(QuadArray geom) the players box is followed by a camera.  

I have placed another cube out in space and use my own keyboard navigation to move the player around.  My collision detection detects my players cube constantly and never detects the other cube, even when passing thru it.

Any ideas? I want simple Box to Box avoidance so players can drive thru (or partially into) walls.   Driving thru each other is fine.

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #2 - Posted 2002-12-06 12:34:01 »

I don't know if you have solved this problem or not but I'll respond.

What type of picker are you using?  A Ray might be the best thing to use here.


Ubuntu
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #3 - Posted 2002-12-06 15:20:40 »

The code uses a ray and a segment. The ray is used for the downwards pick to do the terrain following. The segment is used to do the "forwards" pick to know if you are about to run into something. This limits what is picked to only the closest object(s) so if the object is outside where you are now then it won't find it. From there, the code will run through all the picked objects and do a polygon by polygon check for the closest one to know the exact details of the "real" closest object (j3d sorts the pick by bounding box centre, not the intersecting polygon).

That said, we know there are some bugs in the code that have been causing us great frustrations. I think the problems are related to us not setting the forward picking segment in the right direction - probably an array multiplication bug somewhere. For example, while you are walking "forward" everything works fine, but if you walk "backwards" there are some oddities showing up. I'm expecting to start the debugging on that next week, as it is rather important for one of our current projects.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Conzar

Junior Member




There is nothing common about common sense


« Reply #4 - Posted 2002-12-06 16:45:35 »

Thats what I am doing too - got an example from j3d.org of the terrain following.  I am wondering if you really need the segment picker at all.  Because you are looking ahead 1 frame, your downward Ray picker should be able to detect a wall that you are about to run into (or anything for that matter).  

Things might  be getting messed up when doing both the forward detection and the downward detection.  

Well, thats just a thought.  You might have a really good reason for doing the forward detection as well.  

Ubuntu
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #5 - Posted 2002-12-07 17:05:05 »

You need the two picks to work correctly to do both collision detection and terrain following in the generalised case. There are certain optimisations you can make if you don't have to deal with just generalised geometry (I wrote the code initially for our VRML loader). For example, in a racing car game, you don't need any picking at all because you can run with a 2D height map that you do the lookups into for both terrain following and collision management. Where you have completely arbitrary geometry, that's when you need to do the full picking.  For the gaming situation, you can almost always make some sort of assumption to give you much better performance than the generalised method used in the j3d.org code.

The downwards picking is to know what the avatar position will be in the next frame and allowing you to adjust the height. That will do the first pick to know whether you have make a step or descent (eg walking down hill). If that works out OK, then you need to do the forward pick to know what may be in front of you to run into. For example, if you are moving at a fast rate, the movement may be faster than the width of the wall in front of you. Using just the down pick means that you would not run into anything because the avatar location would be on the other side of the wall. You need the forward pick to work out that the wall is in front of you.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline MickeyB

Senior Member




my game will work, my game will work!


« Reply #6 - Posted 2002-12-07 19:08:14 »

So if my terrain will always be flat and say a "game level" has a pre-determined "map" of rectangluar walls, I could use a look-up map?   How would this be done and would it be faster than picking?

Here is a screenshot of what my game world will/should look like.  THe green cube is the player with the camera behind and up.  The blue cubes are opponent bots, they move around and collisions are irrelevant.  The gray long rectangle is a wall and will always be there on this level.  Right now I am use  a pick segment pointing forwards one frame.  Works pretty well, but if I approache at an angle and the corner of my players cube hits the wall before the pick segment, it enters the wall.  

http://www22.brinkster.com/mbowles/screenshot.htm

MickeyB

Current Project: http://www22.brinkster.com/mbowles/
Offline Orangy Tang

JGO Kernel


Medals: 56
Projects: 11


Monkey for a head


« Reply #7 - Posted 2002-12-07 20:14:46 »

Rays are nice and all for generic tests, but more than a tad costly from what i've experienced. For something as specific as that screenshot, you could probably benifit from some form of grid based lookup or tree structure.

Tile-based is nice and easy (simply change your coords into tile indices and check the tile you're over/about to enter. Very fast, but means that your level geometry is limited in both resolution and variation.

If your terrain objects are static, then its time to wheel out the tried and tested bsp tree  Cool Simplified to a 2d based tree, you can build the tree on level load or precompile it into the level file, then search though it to check if a given point is 'inside' or 'outside'. For best results you'll probably want a sealed level, but thats not really a major problem.

Should be plenty of papers etc. on 2d and 3d bsp's if you want more info. Bsp's have been around much longer than their much publiced use in the original Doom  Smiley

[ TriangularPixels.com - Play Growth Spurt, Rescue Squad and Snowman Village ] [ Rebirth - game resource library ]
Pages: [1]
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

BurntPizza (4 views)
2014-09-21 00:34:41

moogie (4 views)
2014-09-21 00:26:15

UprightPath (22 views)
2014-09-20 20:14:06

BurntPizza (27 views)
2014-09-19 03:14:18

Dwinin (40 views)
2014-09-12 09:08:26

Norakomi (70 views)
2014-09-10 13:57:51

TehJavaDev (96 views)
2014-09-10 06:39:09

Tekkerue (49 views)
2014-09-09 02:24:56

mitcheeb (70 views)
2014-09-08 06:06:29

BurntPizza (52 views)
2014-09-07 01:13:42
List of Learning Resources
by Longor1996
2014-08-16 10:40:00

List of Learning Resources
by SilverTiger
2014-08-05 19:33:27

Resources for WIP games
by CogWheelz
2014-08-01 16:20:17

Resources for WIP games
by CogWheelz
2014-08-01 16:19:50

List of Learning Resources
by SilverTiger
2014-07-31 16:29:50

List of Learning Resources
by SilverTiger
2014-07-31 16:26:06

List of Learning Resources
by SilverTiger
2014-07-31 11:54:12

HotSpot Options
by dleskov
2014-07-08 01:59:08
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!