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.
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.
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.
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.
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:
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.
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:
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.
blog comments powered by Disqus