PereGaea

Laslo Godel

4: MAPS

 

These new Locations are by default the same size as those of the largest Retinal Box, but if the eye rotates into a particular part of the Visual Field, they immediately take on the sizes of the Retinal Boxes that map onto it.

The Visual Processor may perform periodic `saccades' in which the eye is moved in random directions both to detect new objects and delete old ones from the Object RAM.

Let's begin our look at Testers by defining those objects that can be identified solely through ROM Templates as `ROM Objects', and generic ones that can only be Identified via Testers as `RAM Objects'.

 

1. A Facet is made up solely of Angles, Straights and Junctions with 3 Arms or more.

2. A Facet's angles may be of any size.

3. A Facet must share nothing more than two Junctions and a Straight with any adjacent facet.

4. A Facet must adjoin at least two other facets that are themselves mutually adjacent.

To look at the second major class of RAM Objects, let's suppose an object presents a set of Areals like this. To our eye this looks like a Faceted Object.

However, if we add a few more rectangular Areals to each side, and make them slightly thinner and darker as we go, we visually interpret the set in an entirely different way.

 

However, if the Areals are fainter and wider relative to the object's width, the object is perceived as being only gently curved and the `hidden half' assumption may no longer be made. If the proportions change at a varying rate, the curve is perceived to vary. And if the Areals actually reverse in tonal value in some parts of the set, we perceive the object to contain either concave elements or even as two adjacent cylinders.

 

1. A Contour Areal can contain only Straights, Arcs, or Angles, no Junctions.

2. A Contour Areal must be no more than one tonal value greater or lesser than its neighbor.

3. A Contour Areal can have no more than two Contour Areals as immediate neighbors. They can however join at a Junction with 3 or more Arms as in the vertex of a cylinder or cone.

4. A Contour Areal must be part of a set of at least three such Tones.

These Contours ought not be confused with the `contour lines' of our world. Those are essentially mathematical constructs we invented in order to describe the three dimensional shape of an object independent of the conditions under which it is observed. In short, Contour borders will move with a shift in illumination angle, Contour lines will not.

Most of PereGaea's RAM objects will of course have complex shapes. For instance if the Field of View is illuminated by a point source of light rather than a diffuse one, many objects will cast shadows on others. And perhaps most difficult of all, a few objects will change their shapes over time, sometimes quickly, as we'll assume the Fronds streaming away from the top of the Rockpile do.

 

To look now at how the Dynism might Identify RAM Objects containing both Facets and Contours, the Facet Tester will need to alter its first operational Rule so that it can accommodate `curved facets' that can contain Arcs as well as Straights.

RAM Objects with rough surfaces can only be Identified via the larger Areals and Lineals making them up; protrusions or depressions can be tolerated provided they are not so large as to intrude into them.

Indeed, Facet and Contour Testers need not evolve to test for pure `classical' volumes like cylinders, cones, spheres, boxes and pyramids, but what we would think of as more generalized versions of them. For instance, the Areals making up a cylinder or cone need not have perfectly straight sides. With the cone they need not even meet at a vertex; tending to be narrower at one end than the other is sufficient.

Much the same applies to Spheres. The Contour Testers for these will test for circles or arcs that have particular spatial relationships with each other. Again the limits can be fairly broad; they can be ovoidal rather than perfectly round and again have minor protrusions and depressions. The Rockpile Boulders will be picked up by these Testers; subtesters triggered by these will look for characteristic surface markings to identify them as Boulders rather than some other spherical object.

Like ROM Objects, partial occlusion will not prevent the Identification of RAM Objects..

Just as the Dynism can use Lineal Lists to reintegrate ROM Objects, it can do the same with RAM Objects that are visually divided by others.

Objects can also be visually divided either by a shadow from another object or a reflected color-cast. They may also be self-shadowing, or, as with the Moss on the Boulder, shadowed by the curvature of the object it sits on.

The Shadow Tester works similarly to the `Occlusion Tester' we've just seen except that the Areals of the two `segments' will differ at a constant rate. The distance between them will also always be zero.

We can now at last see how the Dynism might visually interpret the Fronds. Basically all it needs is very fast versions of the Contour Mappers we have just seen to cope with the Fronds' movement. The Dynism's Occlusion Testers would also need to operate quickly enough to determine which laterally-separated portions of crossed-over Fronds `belong' to each other.

