#terasology

[ttech]

Terasology: Clon open source de Minecraft

Terasology: Clon open source de Minecraft

(more…)

View On WordPress

[immortius]

Voxel Physics

This post looks at some of the common approaches to integrating physics with a voxels I've seen and used, as well as the approach I settled on for Terasology.

Before that let me clarify what I mean by voxel physics: supporting collision and hit detection of a voxel world, including individual voxels. This does not touch on voxel dynamics such as having floating voxels fall or detecting unsupported structures.

Integrate an Existing Physics Engine

This is an obvious path to take, particularly if already using a game engine with built in physics integration like Unity. Full physics behaviour with a variety of shapes is a complex area, so using an existing and hopefully well supported implementation is enticing.

The vast number of voxels as usual puts some constraints on how to approach this. Adding a collider per voxel will consume vast amounts of memory and perform poorly. A better approach is required.

One method that works reasonably well is to generate one or more collision mesh for a voxel chunk. Multiple mesh will be required if there are multiple collision behaviours - perhaps some voxels are solid, while others can be passed through but still can be targeted. Often this can reuse much of the mesh generation code used to render the world - but generally cannot be the same mesh due to differences between what is displayed and what can be collided with.

There are a few downsides to this technique:

Generating and updating the collision mesh takes time. This can be done on a background thread, but there will be a delay.

In some engines the mesh will be set up for rendering even though that is not required for your usage. This means it will use video memory and take longer to build.

Mesh colliders are paper thin, which means you have to be careful about objects passing through them. In particular when the collision changes due to a voxel being added, any object inside that space will fall into the collider.

The mesh use some amount of memory.

Extra work needs to be done after colliding with the world to determine which voxel was hit.

Another technique is to add colliders for each voxel, but just in the immediate area around players or other actors of interest. This has some immediate advantages:

Per-voxel collision with whatever collision shape best fits each voxel.

Can update immediately with voxel changes.

Small memory footprint, if the number of actors requiring collision is small.

The downside is the limited area in which collision works - you cannot do long-ranged ray traces, nor have objects bouncing around everywhere. Velocity can also be an issue, as a fast moving actor could exceed the collision area in a single tick. Still, this can work well for character movement and can be combined with other techniques.

Roll Your Own

Having seen the options for integration with a physics engine you may be thinking you could do better. After all, your voxel world is composed of a axis-aligned grid of primarily cubic objects - you can easily work out what grid cells are involved in any ray trace or potential collision. And this is correct to an extent.

Ray tracing is pretty straightforward. The ray trace need only step through the voxel cells - you can work out which cell is next from the side of the cell it exits from. Some care is needed for traces along the edge or passing through the corners of cells - these may need to hit all the cells they touch for correct behavior. Supporting non-zero extent traces (where the ray has a diameter) may also be useful.

After determining a cell is involved the ray can be tested against the shape of the contents. Axis-aligned boxes and spheres are simple, but more complex shapes are possible too.

The advantages of rolling your own are:

Can hook directly into world data, so little memory cost or delay in collision availability.

Performs well by taking advantage of the voxel structure.

Per-voxel collision info is easily available.

The problem with rolling your own physics is when to stop. Beyond ray tracing is convex sweeps, collision between moving objects, rigid body simulation, constraints... If you are primarily interesting in creating an engine then this may be ok, but if you have some other goal like creating a game then producing and maintaining a physics engine is a poor use of your time.

Extend a Physics Engine

This is the solution I went with in Terasology - take an existing physics engine and build in support for voxel structures. These structures can link directly to voxel data, providing all the benefits of rolling your own engine, but can take advantage of the collision algorithms and features of the existing engine.

The restriction is that you need access to an open source physics library or one with an api that supports the necessary extensions.

For Terasology I extended JBullet (a Java port of Bullet) and named it tera-bullet. The extension is a new Shape called a VoxelWorld. This shape provides the ability to request information on the collision shape of each voxel. The collision algorithms for VoxelWorld work out all the voxels involved in a collision and delegate the collision processing to their shapes.

[miss-mahou-shoujo]

Terasology

[immortius]

On Entity Systems

