Ok guys,
I write a simple test to get something simular to minecraft ( very very veeeeeeeery basic! )
It occurred to me that i have problems if i draw a block twice ( same objectID ) and use a pickroute(X_COLLISIONRAY) -> i select both of them.... :/
No problem so far, i can load for each cube a new object with new ID, but is this the best solution?
The real problem is that i have to set a ObjectID to use X_COLLISIONRAY :(
I'm realy pissed off and have no idea for a good way to do this...
Sad moment :/
Thats why I posted this http://www.glbasic.com/forum/index.php?topic=7723.0 a while ago :)
I probably would not use X_COLLISIONRAY as it's quite an expensive routine to call for the mass of cubes, esp. with something as massive as a minecraft voxel landscape.
This is just an idea but since your landscape is basically a 3 dimensional array, I would first of all get my location within that array(eg. your x/block width, y/block height, z/block depth) and get the camera normal(maybe in X_GETCAMERAMATRIX()?) vector, fire it out from the camera position there block by block to get your nearest block in the direction your are facing. This would be very inexpensive, CPU wise I think.
Maybe im wrong, but i think you used it wrong in your pick routine, i think you made the error to think in entitys. If you load one object and draw it multiple times, thats perfect and the way how it should be done. If you use collision commands (i used X_COLLISIONAABB, but should be the same for Ray), you need to keep in mind that it test against the object on the position of the current matrix, so if you test the same
lets say this is your drawing routine:
// load obj
X_LOADOBJ "model.ddd", obj_1
obj_2 = obj_1
// draw obj #1
X_MOVEMENT -5,0,0
X_DRAWOBJ 1,1
// draw obj #2
X_MOVEMENT 5,0,0
X_DRAWOBJ 1,1
Then you can not test for collision this way:
IF X_COLLISION obj_1,... -> collision obj 1
IF X_COLLISION obj_2,... -> collision obj 2
Because both times you would check for collision on the same position which of cause would give you the same result for both. To check on the real collision of each one, you need to add there real position (rotation and scaling too of cause). So it should look like this:
// check obj #1
X_MOVEMENT -5,0,0
X_COLLISION obj_1,... -> collision obj 1
// check obj #2
X_MOVEMENT 5,0,0
X_COLLISION obj_2,... -> collision obj 2
Same for movement, rotation, scaling, the hole matrix.
If you do it properly, you should be able to get a working picking routine.
Btw. like bigsofty i prefer to calculate my collisions by myself, rater than use the X_Collision commands.
Note2: i think drawing that many cubes may be to slow i would think it could be better to construct (just one time, not every frame) and draw bigger chunks, less drawing calls means more speed! And keep in mind, that X_SETTEXTURE is slow, so better pack all textures into one file and just move texture coordinates on your cubes.
In my Minecraft demo, I created one object with many faces (like a shell chunk or block surface). So the object "surface only" gets recreated based on a 3d array. For Minecraft, there is no reason to use real cubes because it is a waste to render the extra sides.
matchy, thats the best idea EVER :)
Now i solve the most of my problems, to understand how minecraft works!
BUT:
I have a huge problem with my chunkcode, the creation of the object itself is to slow :)
There is a huge bottleneck :/
i attach the code!
[attachment deleted by admin]
Hey that is cool. How about reducing the chunk size with perhaps a flyby demo of chunks being created? For now, what get's rendered near the camera would be different that distance chunks (which could resemble 4 close up chunks).
its 20x20x20....
No chance to use it in realtime!
and i need Threading :D
ehhhmmmm :whistle:
Help? :)