Collisions :(
Blitz3D Forums/Blitz3D Beginners Area/Collisions :(
| ||
| i got a problem and am wondering if someone can help me out. I've written a bunch in blitz2d and recently upgraded to b3d. I tried reading the tuturoial on collision, i copied the code and it didnt even run (sigh). i searched the achives and cant find what im looking for i've of a castle and a cube(player) and right now the cube can run right thru the walls. i have no idea what im doing. can somone help thanks DroolBucket |
| ||
| I have been doing 2d for quite a while, and just recently started trying my hand at 3d. What I've learned (even as a recent 3d newbie) is that when you move around a scene (ie a castle's interior, or exterior, or whatever), you move the camera. You mentioned moving a cube. Naw, use a camera as your move point. You can assign a radius to it, meaning anything closer to the camera point than the radius will collide. Collisions are between an ellipsoid (the camera) and something else. In the Collisions command, you set up what will collide with what, and what the reaction will be (I STRONGLY suggest slide, but, hey, experiment.). Each entity needs to be assigned a entitytype. Typically, the camera is assigned a digit one (1). In my current project, I made the camera 1, and everything else a 2. You actually have a choice of 1-999 different entity types, so you aren't limited to 1 and 2 only. BUT! Collision checking will only activate for the types you specifically setup in a Collisions statement. Got it? Updateworld is the command that actually checks for collisions between the two (or more) types you specified, or in my example/case, type 1 entities (camera) and type 2 entities (everything else that you want to collide with). If you don't assign an entitytype to an object/entity you create, it will not be checked for a collision, and you will go through other objects with it like a ghost through a wall (appropriate for a castle, eh?) Here's some code examples: ;camera stuff pcam=CreatePivot() camera=CreateCamera(pcam) EntityRadius pcam,1.45 ;a 2.90 dia. EntityType pcam,1 ;create a wall section entity=CreateCube() NameEntity entity,"Wall" ;give it a name EntityType entity,2 ;camera is 1, everything else is type 2 (for now) ;Camera collision with objects, slide from pt. of collision Collisions 1,2,2,2 ;updateworld is where collisions are checked. UpdateWorld Hope this helps. |
| ||
| DroolBucket, check out my programming tutorial website for my FPS (first person shooter) example. It uses collisions. And while you're there, check out everything else... |
| ||
| Nice website. I'm working on a 1st person dungeon crawler game, and having a sword out front or a crossbow/bow, are things I've thought about implementing. Your FPS example should help me get that developed. Thanks. |
| ||
| Another thing (one that i am quite upset about if its true) as far as i know the only type of collisions that can be detected is between a sphere and somthing else, isnt their a way to detect between a polygon and another polygon just wondering droolbucket |
| ||
| Hi all, There is a command "MeshesIntersect" to detect collision between polygon and another polygon. (But it may be slow) Another option: try ODE/Tokamak/Newton dynamic physics Sammy :) |
| ||
| Sir gak u are quite the programmer and i am quite the idoit, when u said to use the camera for collisions i thought that was dumb. however i found out my collisions are working but i was not able to tell because my cube stopped and the camera kept going, you were right thanks DroolBucket |
| ||
| This forum has helped me out a lot. So, I'm glad I am able to return the favor by helping someone else. |
| ||
| Couldn't you just make the camera a child of the cube....then it would maintain the same distance/angle from the cube/player all the time? Also, with the meshesintersect command, if you're going to use that extensively, you should consider having a very very low-poly mesh as a child, and use that to test your collisions with. |
| ||
| Unless you need to see what is seeing the scene, just use a camera. In case that comment didn't make sense, it would be like seeing, from inside a jet fighter, the world outside, but if you wanted to see the jet itself, then of course you need the jet fighter object itself to be seen. Likewise, unless you want to see the see-r (ie a fighter, etc, who is moving around inside the castle, and through whose eyes you are seeing the castle scene), just use a camera and put an EntityRadius on it, for purposes of collision interaction with the world around it. The cube and camera in a parent-child relationship is fine, if you need to see the cube itself; if not, go with just a camera. It all depends on what you are working to achieve. |
| ||
| Unless you need to see what is seeing the scene, just use a camera...The cube and camera in a parent-child relationship is fine, if you need to see the cube itself; if not, go with just a camera. You (generic "you", that is) are going to want to start making the camera a child of a pivot/mesh once you implement mouselook and the direction the camera points is no longer the direction you want to travel. |
| ||
| By "mouselook", am I correct in assuming you mean the command CameraPick? In the 1st person shooter dungeon crawler game I'm working on, I start with a pivot, and make the camera a child of the pivot. All my movement is made on the pivot, and the camera comes along for the ride. I use CameraPick with a cursor arrow (drawimage cursor,Mousex(),Mousy()), while I move around using the arrow keys (up, down, left, right). At any given point, I hold the left mouse button down to use camerapick, and the objects I hit with the cursor arrow image are identified by CameraPick. This way, I can run the mouse cursor arrow anywhere on the screen to identify stuff, while not changing the direction I am going. This way, the camera does not move around to follow whatever objects I am wanting to identify. |
| ||
| FPS games used to be keyboard controlled - mouselook simply refers to being able to look around with the mouse, which I think (don't quote me) Quake introduced. A mouselook system would typically be used in conjunction with the camerapick command in just the way you describe, but they're separate things. |
| ||
| So, you mean, move the mouse, and the camera folows the mouse pointer, allowing you to move the camera in 3d, as in, left, right, up, down and (with mousewheel) zoom forward/backward? I guess the right mouse button to could be used to switch back and forth between actual camera/player movement, and mouselook functions (where you actually don't move, only just look). Or Hold down the SHIFT (or other alternative key, such as CTRL or ALT) key to activate mouselook. |
| ||
| So, you mean, move the mouse, and the camera folows the mouse pointer, allowing you to move the camera in 3d, as in, left, right, up, down and (with mousewheel) zoom forward/backward? No, forward and backwards motion for pitch. But the point is that the player object doesn't necessarily follow the camera, which is why it has to be a separate pivot/mesh and the system is called mouselook (not mousemove or mousepoint). Just pick pretty much any FPS you like since Quake... that's mouselook, with x-axis motion affecting the player's yaw (and hence that of the camera also) but y-axis motion not affecting the player's pitch but rather only that of the camera. EDIT: Here's a quick example so we're on the same page: EDIT: Now added collisions - seemed appropriate given the OP! |
   |