Currently I'm working on Terasology - an open source voxel engine with a focus on modability and graphics. My primary area is the core architecture and mod support. Central to both of these - the beating heart of Terasology - is an Entity System. I know there is a fair bit of interest in entity systems out there so I thought I'd take the opportunity to share some my experiences and learnings.

For this first post I will be covering in brief the reasoning behind using an entity system and what one is, and then in future posts I will delve into more specific topics. For further information I would recommend Richard Lord's What is an entity system and Why use an entity system articles, and T=Machine's blog.

What is an Entity System

To start off, an entity system is a composition based approach to describing game objects, as opposed to an inheritance based approach. When someone relatively comfortable with Object Oriented programming starts to write a game they generally begin with a GameObject class with some common behaviors. Then they create subclasses like "Monster" and "Door" with more specialized behaviors. This works fine until you need a door that is also a monster - it might sound trite but there are many aspects like whether a game object has a location, moves, is rendered, casts light, can take damage... and if you split this up across subclasses then you will end up in this situation. One approach is to lump all these common features down into the base GameObject - this works, but you end up with a gigantic class with all sorts of features and attributes, many of which you don't need for a given object.

Entity Systems on the other hand have Entities that are meaningless on their own but can be composed of Components. These components describe the behavior of the entity through the types of component (e.g. Location, Mesh, Physics) and the data they contain. Essentially each component correspond to a feature an entity can have as listed above. This way you can pick and choose which features each entity should have, and reuse features as desired.

Now at this point there are two approaches that can be taken. One is to put the logic that drives each component in the component class itself. This has the advantage of keeping the logic with the code - which sits with with the Object Oriented paradigm. However there are a number of disadvantages:

Components will need to access each other (e.g. a physics component will need to access the location component), and thus will need to know the entity they are on, which complicates the data model.

To call update() methods and send events to components, every component needs to be registered individually for these calls. This adds overhead to the instantiation and manipulation of entities and forces them to reside in memory so they can be hooked up.

There are some things that simply cannot be done through logic in components, such as physics updates (typically physics systems tick all objects together as collisions involve multiple objects)

Entity Systems take a different approach - they split out the logic into separate systems that work with all entities with a type of component or combination of components.  A rendering system for instance may render everything with a Location component and a Mesh component. It is these systems that receive update() calls and other events. By centralizing processing you can do things that are otherwise difficult, like batch rendering of every entity using the same shader and material, or physics processing. Your components also don't need to know which entity they belong to - the system knows which entity it is working on - which simplifies things. Since entities and components are pure data in this model they can be store out of memory and streamed into memory as necessary, which is great in low memory environments.

The entity system in Terasology follows this second model. This sits well with supporting mods, as a mod can introduce new systems that work on existing components. But more on that later.

One or Multiple of a Component

One decision that needs to be made early on when creating an entity system is whether an entity can have multiple of the same type of component or not. For instance, should it be possible for an entity to have multiple mesh components?

My opinion is you should stick to only one of a type of component per entity. For the majority of components, it doesn't make sense for a single entity to have multiple of a components - what does it mean to have multiple locations? To have multiple physics components?

For components where it makes sense that can be reflected in the component itself - have the mesh component contain a list of mesh to be rendered. Alternatively what you may actually want is a set of entities that reference each other - to have multiple mesh you could have a second entity that is "attached" to the main entity, perhaps through the location component, with the second mesh - then you can manage the offset of the second mesh through the location of the second entity.

[linuxgamenews]

Terasology - YAMC or not?

YAMC? Yet another Minecraft clone??? Well Terasology (previously called "Moving Blocks") sure looks like one:

Terasology alpha gameplay But besides looking like a pretty good YAMC, it actually promises to deviate from the boring Minecraft routine and mentions the pretty well liked games Dwarf Fortress and Dungeon Keeper as inspirations for its planned game-play :) Code is under the Apache license, however the current pixel textures are non-free. But if this takes off, those should be relatively easy to replace with really free ones ;) Oh and you can run it via Java directly from your browser (I had a black void as a world under Linux though... so your mileage might vary also). Posted by Julius

[gamesvideos]

Think of a game that's a mixture of Minecraft (I bet you hear this one a lot lately), Dwarf Fortress and Dungeon Keeper! Already excited? Meet Terasology a game that promises to bring all those three different experience in one game! The game is open source and you can download the latest build here!