Hi again. As promised elsewhere, here's a rambling thread regarding event propogation, filtering and attenuation concepts for my 'Primogen' library. Comments and critique welcome. I'll be updating this post over the next couple of days with information on how sensors and attenuation of events are planned to work. This post is the first part, dealing with event propogation through the Neigbourhood system. This relies on the relevance graph concept as detailed in
this thread as a coarse spatial interest filter, and for noting where cross-server boundaries are in the propogation routes. Current concept for operation is as follows: Events are generated by 'Effectors' and are handled by 'Sensors' of various types. Sensors are basically subscribers to a particular event type. Events have a cycling sequence number paired with a unique ID for the POR they originated in. Events can therefore be guaranteed to be singular in queues (no duplicate entries). Sensors for event types have an effective range, and are 'limpet-like' additions to a POR's internal heirarchy. A sensor's entire range need not be confined to the physical constraint of the POR, instead, for each event type a secondary AABB is maintained and updated for PORs dictating aggregate sensory AABB for that type. It is entirely possible that for certain event types, the aggregate sensory AABB is only a tiny subset of the physical AABB of the POR. All simple enough so far, here's a diagram:

Here we have a simple world, divided into 4 PORs, which are children of two divisive PORs, POR_EAST and POR_WEST. POR_NW and POR_NE are assigned as explicit neighbours, as are POR_SW and SE. Events propogate through the POR heirarchy before being handled as follows:
1) Synchronisation Step: All servers wait for a signal from the master server to continue.
2) Explicit neighbourhood pass: Starting at the root POR for each server domain, PORs are dealt with leafward. Each POR maintains a short list of neighbouring PORs. Each of these is a potential recipient candidate for events occuring in the subject POR. A POR can specify not to send events of certain types to certain neighbours. By default, all events are passed. Each candidate's aggregate sensory AABB for the relevant event type is checked against the spatial footprint of the event. If overlap occurs, the event is queued for handling in the candidate POR, if it is of an allowed type. The flow looks something like this:
3) Synchronisation Step: All servers signal master server when they have finished passing events, including receipt of acknowledgement for boundary-crossing events. All servers signal master server when they have processed boundary-crossing event messages. All servers wait for a signal from the master server to continue.
4) Implicit neighbourhood pass 1 - rootward pass: On each server, starting at the server domain root POR, PORs are examined leafward. Within each POR, for each event, the event is passed rootward to the first spatial divisive POR (non-physical) that contains the spatial footprint of the event in its entirity. Spatial divisive PORs cannot by design overlap spatially at any particular heirarchical level, making them ideal tools for spatial division, hence the name. Passes cannot be made if an explicit neighbourhood link exists, since if the event is allowed by the link it will already have been handled, and if it isn't then it shouldn't be handled. If the server domain root POR does not contain the event footprint, the event is placed in the event queue for the domain root POR before it is passed across the server boundary. The interface for a cross-server boundary link acts to all intents and purposes as the POR at the other end, containing event identifiers to prevent back-propogation.
4) Synchronisation Step: All servers signal master server when they have finished passing events, including receipt of acknowledgement for boundary-crossing events. All servers signal master server when they have processed boundary-crossing event messages. All servers wait for a signal from the master server to continue.
5) Implicit neighbourhood pass 2 - leafward pass: Next, within each server domain, event processing begins again at the domain root and progresses leafward. Events queued for in each POR are despatched downward. Within each POR the process for each event queued is as follows: First, the event footprint is checked vs. aggregate sensory AABB for the appropriate type for each child POR. If there is a collision, the event is placed into the downward queue for that POR. Child PORs have implied neighbourhood by containment and so receive all colliding events by default. To prohibit passing events of a certain type, explicit neighbourhood with appropriate criteria must be specified.
6) Synchronisation Step: All servers signal master server when they have finished passing events, including receipt of acknowledgment for boundary-crossing events. All servers signal master server when they have processed boundary-crossing event messages. All servers wait for a signal from the master server to continue. Okay, so the events have propogated through to appropriate PORs. Now the task is to determine which Sensors within the POR are affected by the event. This is for the most part a simple matter of comparing range of Effector and Sensor, against the sum of sensory radius and event radius:

This works well enough, but is static in terms of effect attenuation - someone effectively has the same range of vision in a foggy area as a clear one (as far as simulation is concerned). This is not the case as far as rendering or the real world are concerned (fog may cause culling of distant objects, or if a sufficient bulk of volumetric fog exists it may act as an occluder) and provide an opportunity for packet sniffers to be used to effectively remove such sensory limits. The solution proposed is as follows. A POR may register event attenuator field objects. These are areas (spherical or AABB), within which both event and sensory ranges are attenuated. Such attenuators would generally be used to model the overriding of small effects by fixed large ones - for example a very noisy piece of machinery would attenuate auditory range nearby, a very smelly item would attenuate smelling range, etc. etc. These are physical effects, and therefore exist spatially within a physical POR. Attenuator fields operate much like Effectors, with a given radius, but also have a strength scalar per range unit to determine their effectiveness.

Rather than simply comparing ranges for sensory collision with events, a slightly more complex process must now be performed. First a ray is cast between Effector and Sensor. This vector's magnitude gives range for comparison. If the test fails, the sensor cannot receive the effect. This is an 'early-out' and may be optionally skipped. Next, the POR is checked to see if any attenuators exist for the appropriate event type. If so, a potential attenuators list is built, and checked in order of range from the effector. Entry and exit positions into the attenuator field are calculated, and used to determine magnitude of attenuation, in conjuction with the attenuator field's strength. The attenuation is applied to the range between Effector and Sensor.

This system is collision detection heavy, and therefore relies on good math and physics libraries. The use of an octree within PORs to assist in potential collider culling is probably going to be required. Whilst I think this system can work effectively, I am slightly concerned that it is CPU intensive, especially if there are large numbers of attenuators and events. The principle of negative attenuation (for building echoing corridors etc) is one I am also looking at. Comments, suggestions and opinions welcome, as ever. Diagrams will be added soon.
[Edited by - _winterdyne_ on November 21, 2005 3:27:32 PM]