Voxel-Based Engine Using Game

WIP games, tools & toy projects Cube World Projects
#1

[s]So, basically we’re trying to make this very basic Voxel-based engine to use for a school project. We seem to be having great difficulty getting our physics engine to interact with the world that we have it generating… Could anyone enlighten us at all?

The main issue is getting the ‘playerBody’ to go inside the ‘air’ gaps, like the code to use seems full proof…

That’s about all, if you guys need more info I don’t know what to post but I’ll gladly post it up![/s]

And yes, don’t worry, we know there’s code from other people that’s been incorporated. If anyone has any issue at all feel free to give us your name and we’ll mention you, but this isn’t for profit, purely for educational purposes!

Continue down |/

#2

I can’t find any code where you are checking if on ground or not.

#3

This shouldn’t be any different compared to basic AABB collision detection since your voxels are essentially AABBs.

#4

The code is inside the PhysicsWorld class technically. We create a world of blocks and every time one is committed to the world that’s actually going to be rendered, if it’s not air, the block is made according to its XYZ coordinates (this is in the Chunk class)

#5

I understood that, I can’t find (Maybe because I’ve never used bulletphysics before) the bit of code that is something a long the lines of,

  • move player
  • collision sideways/can move to new position
  • collision below/should be affected by gravity?
#6

I’m not 100% sure as right now loading Eclipse, but I’m almost positive it’s under the Camera class that the checking is done for movement

Okay ignore that. After rereading our code I realized our basic implementation of collisions had been removed and put in with a version of Jbullet collision, but ours is for sure broken. Ours actually says it’s colliding with everything, and so we have it being looped through to check manually if it collided with the player. (which doesn’t work to be completely honest)

So new question, does anyone have any idea of how we could fix our collision detection to work properly?

#7

Wow. This is really weird!

The library you’re using, GLUtils, is the library I created. Much of the code is based off of my voxel engine series (link in my signature). That’s just… Wow that’s so weird that you’re using my tutorials and code! I’m pancakesimone on YouTube!

I honestly would not recommend my tutorials as they weren’t coded very well. I also am not planning on putting out any more tutorials.

#8

Ahahah that’s actually really weird! Man it would have been awesome if you’d continued that series, but I understand. Do you happen to have any ideas on how we could remake our collision detection? I’m still trying to wrap my head around the idea of AABB and stuff :-\

#9

Well what are you having issues with?

Easiest way I can think of:

Keep a list of some sort of bounding boxes in the world class. AABBs are quite easy to implement so I won’t go in to detail if you don’t need me to.

Every entity will also have a bounding box. Entity to entity collision detection is fairly easy, just loop through the lost of entities and see if the bounding boxes collide.

Block to entity collision detection is a little more involved. You will need to grab the bounding boxes of the blocks around the entity and then test for collision.

I would personally just do a simple check every tick in the entity class to see if there is a block below it. If there is, the entity is obviously on the ground and you will not need to perform collision responses in the downward z direction. All other axis must be tested and collision responses must be handled accordingly.

Collision response should be easy for blocks, just repel the player backwards in the direction that the player is colliding. The same could work for blocks. You could save the last location the entity was and then revert back to it after the collision occurred, but you will want to add some “padding” push back so that the collision will not happen again within a small period of time because of course this will cause a rapid “jerking” movement along the collision vector.

I’m sure I could post some solid math equations later! Just give me a few hours, today is the last day of school and I’m going to hang out with friends to celebrate :slight_smile:

#10

Ahahah okay thanks so much for the info! I’ll see what I can do and definitely take a look at the math if you post some :stuck_out_tongue:

Enjoy!

#11

Okay, I’ve now added AABB-style collision with spheres for the player, just actually implementing it now. How big of a deal is it that I made the Y-axis my height? Just you said your Z-axis was so just wondering :stuck_out_tongue:

#12

Ah sorry yes, its the y axis not the z. Got that confused.

#13

