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!

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!

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)

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)

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,

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?

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.

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

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

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

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 :/Oh and currently the only movement being collision checked is the downward movement using the 'shift' key

EDITAlso, 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 :pEDIT #2Revised code to check in ALL directions, not just the downwards

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?

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:

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...

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

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 :p

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

Much appreciated sir, we're starting to hit deadlines on this project and not entirely sure our best way to go about this part.

We're hoping to finish up the render to be efficient enough that you can blockpick (which I'm going to throw my hand at implementing tonight) and delete /add blocks in

Thanks, look forward to seeing what you mean! ----------EDIT: also just figured I'd back up why we have such bad computers, it's a high school, though next week I'll be outta there after I finish at least a basic version of this game. Actually plan on continuing it after ----------EDIT #2: Attempted our hand at implementing Threading.. God that did not end well..If you want to see our miserable attempt you can just uncomment a couple things but to be honest most of it was so bad we just didn't even save it commentedI'm really curious to see how you went about doing the "toRemove" and "toAdd" Queue's and such!

Okay so I've now tried my attempt at threading again, this time with a little more success.

I got so far as to realize that I'm having issues with doing the rebuilding of the chunks inside the subthread. The issue however is that if I queue the loading to be in the main thread, that defeats the purpose of even having the subthread as all of that loading will just end of being done in the main thread anyway...

The outside loading is being done insdie of the BackgroundProcessing class for reference, the rest of the chunkupdating is being done in the ChunkManager class.

Anyone with any ideas in regards to doing the asynchronous chunk loading or if they have a way of doing chunkloading in a way that it won't slow down my game (in another thread is the only way I can think of) please post! Help would be much appreciated as I only have a couple days left!

then i recently switched to only local face render checks, and ended up speeding up my calculations of faces to render by around 23ms. This is the face calcualation, like i said before its messy and i dont give a hoot about it being messy atm. Too busy with physics summer class to spend too much time making it look neat when i just want it working atm.

then this is for drawing, note that it only runs the draw method whence the chunk has been built by the above method. Im using display lists with va's inside, might switch to vao's with attrib pointers though.

All in all loads up new chunks near instantly(37ms max from finding chunk doesnt exist to having it rendered), i cant move the camera fast enough to get past the loading chunks anymore. Longest part in my code atm is generating the values in the chunk. I really need to clean this code up badly the more i look at it. but i'm super busy, so if anyone is going to come on here and just be like face to the desk to the max then just please don't waste your time! -.-

Main thing here thats good is the simplex algo i'm using for the different values but it takes roughly 78ms to generate a chunk terrain caves and all the other goodies, roughly 20,000 cuboids.

After talking with a couple people in the tech industry, I've come across the realization that it's never good to have multiple classes accessing the OpenGL stream. So in short, the rendering must be done in the main class or only in one class.

At first I attempted to use the Executor Service style, but that didn't turn out well. All I ended up doing there was implementing a way for chunks to save ASYNC when you make block changes (previously it didn't save your changes to the world).

So, now realizing I very likely won't be able to offset my calculations needed for rendering, it brings up a new question I'm unable to answer and was hoping someone might have an idea: How could I render ONLY the blocks I am able to see? Or just render enough blocks, not excess. (Currently I'm rendering all blocks next to air within the 9 chunk's square around me. (my current chunk and the 8 surrounding chunks, which is about 4000 blocks rendered per chunk in a 16x16x64 world (generated using a SimplexNoise))

The second question then;And what would be a good method of implementing the loading of the new chunks as I move into another chunk (assuming it always has the 9 square chunks in memory)?

Sorry if I'm too vague, but this is really starting to drive me nuts, everything I try is just making the game run even slower!

After talking with a couple people in the tech industry, I've come across the realization that it's never good to have multiple classes accessing the OpenGL stream. So in short, the rendering must be done in the main class or only in one class.

Accessing OpenGL from multiple threads is possible but there is no guarantee that it works reliably everywhere. The rendering can be done in multiple classes as long as they don't try to make the OpenGL context current on several threads. Call all your rendering methods directly or indirectly in GameLoop.render() or Screen.worldRender() and it will work.

At first I attempted to use the Executor Service style, but that didn't turn out well. All I ended up doing there was implementing a way for chunks to save ASYNC when you make block changes (previously it didn't save your changes to the world).

So, now realizing I very likely won't be able to offset my calculations needed for rendering, it brings up a new question I'm unable to answer and was hoping someone might have an idea: How could I render ONLY the blocks I am able to see? Or just render enough blocks, not excess. (Currently I'm rendering all blocks next to air within the 9 chunk's square around me. (my current chunk and the 8 surrounding chunks, which is about 4000 blocks rendered per chunk in a 16x16x64 world (generated using a SimplexNoise))

The second question then;And what would be a good method of implementing the loading of the new chunks as I move into another chunk (assuming it always has the 9 square chunks in memory)?

Sorry if I'm too vague, but this is really starting to drive me nuts, everything I try is just making the game run even slower!

Are you sure that the bottlenecks are those computations? Do you plan to use view frustum culling in order to render only the blocks you have a chance to see?

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