Hello everyone. I am new to 3D development and relatively new to java game development in general. I had some general questions to help me get my current project moving forward.
Aim of my project: A small multiplayer (like 2~4 people) block based action-rpg engine.
Problem:
Being new to 3D development I am hitting some snags on memory management that I’m not quite familiar with.
I started with the basic HelloNode example and expanded on it.
I created a node called level
Level calls on my mapdata method
This mapdata method pulls a large 3D array (100x100x100) from a text file.
It then creates a 3d array of Boxes using generic color materials based on the numbers from the data array 0=nothing (open air) 1=(dirt) 2=(grass) etc…
It attaches the 3d array of boxes to the level node and returns it.
I then added a directional light
I then attached the level to the rootNode.
I clicked was excited so I tapped to run the program to only have it load for 15 minutes with a solid black screen followed by java out of memory error, followed by crashing, followed by defeat.
I feel that I am missing a critical point in 3d development or the methods i’m using to store and build the data are not efficient for this type of work? :-\
I tried a smaller approach which was 25, 5, 25 and tried adding collision as in the hellocollision tutorial and similarly ran into horrible frames per second when loading the map and running into a corner.
I guess long story short I was wondering if anyone else had pointers for improving the loading/rendering of data in a block based environment for someone who is just entering 3d game development or any pointers in general?
@mortalglitch said:
Hello everyone. I am new to 3D development and relatively new to java game development in general. I had some general questions to help me get my current project moving forward.
Aim of my project: A small multiplayer (like 2~4 people) block based action-rpg engine.
You do realize that you’ve picked probably the absolute hardest place to start, right? Block worlds, despite their simple look, are actually the hardest kind of game to write… and multiplayer makes it 100x harder. 1000x harder if you’ve never done networking before.
I mention this because many people don’t realize that it’s the hardest way. “The graphics look simple so it must be simple.” Except you have to learn how to construct custom meshes, or manage batching, and any of a hundred things that a regular plain old “load some assets and run” game wouldn’t have to deal with.
Translating your original question metaphorically: “I’m new to walking and relatively new to crawling but I want to swim… in the ocean… at sub-zero temperatures… during a storm…”
@pspeed
Yeah after I posted that I realized it sounded a little absurd for someone starting out to take on. I picked this particular genre as it covers many aspects of game design, the possibilities with this type of design are high, and I enjoy what projects I have seen come out of it so far. I don’t mind it being hard to learn.
Truth is I have worked quite extensively with 2d projects in the past and made a few minor games in the past using C++ and the Allegro library. My favorite self project was a little Zelda looking pvp arena I had set up to be two-player joystick compatible with a PC.
Normally the way I’ve worked in the past is to pick one aspect of a engine, break it down into a separate project then work on it until I get it working, understand it, figure out how to improve upon it, and finally move on to learning the next technique I will need to reach my goal. The multi-player and for that matter the action and rpg portions of the gameplay are far off down the road and I shouldn’t have mentioned these as I know i’m not ready to approach these yet. I have currently picked the terrain/level aspects of the game as I feel they are critical components and are the most foreign to me.
My question as short sighted as it may look was mainly this:
When working with voxel/block based terrain is a box array alright for storing the data after loading a map file? If so, what techniques do I need to look into to control the amount of data being rendered at any given time? If not, what other techniques would someone recommend I look into for data storage/control when working with 3d? I see you mentioned a managed batching I’m not quite familiar with this but will look into it.
in response to the crawling to swimming comment: Check out ISR self water rescue course ( method of teaching children as young as 6 months to 7 months swim and stay afloat) on Youtube XD - edited for typo
@mortalglitch said:
@pspeed
Yeah after I posted that I realized it sounded a little absurd for someone starting out to take on. I picked this particular genre as it covers many aspects of game design, the possibilities with this type of design are high, and I enjoy what projects I have seen come out of it so far. I don't mind it being hard to learn.
Truth is I have worked quite extensively with 2d projects in the past and made a few minor games in the past using C++ and the Allegro library. My favorite self project was a little Zelda looking pvp arena I had set up to be two-player joystick compatible with a PC.
Normally the way I’ve worked in the past is to pick one aspect of a engine, break it down into a separate project then work on it until I get it working, understand it, figure out how to improve upon it, and finally move on to learning the next technique I will need to reach my goal. The multi-player and for that matter the action and rpg portions of the gameplay are far off down the road and I shouldn’t have mentioned these as I know i’m not ready to approach these yet. I have currently picked the terrain/level aspects of the game as I feel they are critical components and are the most foreign to me.
My question as short sighted as it may look was mainly this:
When working with voxel/block based terrain is a box array alright for storing the data after loading a map file? If so, what techniques do I need to look into to control the amount of data being rendered at any given time? If not, what other techniques would someone recommend I look into for data storage/control when working with 3d? I see you mentioned a managed batching I’m not quite familiar with this but will look into it.
in response to the crawling to swimming comment: Check out ISR self water rescue course ( method of teaching children as young as 6 months to 7 months swim and stay afloat) on Youtube XD - edited for typo
…which is the equivalent of writing asteroids, reversing the metaphor.
You will never get anywhere with boxes. Block worlds are not made of blocks. This is such a common statement that I think the forum still has it as tooltip text if you hover over the phrase “block world” (at least it used to). You need to render only the visible quads or your world size will be limited to only 20 meters or so.
P.S.: And those quads will need to be grouped together into one big mesh. Not a million separate objects.
P.P.S.: There have been already publicly posted 3 or 4 block world engines with source code now. You could look at them instead of trying to relearn everything from scratch.
@pspeed said:
...which is the equivalent of writing asteroids, reversing the metaphor.
You will never get anywhere with boxes. Block worlds are not made of blocks. This is such a common statement that I think the forum still has it as tooltip text if you hover over the phrase “block world” (at least it used to). You need to render only the visible quads or your world size will be limited to only 20 meters or so.
Thank you very much @pspeed this was the type of information I was looking for. I had read over several article that talk about brief concepts behind this type of engine each mentioned putting blocks into world plus visibility controls for each individual block. I was always imagining each block as a true cube but now that you have mentioned this it makes a lot more sense as you only need to render the sides you can see otherwise you would just be wasting resources. Interesting indeed.
You may be tired of questions like this but you have really helped me this evening and probably saved from quite a bit of beating my head against a wall and I thank you for that.
I have one more additional question about your P.S. statement
And those quads will need to be grouped together into one big mesh. Not a million separate objects.
If they are grouped as one big mesh forming a structure such as a wall and you were to knock a section out of said wall would you render this mesh again drawing the sides that were underneath the block you removed? I'm uncertain if I phrased this question properly forgive me if I didn't.
Yes, if you remove a block then you have to regenerate a mesh. Removing a block will reveal as many as 5 new quads.
…this is one of the reasons this type of game is more complicated, because you have to start right away with efficiently generating and regenerating meshes all the time… and doing so in a memory efficient way. (I know a few things in this area: http://mythruna.com/ :))
You have given me a lot to think about since you mentioned grouping the “blocks” I have started playing around with some of the built in grouping functions like GeometryBatchFactory.optimize - This function alone solved my collision problem which was substantially dropping my framerates. It looks like I may need another method after reading it’s description though.
I’ve also been reading over some of the culling functions I found in Google but I think my mind is to tired at the moment to actually process what I saw in some of them at the moment. I feel like i’m in college all over again 8-O
When you had first responded to my post I thought your name looked familiar from some of the digging I had done the past couple of days. It didn’t click until your second posting on this thread that you were behind Mythruna after I checked the profile. Much respect there definitely. Thank you for taking the time to assist me.
Marking thread as resolved: I was taking the wrong approach at rendering the blocks in my voxel/block attempt. Instead of rendering each “block” individually they need to be broken down and rendered in groups and they need to be rendered as necessary to prevent overloading memory.