Thursday, May 26, 2011

mvminer update - textures and physics

I've put in a few evenings working on mvminer's renderer. I have implemented a unique texturing system and I just finished throwing in a complete-hack physics test.

One of my design goals for mvminer is for each block to have a unique, procedurally-generated texture. This will make single material structures more interesting and opens up possibilities for player paintings or other dynamic texture changes.


The first implementation of unique texturing

When I first got it working I wasn't doing actual seeded procedural textures. The screenshot above uses rand() to fill in the index half of a bunch of DXT1 blocks, the color half being selected from a table based on block type. That, of course, is completely nondeterministic and is unrelated to spatial location. With the basics working, I implemented a straightforward Perlin noise function that takes an absolute world location.


The inside of a large box textured with a few octaves of Perlin noise

The result looks pretty good! At some point in here I decided to fix block sizes at 0.5 m to a side (half of Minecraft's block size) and texture resolution at 8x8 per block face. To get a better idea of the noise's spatial qualities I hacked a sphere generator into the new-chunk generation code:


Behold the dirtsphere

For comparison, I set up a similar screenshot, but with each block having a randomized origin location. This represents what a user-created structure would look like, with spatially distant blocks brought together.


Dirtsphere, chaos edition

At this point I was getting tired of waiting for texture generation. Generating ~3000 tiles was taking about 20 seconds, so I switched back to rand() to work on some other things. First up, a simple terrain generator.


mvminer is a game about dirt

I switched the Perlin tile generator back on for that screenshot, and it took a few minutes to come up. My plan is to generate batches of noise, computing corner gradients once per batch and then lerping (well, quintic-erping) a bunch of samples in a tight loop, but that can be done later.

Last night I decided to try integrating a physics engine. I had used the Open Dynamics Engine in a previous project and I was getting to know it quite well, but the limited collision detection system was getting annoying. I thought it was time to try Bullet, so I downloaded the latest archive, built it, and had a horrible hack implementation up and running in a few hours.


There's something odd about this box ... could this be what they call rotation?

Once again, it's a complete hack. I need to code up a solid local physics entity system. Minecraft has weird behavior out in the Far Lands, where 32-bit floats start to have much less sub-integer precision. I intend to avoid that by segmenting the simulation along chunk boundaries and keeping coordinates nice and small. Eventually I'd like to remove Bullet in favor of a custom fixed-point physics system, for the dual purposes of absolute determinism and educational wheel reinvention.

Up next, an in-depth description of the virtual tile map system that makes unique texturing possible (and easy!).

No comments:

Post a Comment