Tileable Models

Here is a proposal for a powerful mechanism which I think will allow is to do neat dynamic things without having to add lots of special case code, scripts or data to the client.

Everyone who works with graphics should be familiar with the concept of tiles images or textures where the same image is repeated in order to cover an area large than the original image.

The concept of tiled models aims to do something similar, but by rendering multiple instances of a 3D model adjacent to each other to represent a larger entity. There are a few example cases to which this could be applied, both existing and new.

The first, already fairly familar example is the jetty currently included in the default map, just down the hill from the pig sty. Multiple instances of a similar model to that currently used could be rendered adjacent to each other to form a larger jetty. Allowing this to be specified as a single entity would reduce the network and memory cost of these multiple instances, and reduce any problems with vertical alignment due to variation of the terrain.

The second example might be a long wall or fence which could be made up of multiple instances of the same model. Here it might be more desirable to adjust the height of each instance to the terrain, requiring a more expressive specification.

The third example, which is my main inspiration for the mechanism is to allow the fast efficient representation and rendering of scaffolding used to create large constructions. Scaffolding could be represented as a cuboid shaped model representing a section of scaffolding which could be then rendered many times adjacently in three dimensions allowing arbitrary cuboid shapes of scaffolding to be represented with the minimum of ugly scaling issues.

Existing clients already have mechanisms to scale models to the size of a bounding region specified by the server. This proposal would extend this behavior to include the possibility of scaling the model so that it will fit multiple times into the bounding box, and then rendering it multiple times within the box.

As a starting point for discussion, I describe below some entities in JSON which specify object tiling using a property called “tile”, which gives three integer values, being the number of instances required in each of the three dimensions.

A jetty represented by a model 3m x 3m x 1m high. The jetty is 9m long, and requires three tiled instances of the model to render correctly.

{
“parents”: [ "jetty" ],
“bbox”: [ 9, 3, 1 ],
“tile”: [ 3, 1, 1 ]
}

A block of scaffolding 5m x 10m x 5m high, represented by a 1m cube model.

{
“parents”: [ "scaffold" ],
“bbox”: [ 5, 10, 5 ],
“tile”: [ 5, 10, 5 ]
}

Comments and extended proposals please. If we get to a rough base spec quickly, I can implement some test entities on the server, and we can get testing. Refining the spec can come later, in keeping with fast and loose development methodology.

This entry was posted in Software. Bookmark the permalink.

2 Responses to Tileable Models

  1. erik says:

    This is something I want to pursue also. Jayr have already provided updated meshes for the fence sections (in 3d_objects/items/building_element/models/wooden_fence), but we’ve yet to use them. Ogre already have excellent support for “geometry baking”, where you take a tree of scene nodes and let Ogre automatically bake it into a new static mesh. That would be perfect for this. I think it wouldn’t be that hard to add support for tileable meshes to Ember, the Model format is already quite extensible and all the support in the graphics engine is in place.

    I’ve been thinking about how to best represent the fence case, since as you said it’s not really suited for the tileable approach. The way I think we should do that is to add an “composite” attribute to certain “container” entities. These entities do not have any physical models themselves, but have one or many subentities (in the fence case that would be the fence sections and fence poles). What makes this configuration different is that:
    1) the individual bounding boxes of the subentities aren’t taken into account when determining visibility, only the bounding box of the main container. This is important since it’s expensive to regenerate the static mesh, so once you see a part of it, you see it all. This also means that we need some kind of mechanism in the client-server communications where we’re guaranteed that all subentities are transmitted before the container entity is transmitted
    2) we make a promise that the entities won’t be changed too often. While the static mesh can be regenerated, it’s expensive and we want to avoid that.

    Anyways, I’ll gladly add some support for the tileable approach (as well as the composition approach) to Ember. Currently I’m trying to get it compiled for win32, and I won’t do anything until that’s taken care of (I’ve promised and all…)

  2. alriddoch says:

    This discussion has been continued on the WorldForge general mailing list, here: http://mail.worldforge.org/pipermail/general/2008-January/005466.html