They both seem to have their advantages. RLE for describing the distribution of block types, and octrees for describing the actual volume all blocks take up for that chunk.

You can probably combine both ideas by using a single flat array delimited by the block type IDs, so the renderer knows what blocks to draw separately by texture.

I'm currently trying to make a voxel engine just for fun (maybe for a simple top-down shooting game), and taking advantage of the octree structure by drawing single, large cubes for the larger nodes instead of filling it all up with equal-sized cubes. The hardest thing for me right now is actually taking the node index to correctly position the cubes in 3D space.

You're right, I forgot to mention that.

I personally use octrees all the time. I've only used RLE once in a really early project I did a few years back. I chose it over octrees back then since it was much easier to implement and I wasn't too comfortable with C++ at the time to work with octrees.

Why do you use Octrees now?

They are (in my opinion) more efficient for larger datasets. I use them mostly for terrain rendering as you are able to collapse the tree for father areas (less detail) and expand the tree for closer areas (more detail). I'm also experimenting with GigaVoxels and Voxel Cone-Tracing which both use octrees for efficient data storage and access.

I understand the advantages of both just seem a little confused on what to do after reading...

http://www.sea-of-memes.com/LetsCode32/LetsCode32.html

and

http://0fps.wordpress.com/2012/01/14/an-analysis-of-minecraft-like-engines/

The first article is actually where it clicked how I would store the block-filling space as an octree. I did not actually look at the code samples from either. What are you having trouble with, storing the data or how to properly render the blocks on the screen?