Just trying to wrap my head around this as I’m new to 3d programming. I’m trying to attach two cubes together but first I need to pick a side of a cube. I can do a normal ray and see if it collides with a cube but I’m not sure how to determine what side of the cube I picked.
Not sure where to start on this, any ideas? Thanks
Hi shazzner,
which side is not so important. you can calculate the position of the new cube with the collision point and the collision normal. It’s quite simple:
a) calculate a CollisionResult cr
b) Vector3f targetPosition = new Vector3f(cr.getGeometry().getWorldBound().getCenter().add(cr.getContactNormal().mult(CUBE-SIZE)));
That’s all 
http://code.google.com/p/bloxel/source/browse/trunk/bloxel/src/main/java/de/bloxel/ui/BloxelActionController.java#60
http://code.google.com/p/bloxel/source/browse/trunk/bloxel/src/main/java/de/bloxel/ui/BloxelApplication.java#164
Another solution could be (I tried this for a “cube-side-picker”):
a) calculate a CollisionResult
b) read the triangle-index of the collision
c) you must “know” the internal mesh structure to say index xxx is side 0,1,2,3,4 or 5
d) you can get the triangle for the index … but remember a jme-box have always 2 triangles per side (here I give up g )
Regards
Andreas
Hi Andreas
private void actionAddBloxel() {
final CollisionResult cr = bloxelApplication.checkTargetPosition();
Here you call checkTargetPosition withouth any parameters but
public CollisionResult checkTargetPosition(final Collidable aNode)
requires aNode, and if aNode is not sent how can this call be executed since aNode should be null:
return checkTargetPosition(aNode, ray);
Also can you explain this inside private void actionAddBloxel():
if (cr != null) {
if (cr.getGeometry() != null) {
} else {
// we hit the terrain node
what is first case and when does it happen? What is else case “hit the terrain node” also when does that happen? Could you try to explain that from user view and user interacting with enviroment, for example user clicks on screen and hits something, actionAddBloxel gets called, when does if case happens and when does else case happens?
alight … in our game we have the concept of near and far elements (currently g):
a) near elements : new Node(“near_elements”) → add to root-node
near elements are “pickable” elements (selectable cubes around the player position)
such elements can remove or add more elements to (add/remove bloxel)
b) far elements : new Node(“far_elements”) → add to root-node
far elements are “readonly” elements (geometries from merged cubes around the player position) → terrain node
if the game is running the screen shows the terrain-chunks around the player (merged geometries) and the near elements (real Cube-Geometries), so there is no visual difference … only for minimize the loaded objects.
clearer?
yes thats clearer, so is far elements resulting in
else {
// we hit the terrain node
and near elements result in
if (cr.getGeometry() != null)
??
Btw can you show me the class and functions that are responsible for merging the cubes into bigger mesh. Do you only merge cubes with same texutures. Can cubes with different textures be merged into one and same qube?
I noticed that you did not construct your own custom cube by using vertices and indices but you went with new Box() that JMonkey supports. Would there be any benifit by constructing cube your self over creating box?
Btw do you create cubes that are not touching any air and are surrounded by other cubes or do you optimize and jump over creating them?
I got a hint from this forum to use GeometryBatchFactory … have a look at http://code.google.com/p/bloxel/source/browse/trunk/bloxel/src/main/java/de/bloxel/world/PreviewTerrainChunkImpl.java#132
I’m using a “special” Box : http://code.google.com/p/bloxel/source/browse/trunk/bloxel/src/main/java/de/bloxel/mesh/MultiFaceBox.java
See http://ahoehma.wordpress.com/2011/03/02/multifacebox-mesh-for-bloxel/ for the whole story 
And yes … we should improve the bloxel performance more and more … maybe with special mesh’s to reduce the number of triangles/vertex (I guess … this would be a question to the jme-profies … is it necessary to create such a “optimized mesh” … I don’t know right now :))
regards
Andreas
Hi guys
thanks for explanation and the links Andreas.
I have some interesting links for you guys about terrain generation so you can learn and get inspired
from the man him self:
http://notch.tumblr.com/post/3746989361/terrain-generation-part-1
Read this to learn more about minecraftsk terrain generation methods, etc, very good read with lots of pictures.
It’s better and more technical read then Notch’s writeup above, be sure to check it out:
http://archive.gamedev.net/community/forums/mod/journal/journal.asp?jn=259175&cmonth=11&cyear=2010
this one investigates what is possible with openGL 4 and GLSL shaders, its using Phyton for this. Results speak for them self and code is available for anyone that wants to learn or experiment or pick apart GLSL shaders and learn to do it them self perhaps with jMonkey
http://codeflow.org/entries/2010/dec/09/minecraft-like-rendering-experiments-in-opengl-4/
http://www.youtube.com/watch?v=1Bir9qbJJXg
Cool links @moonkey, definitely exciting to see notch is starting to share some of his tricks As for the OpenGL4 demo though, I don’t really get it. Have you checked out Mythruna by our very own @pspeed ? His game, like jME3, only requires OpenGL 2 and higher and it looks absolutely stunning!
@erlend_sh
yes I am looking at the latest build, he has lots of code in there and really nice engine so far, impressive!