Home       About Me       Contact       Downloads       Part 60    Part 62   

Part 61: Redesigning Crafty

August 23, 2012

As part of getting the project back on track, I think I'll try weekly blogging. I really prefer to write after I've completed a piece of work, but as I get into larger pieces of code, that approach isn't going to work. Completed milestones will just be too far apart.

I am still uncertain about weekly blogging though. I'm worried that posts will cover too many topics (as I flit from one part of the ToDo list to another) or will just be "I didn't feel well this week, so nothing got done." We'll see how it goes.

I worked on two things this week -- some experiments with 3D printing, and work on redesigning Crafty to make it a block-world game platform.

3D Printing

Fig 1: Mineways selection
Fig 2: Printing options
Fig 3: Printing a Model
                          

Back around the beginning of August, I happened to recommand a 3D printing site called Shapeways.com to someone. I hadn't looked at their site in a long time. There have been some interesting developments. For one, they can print much larger models now than I remembered. They are also printing in color. And they link to a Minecraft printing application called Mineways.

The program presents only a map of the Minecraft world (Figure 1.) This makes it hard to find the object you want and hard to set the exact bounds (especially vertically.) Then it prompts you with a long list of printing options (Figure 2). The problem with this is that printing is so expensive, you'd never want to try all of these options out!

I selected a rocket ship I remembered from the TwentyMine server, and told it to make cubes 6 mm each, to make the model the largest they could print. Uploading the print file to the Shapeways site, I had my price... See Figure 3. Oops.

Their material "colored sandstone" is described as

...a gypsum-based powder that is bound together with an adhesive and simultaneously embedded with an ink jet head. The products are then finished with cyanoacrylate (same stuff super glue is made of) sealant to ensure durability and more vivid colors. The printed product is a hard, rigid material that is slightly brittle and not suited for structural parts under great load.

Discouraged by the high price, I picked something that would look good smaller (2 mm cubes) and printed that. This was a small bridge, also from TwentyMine, and the print was only $12, plus $3 handling, plus $6 shipping. So for $21, a little bridge appeared via UPS a few days later. See Figure 4.

Fig 4: A bridge made real!

Of course, I immediately started to notice problems with it. For one, the Mineways program skipped all the torches. It also prints the railings as full blocks. The default settings at this size also don't use very detailed textures. As you can see, everything is pretty much a solid color.

There is also the material itself. It does feel like sandstone -- very gritty, not the sort of thing you want to pick up and play with. And the color runs if you get it wet. I put a few drops on the base and rubbed it dry. A day later it looked like Figure 5. I suspect it wouldn't do well in the sun either.

Fig 5: Color comes off

Still, it was very cool to see a virtual object made real, so I wondered if I could generate some output from my various demos. In particular, I was thinking that McrView would make a much nicer input program than the Mineways program.

Fig 6: A thin-walled cube
My first question was what makes the rocket ship model so expensive? I know that it's large (330 mm/13 inches tall), but that still seemed excessive. Reading the documentation, it turns out they bill you by the cubic centimeter of material used -- $0.75 per cc. And inspecting the model with MeshLab, I discovered the Mineways program had made all the cubes solid. Aha!

I wrote code to output a cube with thin walls in VRML, which is their preferred input format for color data, and uploaded it. Just to check price, I made the cube 150 mm on a side, which is their maximum. The result was surprising! (Figure 6)

Reading further, I discovered that models need to have a "drain" put in them somewhere. The way the 3D printing process works, it makes the solid parts by gluing or laser sintering the parts out of the material, which is a layer of dust. After a slice of your model has been printed, the tray fills with another layer of dust. If your model has no holes, they can't drain out the unused dust, and you are billed for the entire volume. Adding a tiny 4 mm hole in the side of the cube completely changed the price.

Looking at the rocket model some more, I noticed that the rocket ship has a very detailed interior. However, the Mineways program had turned all the windows and doors solid, so you couldn't see the interior. In other words, it had made three huge mistakes:

  • The model could have been emptied of interior blocks, but wasn't.
  • It could have had a shell of 1 mm instead of blocks of 6 mm.
  • It needed a drain.
