Building is the Pits
Trying to scoffold an activity so it fits into a short term means that certain details must be surfaced, processes prepared and scaffolds erected. The “builders academy” is a summary of the tutorial zone on planet Obscura and focusses on skills particular to this building task:
I made a machinema demonstrating techniques, and talking them through more regular tidy building practises, in the hope that if they do not want to read the worded instructions, they might take notice of a human voice modelling what they have to do. I am getting quite good at “multi-modal” explanations, and this is something that Virtual Worlds are particularly good for.
The idea is that cybernauts model, in 3D the readings they have taken in the field. The modelling then creates a 3D representation of the ore body in situ so they can then decide, based on researched costs and benefits, the most appropriate way to extract the ore.
We present them with a “builders pallette” of the objects they need to complete the build – in this instance they are semi-transparent blocks that stack neatly, each representing different mineralisation readings. You can also see in the pit there is a starter grid, centred on the ore body, so they can start building from there without having to worry about aligning, scale and have an idea of extent and scope. Each pit has a “spoils” area to one side, so that later when they are demonstrating the mining technique they have selected, tehr eis somewhere to put their mined waste – again a nice demonstration of the fact that the stuff you dig up and discard has to go somewhere.
Most 3D worlds have limits, Activeworlds more than most in some regards, but I learned some valuable lessons in highly intensive, densely packed object arrays by trying to complete the activity we are asking the cybernauts to do, myself.
There is this thing called a “cell limit”, it is a PHYSICAL MEMORY limit the world, and I am guessing the rendering engine have whereby the total assets for a grid cell are limited. Each object instance, the NAME of the object, any ACTION scripting applied and any DESCRIPTION add to the storage requirements for that object. In the above screenshot you can see a rather sparse area of the world and a highlighted object alerts us to the fact that we have consumed 52% of the cell limit in that cell (you can see the cell grid in green and the current cell in red). This large cell usage can be explained when you realise there are 135 objects in that cell, most with HUGE names, most with create scripts etc.
This became a critical problem when I was testing the pit construction. Originally I had the blocks with lovely long names, and create scripts and a lovely long description in each – this meant that when I was 2/3 of the way through the building of my model, the WORLD prevented me from building any more in that cell … oops.
The solution was a re-making of ALL blocks (I changed the actual objects to be coloured and transparent in my 3D modelling program rather than do it with scripts in-world), gave them all tiny names (m1 .. m7) and pruned their descriptions down. the upshot of this is that I realise the object catalog that exists currently contains some obscenely wasteful object data – sure the names are descriptive but …
I like it that I am still learning in this project.