The Tree in the Rockpile is the most obvious example of where such a capability would be useful. At this stage the Tree appears in the Dynism's Object RAM as countless thousands of Areals and Lineals deriving from what we would perceive as its Trunk, Branches, and Leaves. At this point we will assume that the Dynism has evolved a form of color vision, albeit rather primitive and cartoon-like.

Let's begin with the Branches. All PereGaea's branch systems, not just those of its Trees, share certain characteristics that will allow them to be identified as such, even though they can, like Rocks, take an infinitude of forms within those limits.

The one `distortion' these Testers cannot cope with however is a set of Contours indicating that a Branch is splitting into two, in other words, a Branch Junction like this.

A `Solid Junction Tester', similar to the Occlusion Tester we saw earlier, in effect joins any such set of mutually close branch `ends' it locates via a 3 x 3 Map Grid like this. The Tester may later acquire the ability to Identify the actual junction itself through the shape of its Areals and Lineals.

Variants of this Tester may also detect different types of Junction, such as those between smaller diameter branches and much larger ones or a tree trunk.

Further evolution of these Branch Testers link all these Junction Maps into a system of Branches, I will use simple symbols to represent these Maps.

You can see how this all works in this drawing where I've numbered each such Tracer `generation'. The Branch System Tester can then link the Junctions into a single `Branch System' and assign a Tree Branch System Number to it.

The Dynism eventually becomes able to use these Branch System Testers to Identify other kinds of Branch System, be it a Feather say, or a `Filigree' of some kind.

It does so by checking each Branch Junction Map to determine if it matches this `Category Map Template'. To Match, a Map can have any number of arms, but they must lie within the colored area.

If the system consists entirely of such `modules' - or at least some evolution-determined number of them, the Tester identifies it as a particular type of Branch System and attaches a specific RAM  Object Number to it accordingly. Here the dotted symbols represent optional Junction Maps.

Modules for Feathers for instance might be based on a much tighter four-way Junction Category plus two Branches with Ends. A variant of this may contain identical `submodules' that repeat themselves recursively an indefinite number of times. This would then allow fern-like systems to be identified.

A random Branch System like this on the other hand is clearly unlikely to have any RAM Object Number attached to it.

If a Branch System is visually divided by another object, then an Occlusion Tester can rejoin each Branch separately, and thereby the whole system. If the occluding object is too wide however for individual branches to be rejoined in this way, then those parts of the system thus `severed' will be Identified as separate Branch Systems.

More advanced Branch System Testers will be able to Identify and Number Branch Systems that are silhouetted against bright backgrounds, such conditions do not allow cylinder contours to be perceived.

The Trunk is simple; if the Branch System Tester locates a Branch containing stimuli representing an interface with the ground at one end and a splitting into two or more branches at the other, it attaches a Trunk Component Number to it.

Since most of a Tree's Leaves will be similar in size and shape, a set of ROM Templates from the Observational Spheres for just a few `sample' Leaves may well suffice for these.

To do this it acquires another Context Tester that checks that the Trunk does not deviate too far from the vertical. This uses the same grid as the Branch Mapper; the rotation angle must lie within the arrowed sectors.

Finally, a Tree Context Tester then tests the ends of all the branches for any adjacent leaf clumps, then for any clumps immediately adjacent to these, then any to these, and so on out to the Tree's boundaries. It samples each clump as it goes to ensure that the leaves making them up belong to the same species, and of course that of the Tree.

There is one last thing we must cover before we leave the Rockpile. Up until now we have assumed that all the simple RAM Objects the Dynism perceives have positive curvatures like the Rock and the Boulders. Objects can however have similar shapes but with negative curvatures: a Rock turns into a Cave, a Boulder into a Hollow. Some may contain elements of both like the Steps.

Most such `Negative Objects' will be identified through Maps just as Positive Objects are. To identify others however the Dynism may need to acquire a Tester that determines light-source direction so that the actual boundary between a Negative Object and the Positive Object that must inevitably contain it can be determined.