Voxel - Visibility

[Kitty Hello]

V11 can disable automatic normal calculation. You can specify them manually then (see online help). That might give some speed boost when creating x_objs. Amazing project!

Somewhere I did something like this but with rounded corners... might be a cool enhancement.

Sent from my GT-N7100 using Tapatalk 4

[Slydog]

Thanks for the kind words.  Dang, now I have to take this further! 

I fixed the FPS display.  I was showing the frame duration I suppose.  Thanks for the suggested fixes, but I found a very simple algorithm at StackExchange, and converted it to GLBasic (it seems to work):

Code: (glbasic) [Select]

FUNCTION DisplayFPS: x%, y%
STATIC averageFrameDuration# = 0
averageFrameDuration = (averageFrameDuration * 0.9) + (GETTIMER() * 0.1)
PRINT "FPS: " + FORMAT$(3, 0, 1000.0 / averageFrameDuration), x, y
ENDFUNCTION

@kanonet: ha, ya, I rechecked the code to see what you meant about GENX_OBJ().  First, I didn't even remember there was such a command (it doesn't begin with an 'X_'!).  But I may remember when I first created the mesh TYPE (years ago), that it doesn't actually use the returned value from GENX_OBJ() until you add some geometry to the model.  So if I call that command 10 times at the program start, all meshes would all get the same id.  My fix was my 'smart' way of getting around that.  But I took another look, and simply inserted the check (if id<0) in the Generate() function, and that seems to work awesome.  I deleted my 'smart' function and now I'm using GENX_OBJ().

@Kitty: Hmm, interesting idea, didn't even know calculating normals by hand was an option.  Will have to update to use that.  Does a normal have to be normalized (ha, sounds weird)?  Is it a simple vector (0,0,0 origin) that points away from the quad face?  And relative too I hope, so all north facing walls can all use the exact same normal for all four corner vertices?  I could precalculate each face normal during initialization, and use those for the mesh building later.  Will try this soon.  Does 'X_AUTONORMALS 0' speed up model creation since it doesn't need to auto-calculate normals?  I find it still a little slow using '0', but of course the normals are way off.

@dreamerman: Cool, you got this working on Android?

@erico (and others thinking 3d programming is difficult):  That's why I created the TMesh TYPE (and TVertice, TQuad).  It handles all the low level details for me (like above, I didn't even remember the GENX_OBJ() command since I seldom venture into the mesh code).  You just have to keep it straight in your head (or paper) the x, y, and z coordinates of the vertices you need, create some quads (each containing four vertices), and then add those quads to your model (then finally call the .Generate() command to finalize the process and create an actual 3d model).  All done in steps to keep your head sane.  This project is probably a good starting point for dynamic 3d model generation (especially if you use my TYPEs).

I think I will at least do the texture atlas portion next.  I will be using TexturePacker to pack my textures into a sprite sheet (there is a free version, but the full version is only like $25).  I'll need to create code (I'll be using bigtunacan's code as a starting point, thanks) to read the sprite sheet definition file, and TYPEs to handle extracting individual sprites/textures from the sheet.  Then use this to allow you to define your voxel textures using individual files for each face, and reference them by filename in GLBasic (such as 'cube_grass_top', 'cube_dirt_left' or something meaningful).  I've done this in Unity so porting the code shouldn't be difficult.

I attached the updated project with the fps fix, and GENX_OBJ() fix.

[erico]

Nice, Slydog! I will check the newer version later today.
I´m sure to book mark this page and project for when I get in 3d on GLB.

You mentioned textures, so here I wonder...Since it is all cubes, there could be a fake occlusion shadow effect/shader going on by using the bumbmap channel.
That would mean a bump map atlas that gets attached to quads depending on the neighbor blocks.

It could be done blending a black and white degradee to the texture, but here I think using the bumpmap might be easier and faster, Mentalthink mentioned something similar to that a long time ago.

Just throwing some ideas on the pot.

[kanonet]

Nice looking FPS code, but I prefer GETTIMERALL over GETTIMER besides this, my function should be faster in execution speed.
You are right, GENX_OBJ can not get used in row without creating a mesh in between calls, but thats easy to work around and its still saver to use this instead manual choosing a slot. So got decision to use it!

Normals need to be normalized (ok I dont know if X_OBJADDVERTEX_NORMAL does it automatically), but since in our case all normals are same direction like the world axes, this is easy to achieve, normals simply will be things like (0,1,0) etc which is normalized. Of cause all normals will be the same for all faces that look in the same direction, so we only need 6 different normals.
BTW normals need to be normalized cause for some strange reason GLB does not use glEnable(GL_NORMALIZE), which it should, cause if you scale your mesh ATM your normals get scaled too, so they are not normalized anymore, so you get wrong lighting. I would consider this a bug and suggested to fix it long time ago, when I published my lightfixes, but nothing happened yet. But this does not matter for this project here and it can easily get fixed in your other projects by one single native opengl call.

