Hello, I am new here to the Xith3D community and the library itself, though after reading some comparisons between this and Java3D, and going O.o over LWJGL (with raw OpenGL, which is fast but I prefer not to code 20 lines to draw a rectangle

) I decided to use Xith as my preferred Java 3D library.
Hello there!
Now that I've told my life story, I would like to ask a few questions. I am making a game that uses Primitive 3D shapes (cubes with textures) as tiles, in a 1000x1000x200 tiles map (though however not all of the cells on the map of filled, of course

) in a similar fashion to... I guess I can use
Minecraft as my comparison, since it will use a similar 'cell-based' environment, though Minecraft uses raw OpenGL from LWJGL instead. Here is my question: what would be the best way to implement this map?
We'll address that in a second.
I already have a few possible ways I thought out, the most practical of which are:
- Initiate a Cube[1000][1000][200] array of cube objects to be added to the main scenegraph, and then using StaticTransform on each cube, move them to their right place (and then maybe put like a huge 'fog' thing that hides all tiles more than 50 tiles away to add performance speed)
This is almost certainly going to exhaust all of your memory, and might bring the scenegraph of Xith to its knees.
- Initiate a 100x100x100 scenegraph with blocks that has blocks whose textures change every frame comparatively to the part of the int[1000][1000][200] buffer to be shown to player, based on his coordinates
This has potential. More in a bit.
... and all the other ideas suck

(and these probably do as well). So, I was wondering, does anybody have an idea of how I can implement this with a respectable framerate? and possibly without consuming much RAM or processing power?
It's a hard problem.
And question 2: how do you make blocks translucent?
TransparencyAttributes ta = new TransparencyAttributes(TransparencyAttributes.NICEST, trans);
ta.setMode(BlendMode.NICEST);
ta.setEnabled(true);
shape.getAppearance(true).setTransparencyAttributes(ta);
So, let's look at your problem. You've got a world full of blocks, and want to use Xith to render a subset of that. The naive approach is to fill the scenegraph with blocks for each cube. This will choke the scenegraph, most likely.
A better way of looking at this is to consider the data in the problem: a large 3D array of blocks of different types. So, if you allow yourself to group similar blocks into larger and larger cubes (my colleague suggests the term "chunks" while reading over my shoulder), you only have to worry about rendering the larger chunks. For a chunk made of 3x3x3 blocks, you only render 1 Cube, saving 8! A chunk of size 5x5x5 saves 124 Cubes. The saving increases as you make the chunks larger in volume.
To do this, we see a suggested form of the solution: one data structure for the world, and one for the visual representation.
The world data structure contains an array of blocks of known size and shape, so you can quickly find the blocks you need by a quick calculation (think on how you calculate a pixel's address in a frame buffer; this is similar). I imagine that you want blocks of various types. Assuming that you want 255 types of blocks, and an "air" block, you can get away with using a Java byte primitive (signed 8-bit integer type). If you want to add hitpoints, then you look at adding another byte. By this point, you've got 16 bits per blocks, so you could just have a big array of shorts.
The visual representation would be a collection of chunks for similar types of blocks, drawn as Cubes. As you move around, you calculate the chunks needed from the world data structure and generate the Cubes needed to represent them. This might be a somewhat heavy option.
Those're just my first thoughts on the matter.