[s]Okay so I’ve added the AABB style collision with a sphere for the player, however my grid for the AABB seems to be different than that of the blocks… meaning that for some reason with a chunksize of 8 (8x8x8), the only blocks it recognizes are from 3 to -3 in all axis… I’m so confused :confused:
Oh and currently the only movement being collision checked is the downward movement using the ‘shift’ key

EDIT
Also, would an array of true/false be more efficient for block collisions than AABB? So not really a collision system, but just when you want to move to the block in front of you, you check the coordinates of that block for being true/false instead. Just wondering since mine seems to be broken :stuck_out_tongue:
EDIT #2
Revised code to check in ALL directions, not just the downwards[/s]

Found a silly little issue in the code… realized the AABB guide I followed didn’t do it properly for if the object was created not from the origin. Fixed and now the code works. Not seamless, now I need to add momentum and stuff so gravity works properly.

Now, my question is which would be better:
two playersphere’s with camera set on the center of the top sphere, or an oval with the camera offset upwards? (I want a little less than two blocks total height.
OR is there a better alternative?

#14

Okay whole new issue, I know you said I shouldn’t use your GLUtils class, but unfortunately I’m not good enough at knowing my own code to completely remove it altogether.
How could I go about creating a main menu and a ‘pause game’ state?
Looking at your code, the original Main() statement is:

	public Main(){
		gameLoop = new GameLoop();
		gameLoop.setScreen(this);
		gameLoop.start(30);
		
	}

However, I’m unsure of how I would be able to implement the changing of screens as i can’t figure out what your screen is called (I’m not sure what ‘this’ is referring to! X_X)

Might be a really obvious answer or I may be going about solving this wrong, but your help will be much appreciated X_X

*I removed your GLUtils.jar package and instead added your source code from your repo in order to be able to read the source properly and make minor tweaks

EDIT

Seriously noone uses different screens for their games/menus? :confused:

#15

Okay whole new set of issues.
What would the best way of altering our rendering system be?
We seem to have hit a brick wall in regards to rendering only blocks in sight(not blocks that are behind other blocks).
The current way we’re doing it is checking for all blocks see if they’re next to air, and rendering only those, which is good for small maps.
As soon as we have the larger maps with the randomly generated terrain, this is too resource consuming and is killing the rendering from 30fps to 2-10 fps…

#16

30FPS :open_mouth: why so low are you running on a vintage computer?

And why is it dropping while loading? I just finished my async chunk loading system a few minutes ago and im not losing a single frame at all untill i reach like 60+ chunks loaded then its just because its hard on my mac with INTEL HD 3000

#17

Ahahaha, it basically is! Max I can reliably do on the computer is 30fps, and the computer itself has about 512MB ram with a Intel graphics chipset from the late '90s (reallllyyy old cpu dual core running at ~2 GHz)
These are the school computers as this is for a school project :stuck_out_tongue:

#18

Ahhh makes sense, but even at my school (Sac State University) we have at least intel 4000’s and around 4gb dual core i believe. Have you tried calculating everything async before rendering? would probably boost the fps while loading the chunks

#19

To be completely honest with you, I’m not too sure what that even means lol

#20

Calculating the Mesh A.K.A. the sides to render in a thread seperate from the thread where you update the display and tell it what to render.

You can either use futures with a executor service or just a seperate thread.

(Note: I do not mean multithreaded rendering.)

Example(just a clip of what it would look like.):


SubThread Calculate
MainThread Render
SubThread Calculate
SubThread Calculate
SubThread Calculate
MainThread Render
SubThread Calculate
MainThread Render
MainThread Render
MainThread Render
SubThread Calculate
SubThread Calculate
SubThread Calculate
MainThread Render
MainThread Render
SubThread Calculate
MainThread Render
SubThread Calculate
MainThread Render
SubThread Calculate
SubThread Calculate

Sub thread just checks where you are and finds the chunks it needs to calculate, once calculated it tells the main thread its ready to render those chunks. main thread then renders them.