I dont think your mesh type is a really help for someone new to 3D, for me it looks like it overcomplicates things - but maybe thats just cause I already know how to do stuff with normal GLB commands and are used to them. BTW for a 3D newbie I would suggest to ignore generating meshs, but simply load .ddd objects, Should be an easier start.

BTW there is a bug in your last version: you use chunksize (4,12,4); since your world hight is 12 too, you only have one chunk in height. If you now change chunksize to (4,4,4), so you have 3 chunks in height, your mesh gets messed up. This problem did not happen in your last version (I just downloaded it again to confirm this!), so I think it must be caused by some of your recent changes.
BTW if your (worldsize/chunksize) is not an even number, a bit part of the world gets not rendered - I guess thats intended, I just wanted to mention it in case its not. I would prefer it, if in this case the world gets bigger to fill a full chunk and the new parts of the chunk get filled with 'air blocks'. This could especially be needed if you introduce chunks in chunks in chunks etc. (I think this later feature is necessary, maybe I will add it on one of the next weekends).

[WPShadow]

hey,

I think all the time about the following concept of the usage of voxel:

Shouldn't it be possible to build objects with the voxel engine? For example a house. With walls and something else. On the outside is the wall.

Now what would happen if you shoot a bullet on the wall? several voxels would be destroyed --> so what will happen that moment to the invisible voxels behind them?

[Slydog]

Wow, this is almost seven years old!
JohnnyB noticed my zips are corrupted.
I can confirm, it downloads but the files are corrupted when unzipped.

I can't find the original files on my Dropbox anymore.
Does anyone else have a copy kicking around they can re-upload?
(Ha, I know there's only a slight chance, but I thought I would ask!)

Although, the thought of dusting off my copy of GLBasic and redoing this does sound intriguing . . . 

[dreamerman]

As it was in my area of interest I kept it in my archive, not sure if that's latest version that You have uploaded but here it is
Something could be modified, but it should be easy to track and change after digging in all those posts.

[erico]

Yep, I noticed last forum "acting" got the files and pictures messed up. I wonder if Gernot can do something about that but it has been a while so it is probably not possible.
This is a wonderful project, up to this day I get people asking about voxels with GLBasic.

Get back at it Slydog!

[JohnnyB]

Great stuff. Now it would be good to be able to wrap individual textures around the meshes. Is this wise, when it comes to performance?

[dreamerman]

No, that isn't advised, generally best solution is to use as low texture count as possible, just by packing all separate files into atlas sheets, same goes for 2d and such 3d graphic. Consider that You would have 10 different block types, so during rendering (depending on block position and so on) current texture could be changed hundrets of times, that's not good. It's different for 3d racing game where is one texture for world/track and other for car, as it isn't changed so often while rendering. There are also texture arrays, but for that You would need to use inline OpenGL directly from what I remember. So simplest solution is just to put as many textures/sprites into one large texture - atlas.

Not sure what are limits to texture sizes now but 3Dfx cards had 256x256 limit, Riva TNT2/first Geforces had 2048x2048, iPhone 3g had 1024x1024 limit, newer phones have higher at it should be at least 2048x2048, quick look at it looks that Unity and Android OS support's max 4096x4096 so this should be the limit. If You would need more, then texture arrays would be solution, but this is already huge. For some minecraft style project You can use 64x64 textures for cubes in one atlas and have separate atlas for UI stuff and so on.

[erico]

Sure shot, a single big texture within the atlas approach should be the fastest.

[Schranz0r]

Hmmm, would be nice to do it the modern OpenGL way with shaders... 
Maybe i'll give it a shot this week!

And a textureatlas should be the fastes way to do.

[Slydog]

The '_mesh.gbas' allows for texture maps using the 'QuadAddV4()' function.

Code: (glbasic) [Select]

FUNCTION QuadAddV4%: v1 AS TVertice, v2 AS TVertice, v3 AS TVertice, v4 AS TVertice, uv1 AS TUv, uv2 AS TUv
You pass the texture coordinates using the uv1 and uv2 parameters when adding a new Quad to a mesh.
The TYPE 'TUv' expects two floats representing the x,y position in the texture, normalized from 0.0 to 1.0.
uv1 is the top, left corner, and uv2 is the bottom, right corner in the texture. (If I remember correctly, it may be bottom,left to top,right or something).

You would modify the 'Mesh_QuadAdd()' function from '_voxel.gbas' to detect the face type, and include that face's uv coordinates in the 'quad_offset' variable.

Code: (glbasic) [Select]

quad_offset.SetUv(uv1, uv2)(You actually don't need to use the above 'QuadAddV4()' function in this case.)