I haven't done enough code to output a correct model for the ship, but I think the final price would be more like $80 instead of $519.

Fig 7: Inside corners

So far, all I've done is output simple cubes. I started on doing thin-walled cubes in a more complex pattern, but discovered it was more of a nuisance than I thought it would be. The walls are easy, but I also need to create interior corners where the walls come together (Figure 7). The walls need to join up properly, with no duplicate edges (a "water-tight" and "manifold" shape.)

I'm also not sure how to place the drains. Visually, you don't want too many of them, since they are holes in the surface. However, they warn you that complex models will need more drains. I'm not sure how they handle a complex shape that can't be drained.

Finally, if I do this right and make the thing completely hollow with thin walls, I'm not sure how strong it will be. I might have to add some internal supports, but at what interval? It seems impossible to know without printing something hollow and seeing how easily it breaks. I'm not sure I want to waste the money to find this out.

I've put this on hold until I finish off with Crafty. I still want McrView to be able to export models that can be added to Crafty and SeaOfMemes. That will be the time to put in a 3D print function as well.

Redesigning Crafty

Crafty is currently McrView without the functions to load Minecraft data. Instead, it just generates landscape procedurally as you move. To rebuild this as a game platform, I need to decide what capabilities I'm going to support. At minimum, this includes the following:

  • A Landscape class which holds terrain. Terrain is modifiable and stored in a DB. Chunks of terrain are swapped in and out of the display as you move. New terrain is procedurally generated.

  • An Avatar class used for players, monsters or machines. Avatars have movable, named limbs made out of smaller blocks. The definition is loaded from a file, and there can be many instances. There's no reason they can't be modifiable and stored back in the DB. An in-world avatar editor should be possible eventually. Avatars are assumed to be small and drawn completely, not paged in and out like Landscape.

  • A Sky class which handles sunrise, sunset and weather. This will be very simple at first and is low priority.

  • Some generic Effect class, for adding effects like explosions, laser beams, etc.

  • A Game class which concentrates all the game logic in one place. This includes controlling player movement (including gravity, collision detection, etc.), generation of new landscape, positioning of monsters, and interactions between monsters and the player. Eventually, there will be an implementation of Game which calls into a script interpreter like Lua or Javascript.

  • A simple server which replicates world state to multiple users. I'm not sure how much of the Game logic would have to live in the server. To make it completely authoritative, all of Game would live there. Perhaps I can split Game out so that even when playing single user, you are talking to another thread which implements Game. Then multiplayer would look the same architecturally, except the Game script would live in the server.

The default demo should be a simple game, just to get people started. I'm thinking some kind of combat-with-monsters thing where you work through a destructible world. I haven't decided on any details. I suppose it could look a lot like Minecraft.

So far, I've just been restructuring the code and making notes on what the new classes have to do. I need to get the Object Store I described in Part 53 integrated, so that I can use it for saved Landscape and for Avatar definitions. It will also be used for import and export from McrView.

I also need to make my brick rendering code work under arbitrary transforms so that I can render moving limbs. One big issues is what to do about transparency in this more complex world. What I have now sorts transparent bricks from near to far in the landscape. That won't work when there are multiple objects.

I could just restrict avatars to only having solid bricks and only let the landscape (with buildings) have transparency. This is the simplest solution in the short term. For avatars, I think it would be fine if they can't have transparent parts. But the Avatar class would also be used for machines, like a floating ship. If the ship can have windows, then you could have transparent windows in the ship object interacting with transparent water in the landscape object.

In that case, my code isn't really up to drawing the correct view. I could combine brick lists between objects and sort them (a nuisance), but only if the ship were aligned with the grid. If I want a smoothly moving ship, then I have arbitrary intersections between ship blocks and water blocks. I don't have any code to handle that case. I'm not sure what to do.

So that's where things stand at the moment. No code to play with this week.

Home       About Me       Contact       Downloads       Part 60    Part 62   

blog comments powered by Disqus