Do you check which block you are on before doing your AABB, so you know if block is active or not?

You will need to do a ray cast to do the picking, I'm going to try that tomorrow providing I get this collision working!

You don't need to test if the block is active. The only thing you need to test for is if the player vector position is within the block vector. If it is, handle collision appropriately. I don't understand why you keep bringing up your

That seems a little sketchy... you really shouldn't really on that way of collision unless you're writing anything other than a basic 2D game. You really should just AABBs and implement sliding movement.

@opiop65 - Surely you need to test if the block is active else you would collide with every block in the chunk?!?!? My chunks are made up of 16^3 blocks, of course, some of them are not active, so how do I check the blocks in the chunk?!

So, why is this so hard again? Just get the blocks around you. <.< Its not that hard if you know how big the cubes are. Its like a grid. Treat the chunk as a grid, and find where you are in the grid. Then test collisions around it.

The above code is just an example of a block that is at position x:7, y:1 and z:7, so, when player is at that position, collision occurs, and it does, and is a whole lot better than just doing collision with, is player on block N.

Of course, the example above needs to get the blocks position around the player - top, bottom, front, back, left, right - then check for collision with these.

When I get a block - I NEED to see if it is active or not, otherwise what is the point in testing for a collision with an empty block?!

Will need a slide vector when collision for more realism - this is in fact an impulse force, so guess it could be:

So, why is this so hard again? Just get the blocks around you. <.< Its not that hard if you know how big the cubes are. Its like a grid. Treat the chunk as a grid, and find where you are in the grid. Then test collisions around it.

Collision detection is easy.Convincing them that they don't need AABBs to collide with the world is hard.

Some forms of collision detection is easy, some not so. I'm finding AABB the best solution for what I am trying to do having tried another method which wasn't too successful.

What I'm struggling with is collision response, what to do when collision occurs. Of course, we need to determine if the collision was in front, behind, above, below, left or right of the player first of all.

When I land on top of a block, I then cannot move forward as my code thinks there is a collision in front, even though it is with the ground... :-(

@Vermeer - I believe you need to add the height on when checking collision so we don't get a collision with block below. I do the ground test in a separate collision check, from there I get the height of the ground we are on and now use that when moving.

As for not moving player when testing, you mean store the cameras position in a player vector and check this before allowing movement? Makes sense.

I think getting the players normal (direction vector) so we always know which way the player is facing would be beneficial to this form of collision detection, thus, we would know if we collided from front of player, behind or left, right - below shows P as player and arrow showing players normal vector.

/|\ P | | P \|/

So if a collision occurs, we could check the players normal vector...would this work?

I guess there are lots of ways to approach this, but I think the important thing that you know how the solution works in your game so that you can fix issues with it.

Yes - I don't apply transformations directly to the player, but a dummy object. If There is no collision, I then move the player.

I also use the players vector too yes, so I will know which block to test. I think I didn't explain below that once you test the height, you do use that height information when testing the forward movement.

These are my methods to send a ray from the camera, it may be very in-efficiant, but it works to test it.You will notice I have lots of small methods to add vectors and suchlike.

Basically I use trig to calculate where the camera is pointing, then test along the ray at 0.1f intervals, and check if It hits a solid block.Someone may suggest a better way, and it can certainly be optimised a lot. Trig functions are expensive, Once the angle is know you canmake use of the same angle, without recalculating. But this may help you get it working, so you can develop it.

And the next Question:How big is the memory footprint with 256,1024,2048,4096 and 8192 chunks?My experimental engine can handle ~16000 16³ Chunks without crashing and a stable framerate of 50 fps.Im just wondering what your engine is capable of.

I've got an issue in mine now, I'm only rendering chunks when at a certain view distance, this seems to work, but problem is, CPU memory usage goes up on each chunk that gets rendered?!I am using Display lists, could this be the issue, and this is on my Macbook Pro which has a intel 3000 HD graphics card...

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