in "freebasic" ...???.. and i uploaded a new version, hopefully its faster than the previous one, even if there are floating islands now too!
Gruss
Procedural block world project
-
super_castle
- Posts: 289
- Joined: Oct 10, 2006 7:19
Ive uploaded a new build mainly because i need to know that falling blocks works as they should :) So please test!
Ive also made changes to waterflow, and the overall speed of the game should be significantly improved.
http://dm.fwsnet.net/fbcraft.rar
Note that only "sand" type blocks should be falling
I might add other blocks when the need arises. :)
edit: uploaded a new one with better job timing
Ive also made changes to waterflow, and the overall speed of the game should be significantly improved.
http://dm.fwsnet.net/fbcraft.rar
Note that only "sand" type blocks should be falling
I might add other blocks when the need arises. :)
edit: uploaded a new one with better job timing
ok, tried it again but a different way and it worked...leopardpm wrote:I get an checksum error when I try to expand the archive... did it twice... anyway you can try to upload again?
now...
OK, you are getting some pretty impressive framerates with the amount of blocks you are showing! I really need to know your process! Do you use a marching cubes or an octree representation of the data with a version of raycasting to determine visible blocks? Do you cull the unseen blocks at all?
I will look back through the thread and see if you already answered this. Nope, didn't answer this before, at least not in this thread.
I can't get the 'sand' to fall because I can't push a sand block (over an edge), nor does the program allow me to create a sand block in midair (I just played with it a short time so probably its operator error).
Please share, oh Guru of the Cube! Share your wisdom (and your code) with us uninitiated! Your engine is so smooth and crisp! It is really looking good! very impressed... if you couldn't tell already!
ok Guru, er, I mean Gonzo... more questions (it went unanswered in other 'chung cube' thread so I wasn't sure if you saw it):
Why not just translate the 3D Cube array into a single mesh/object and when adding or subtracting a cube, just modify those parts of the mesh while leaving the rest alone instead of recalculating the whole mesh again?
for instance, expanding on my AWESOME grid diagram....
]]].....A.....B....C.....D.....E.....
1 ]----x----x----x----x----x----
2 ]-------------------------------
3 ]-------------------------------
4 ]----x----x----x----x----x----
5 ]-------------------------------
6 ]-------------------------------
7 ]----x----x----x----x----x----
8 ]-------------------------------
9 ]-------------------------------
10]----x----x----x----x----x----
Assuming the Z coord is all the same, we have a flat terrain defined as a grid of cubes (there is a 'z' just cant see it right now...) which is 4 x 3.
Now, the player 'deletes' cube at position 2,2 (whose vertices are B4,C4 & B7,C7) so the program kills the mesh between those vertices, and adds 5 new surfaces (4 vertical, and one 'floor') using additional vertices of B4,C4,B7,C7 but on the Z-1 plane. do the reverse for adding a cube.
Wouldn't this method be lickity-split speedy and provide the renderer with basically one terrain (with many polygons, granted, but it would deal with the backface culling, right?) texture instead of figuring out 1,000s (millions?) of 'cube faces' to cull and deal with?
Since it is one mesh, there would not be the possibility of 'floating' cubes unless defined an entirely separate object for each mass of cubes, but so what? Still would be faster.
So, to sum up, my question is: Do you provide a single mesh to OpenGL to render or pass all the cube objects separately? If passed separately, then you have to provide most of the culling work and unseen cube removal, right? Would initially creating (at startup) and then maintaining a single mesh (as described above) work faster, if you are not already doing it this way? Please share your insights! I am messing around right now with OpenGL meshes and cubes, but I am far from figuring out the answer to these quick questions...
Why not just translate the 3D Cube array into a single mesh/object and when adding or subtracting a cube, just modify those parts of the mesh while leaving the rest alone instead of recalculating the whole mesh again?
for instance, expanding on my AWESOME grid diagram....
]]].....A.....B....C.....D.....E.....
1 ]----x----x----x----x----x----
2 ]-------------------------------
3 ]-------------------------------
4 ]----x----x----x----x----x----
5 ]-------------------------------
6 ]-------------------------------
7 ]----x----x----x----x----x----
8 ]-------------------------------
9 ]-------------------------------
10]----x----x----x----x----x----
Assuming the Z coord is all the same, we have a flat terrain defined as a grid of cubes (there is a 'z' just cant see it right now...) which is 4 x 3.
Now, the player 'deletes' cube at position 2,2 (whose vertices are B4,C4 & B7,C7) so the program kills the mesh between those vertices, and adds 5 new surfaces (4 vertical, and one 'floor') using additional vertices of B4,C4,B7,C7 but on the Z-1 plane. do the reverse for adding a cube.
Wouldn't this method be lickity-split speedy and provide the renderer with basically one terrain (with many polygons, granted, but it would deal with the backface culling, right?) texture instead of figuring out 1,000s (millions?) of 'cube faces' to cull and deal with?
Since it is one mesh, there would not be the possibility of 'floating' cubes unless defined an entirely separate object for each mass of cubes, but so what? Still would be faster.
So, to sum up, my question is: Do you provide a single mesh to OpenGL to render or pass all the cube objects separately? If passed separately, then you have to provide most of the culling work and unseen cube removal, right? Would initially creating (at startup) and then maintaining a single mesh (as described above) work faster, if you are not already doing it this way? Please share your insights! I am messing around right now with OpenGL meshes and cubes, but I am far from figuring out the answer to these quick questions...
yes, that would probably be very fast, but its not appropriate for a block engineleopardpm wrote: Now, the player 'deletes' cube at position 2,2 (whose vertices are B4,C4 & B7,C7) so the program kills the mesh between those vertices, and adds 5 new surfaces (4 vertical, and one 'floor') using additional vertices of B4,C4,B7,C7 but on the Z-1 plane. do the reverse for adding a cube.
Wouldn't this method be lickity-split speedy and provide the renderer with basically one terrain (with many polygons, granted, but it would deal with the backface culling, right?) texture instead of figuring out 1,000s (millions?) of 'cube faces' to cull and deal with?
i do culling and face-optimizations :)
and no, its not one mesh, its all "data per texture"
besides, you will have to do your own culling when you add blocks like "glass" or "water" etc.
Such blocks are see-through
ok, been playing around with OpenGL tonight and I see how it is just very basic, low level routines... mostly the things like culling or hidden surface removal are all left up to the programmer to deal with....
I still don't understand your statement that keeping track of all the exposed faces is not a good technique for a block engine... I will have to probably try it to understand why.
So... do you re-generate all the faces to render for each frame? I mean, iterate through your 3-D array and figure out which cubes/faces need to be thrown at OpenGL? seems like an awful lotta work!
I guess I will have to learn the techniques for culling now... sheesh! I was hoping OpenGL would do at least SOME of it for me! oh well!
Looking forward to your next installment!
I still don't understand your statement that keeping track of all the exposed faces is not a good technique for a block engine... I will have to probably try it to understand why.
So... do you re-generate all the faces to render for each frame? I mean, iterate through your 3-D array and figure out which cubes/faces need to be thrown at OpenGL? seems like an awful lotta work!
I guess I will have to learn the techniques for culling now... sheesh! I was hoping OpenGL would do at least SOME of it for me! oh well!
Looking forward to your next installment!
no, i never said thatleopardpm wrote: So... do you re-generate all the faces to render for each frame? I mean, iterate through your 3-D array and figure out which cubes/faces need to be thrown at OpenGL? seems like an awful lotta work!
think about it, 64^3*16*16*8 = 536870912 blocks
thats how many block places allowed locally (near player) in my engine
536,870,912 blocks
you cant iterate all that, and certainly not each frame
and even then the act of copying that to the gpu will be slow in itself
no, what you do is precompile pieces of the world, like a 3d grid
then display those pieces as long as they are in view
for each change you precompile an entire piece, etc. :)
i call it a sector
hence the number 64^3 (64*64*64 sectors)
as for the falling blocks, i know its not easy, since its a mechanism that isnt supposed to be created by a player
but you can always place a few sand cubes on top of each others
and just remove something under them
or go to the top of a giant mushroom and remove something under:P
then watch as it falls down to the ground.. hehe :)
ok, I appreciate your indepth explanation! Really helps!
when you say 'precompile' a sector - you mean figure out the possible visible faces, generate the mesh(vertices), create an VBO and load it up to the FPU, right? So, if the camera does change view, everything seen will be in the GPU, and if a player modifies terrain, only the sector it is in will be dealt with then re-uploaded to the GPU again, right?
pretty good way of doing it, and you seem to be getting a decent framerate for all the blocks onscreen!
Your falling blocks will be interesting, but as it is, I already like your water generation routine - I always have to fly up to a floating island and put down a water block then fly off and turn around to see the magnificent waterfall created! My ONLY gripe would be to not put down 'water blocks', but rather a 'spring' which outputs a set amount of water blocks which each follow the terrain, falling, and eventually pool up somewhere - so no static water hanging in the sky, actual moving blocks of water (possibly the 'spring' blocks could have a variable set amount of water so they could generate a waterfall for a finite amount of time instead of just a quick shower.... and on the surface, watching a depression 'fill up' with water then overflow would be a pretty awesome sight as well! But, I understand that this would involve alot more processing and programming. If you are interested, the programmer of Dwarf Fortress (which features this 'flowing water' physics) uses a shortcut routine which he explains enough to reproduce it: basically instead of moving each block of water individually, he takes finds the top most (heightwise) block and the 'exit' (lowermost in alot of case) block and just moves the topmost into the next position instead of moving all the blocks inbetween... a refinement of that routine might work well and produce fantastic effects!
when you say 'precompile' a sector - you mean figure out the possible visible faces, generate the mesh(vertices), create an VBO and load it up to the FPU, right? So, if the camera does change view, everything seen will be in the GPU, and if a player modifies terrain, only the sector it is in will be dealt with then re-uploaded to the GPU again, right?
pretty good way of doing it, and you seem to be getting a decent framerate for all the blocks onscreen!
Your falling blocks will be interesting, but as it is, I already like your water generation routine - I always have to fly up to a floating island and put down a water block then fly off and turn around to see the magnificent waterfall created! My ONLY gripe would be to not put down 'water blocks', but rather a 'spring' which outputs a set amount of water blocks which each follow the terrain, falling, and eventually pool up somewhere - so no static water hanging in the sky, actual moving blocks of water (possibly the 'spring' blocks could have a variable set amount of water so they could generate a waterfall for a finite amount of time instead of just a quick shower.... and on the surface, watching a depression 'fill up' with water then overflow would be a pretty awesome sight as well! But, I understand that this would involve alot more processing and programming. If you are interested, the programmer of Dwarf Fortress (which features this 'flowing water' physics) uses a shortcut routine which he explains enough to reproduce it: basically instead of moving each block of water individually, he takes finds the top most (heightwise) block and the 'exit' (lowermost in alot of case) block and just moves the topmost into the next position instead of moving all the blocks inbetween... a refinement of that routine might work well and produce fantastic effects!
the length of the water can be increased, so that it will flow, well, alot furtherleopardpm wrote:ok, I appreciate your indepth explanation! Really helps!
Your falling blocks will be interesting, but as it is, I already like your water generation routine - I always have to fly up to a floating island and put down a water block then fly off and turn around to see the magnificent waterfall created! My ONLY gripe would be to not put down 'water blocks', but rather a 'spring' which outputs a set amount of water blocks which each follow the terrain, falling, and eventually pool up somewhere - so no static water hanging in the sky, actual moving blocks of water (possibly the 'spring' blocks could have a variable set amount of water so they could generate a waterfall for a finite amount of time instead of just a quick shower.... and on the surface, watching a depression 'fill up' with water then overflow would be a pretty awesome sight as well! But, I understand that this would involve alot more processing and programming.
but you are essentially adding a _water_ block
you arent pooring water, that is the difference here
if i was to add a bucket item, then that would indeed be as you say, water that flows until it stops, or dies out :)
players arent supposed to be able to place water blocks
this is for internal testing, more or less, only :)
the water 'flows' but then freezes in unnatural shapes... if a placed water block produces X amount of other water blocks that 'flow' then all of the blocks of water will flow until they find a resting place and cannot flow anymore... so placing a water block on a floating island will prodce a water fall that, as soon as the water blocks run out, will result in a pool of water on the ground somewhere and no water on the floating island and no 'waterfall' anymore. just thinking aloud here is all, not exactly a 'feature request'
when i revisit that part, another time, i will keep what you say in mindleopardpm wrote:the water 'flows' but then freezes in unnatural shapes... if a placed water block produces X amount of other water blocks that 'flow' then all of the blocks of water will flow until they find a resting place and cannot flow anymore... so placing a water block on a floating island will prodce a water fall that, as soon as the water blocks run out, will result in a pool of water on the ground somewhere and no water on the floating island and no 'waterfall' anymore. just thinking aloud here is all, not exactly a 'feature request'
though im not exactly sure how i can, worst case scenario, find a resting place for a waterfall that might land on flat land
also, i uploaded a new build with better movement, and a few fixes, for falling blocks
probably not gonna post any more builds for a while :) just making sure what is there works
I will check it out! I really want you to understand how much both your replies and demo program have helped me in my thoughts and coding.
You prompted me to overcome 'fears' of openGL and now I am messing with it, creating terrains and such...
Convinced me that FreeBasic + OpenGL can achieve high enough frame rates for a high quality game that can compare to commercial products
Introduced me to start thinking about some things from a different perspective (3D pun intended)
Thanks again and have fun retreating into your programming cave/heaven! Can't wait to see what (if anything) you produce for us to view when you emerge!
You prompted me to overcome 'fears' of openGL and now I am messing with it, creating terrains and such...
Convinced me that FreeBasic + OpenGL can achieve high enough frame rates for a high quality game that can compare to commercial products
Introduced me to start thinking about some things from a different perspective (3D pun intended)
Thanks again and have fun retreating into your programming cave/heaven! Can't wait to see what (if anything) you produce for us to view when you emerge!
good luck with your project then :P
as for me, its the usual day at home
http://dm.fwsnet.net/angularshadows.PNG
should be as fast as before, a little less perhaps, but i didnt notice it
edit: which turned into quite the more complex version:
http://dm.fwsnet.net/angularlighting2.PNG
work work!
as for me, its the usual day at home
http://dm.fwsnet.net/angularshadows.PNG
should be as fast as before, a little less perhaps, but i didnt notice it
edit: which turned into quite the more complex version:
http://dm.fwsnet.net/angularlighting2.PNG
work work!
