## Collision
The Zone definition contains a list of collision objects. Collision objects are tuples of:
 1. A triangle mesh (which includes normals)
 2. Transformation-information

The triangle mesh is defined in "object space", and is (potentially) re-used for multiple collision objects.
The transformation-information contains the transforms to convert between object-space & world-space.

With respect to collision detection/resolution, I think the most accurate & efficient method involves:
 1. Transforming the actor's collision into object-space
 2. Determining the proper resolution in object-space
 3. Transforming the resolution into world-space, and applying the resolution to the actor

However, the transforms make this difficult, because they can involve skewing & mirroring operations.
That is, a capsule or sphere in world-space could be arbitrarily deformed in object space. An oriented-bounding-box would work,
but bounding-box collision-resolution comes with its own set of complications.

The current implementation just transforms each collision-object into world-space by applying the world-space transform.
Re-orienting the triangles could reverse their winding, so this is detected & fixed as well.

### Interesting Collision Locations
1. The one-way door in [Pso'xja] @ Vector3f(x=-339.87f,y=0.00f,z=310.41f)
2. The tight torch area in [Castle Oztroja] @ Vector3f(x=-142.37f,y=-2.04f,z=-19.04f) (and the weird slope just before it)
3. The fountain in [Metalworks]
4. The airship OOB
5. The 0.5f step in [Northern San d'Oria] near the fountain
6. The steep stairs in [Beaucedine Glacier], near the entrances to [Pso'xja]
7. [Selbina] in general (sloped stairs, sloped cliff faces, the weird hit-walls on the stairs near the ferry...)
8. The steep slope in [Uleguerand Range]
9. The vegetable collision in [Rabao]

## TextureName
The outpost in Yuhtunga has lights with a weird configuration:
* Configured to use:     [effect  light   ]
* But actually resolves: [fire2   light   ]

Experimentation shows that changing [effect  ] or [fire2   ] doesn't impact the texture resolver, but changing [light   ] does.

## Sec 0x48
The "distance" calculation takes scale.x as a factor (at least for zone particles)
This is necessary in [Western Sarutabaruta], or else the ocean is weirdly visible from the twinkle tree
The factor is linear, but not 1:1 - 1.15f was determined by observing the output of the distance calculation:

 s.x     distance
 ---     --------
   0 ->  541.63
   1 ->  542.766
   2 ->  543.922
   3 ->  545.068
   4 ->  546.215
   5 ->  547.361
  10 ->  553
 100 ->  656.246
 200 ->  770.862
 300 ->  885.478
 400 -> 1000.09

Verified that:
* s.y and s.z have no effect
* r.y has no effect
* modifying the params of 0x48 has no effect

## Sec 0x30
Sec 0x30 seems to scale for Zone/Weather particles (but not really for actor particles...?)

Clouds and such have massive positive values. Even though they're far away, they still get clipped in some zones.
Clamping at +0f doesn't seem to cause any issues.

In general, it seems like particles should have a bit of bias, or else there's massive z-fighting for decals.

Cave-transition particles in Valkurm use large~ish negative values (-20f). Render flag 0x0800 disables the effect,
so 0x30 seems to do nothing? But it does still need bias, or else the transition particle has massive z-fighting.

Also, giving render flag 0x0400 a bit of bias helps for some cases (?). However, setting it too high breaks effects
like the water in [Metalworks] (appears outside of the fountain).

Some rough measurements of WorldView's position.z vs projection bias (* -1 to both).
Took a few different values, and it seems that the bias halves every ~5 world-space units.

 3.0472, 22.3279
 4.2507, 19.6689
 5.6764, 16.8042
 6.8964, 14.5872
 8.3092, 12.2759
 9.5232, 10.4982
11.1311,  8.4222
12.3575,  7.0395
13.7951,  5.6245
15.3979,  4.2901
17.0239,  3.1756
18.8623,  2.1764
20.6834,  1.4272
22.5043,  0.8842
24.3310,  0.5132
26.3815,  0.2627
28.6152,  0.1358
30.8782,  0.1016
33.3294,  0.1003

## ParserContext - color scaling factor
While _parsing_ [0x1F], the color vertex attributes are doubled _only if_ the file corresponds to an area (or sub-area).

Verified this by verifying the in-memory values for a [0x1F] resource when:
* Copied to an area file (Selbina, etc)
* Copied to a sub-area file (mayor's room in Selbina, etc)
* Copied to a spell file (doesn't double)
* Copied to equipment file (doesn't double)
* etc

Also verified that it's not checking the root directory name (ex: [t_se]). The doubling happens even when arbitrary values are used.

In particular, this is necessary for Manaclipper's ocean, dolphins, etc

## Sec2 0x45

Considerations:
 Sec2-0x3C, Sec2-0x44, Sec4-0x01 are just snapshots (binds, but then doesn't follow, even if configured to follow)
 Sec2-0x53, Sec2-0x6A have special logic to manage child positions due to billboarding effects

EffectRoutine-0x3F is the only parent/child exception, which doesn't strictly snapshot (as long as follow is configured).

Some interesting examples:
* [Jubaku: Ichi] has a chain of "Base->Complex->Simple"
* [Drain] is a good example of a child whose parent has a complex attachment type (TargetSourceBasis)
* The footsteps in [Hall of the Gods] are good for verifying snapshot behavior
* The gift-box in [Air Rider] is a good example of EffectRoutine-0x3F chaining (with base-position inheritance)
* [Air Spirit] is a good example for EffectRoutine-0x3F chaining (with follow enabled)
* [Meifu Goma] is a good example for a particle that uses the Sec3 position-setters on child particles
* [Shell IV], [Shell V], [Fowl Aubade], [Enchanting Etude], etc

Side notes:
* 0x9B is an interesting alternative, which definitely does not modify the attachment (ex: [Borealis][caf0])
 * Switching this to 0x45 nicely demonstrates the change-of-basis behavior to [SourceActorWeapon], producing the wrong effect

Newer notes:
* [Wild Carrot] was an interesting example for Sec2-0x3C.
 * I think the only way for this to work is if the child particle links directly to the parent's generator
 * This doesn't work for EffectRoutine-0x3F, but might be a better way to model Sec2-0x44 and Sec4-0x01.

## Batched Particles
Generators with batching enabled have weird behavior.

* Various op-codes and flags are completely ignored
* Initial position calculations are different
* The batch-position is somewhat view oriented, even when no such flags are enabled

The vertex data itself is pre-multiplied with the model & view matrix - only the projection matrix is provided to D3D.
I wonder if it's just a buggy re-implementation for the CPU side calculation?