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…)