[CrystalSpace] #950: The warping transform of a portal should be relative to the origin of the coordinate system

#950: The warping transform of a portal should be relative to the origin of the
coordinate system
--------------------+-------------------------------------------------------
 Reporter:  kickvb  |       Owner:  jorrit
     Type:  defect  |      Status:  new   
 Priority:  major   |   Milestone:        
Component:  engine  |     Version:  V2.1  
 Keywords:          |  
--------------------+-------------------------------------------------------
 Instead, it is currently relative to the transform of the portal. This
 causes several problems, e.g. when the warping transform has a rotational
 component. In this case, many CS functionalities around portals will fail
 to work correctly. An example of such problems needing to be fixed is
 r36745.

 See the following mail sent by kickvb to jorrit and lulu:

 {{{
 * The iCamera::Move() method was not crossing correctly the portals
 because those portals have a rotation component in their warp transform.
 Apparently, this seems to be one of the first try to have a warping portal
 with a rotation component, and AFAICS there was a bug in it. See the next
 point for this bug.

 * The warp transform defined through iPortal::SetWarp() is relative to the
 transform of the portal (ie the position used in CreatePortal()), not to
 the origin of the coordinate system. This means that, before applying the
 warping transform to an object, you must first put the position of the
 object in the coordinate system of the portal (ie you must translate the
 object since CreatePortal can only have an offset component). And the
 actual warp transform to be applied is the result of GetWarp(), but
 actually put relatively to the origin of the coordinate system (so again,
 you must translate the warping transformation before applying it).

 You can see an example of that warping transformation to the changes I
 made in csSector::FollowSegment in r36745. This commit should have fixed
 the camera motion across a portal with a rotation component. The previous
 code wasn't working for that and I can hardly explain what this code was
 actually doing. This is also the case for
 iPortal::Warp/WarpSpace/ObjectToWorld... Jorrit, how well are you
 confident in those methods?

 * Another way to express that warp fact is: warp_transform is relative to
 the transform of the portal portal_transform, so the warp transform
 expressed relatively to the origin of the coordinate system is
 "warp_transform_absolute = portal_transform.GetInverse() * warp_transform
 * portal_transform". And that's the transform that can be applied directly
 to the position of an object expressed relatively to the origin of the
 coordinate system in order to apply the warp on it, ie "new_transform =
 old_transform * warp_transform_absolute"

 * This fact explains why the warping transforms of both portals in
 phystut2 are not the inverse one of the other: since the warp transform is
 relative to the position of the portal and each portal has a different
 position, then the warp transforms cannot be the same.

 * I think that this behavior of the warp transform is confusing, and that
 the transform should be defined relatively to the origin of the coordinate
 system instead of relatively to the portal. For example, one may want to
 move the position of a portal independantly to where the portal leads to,
 this is not possible currently without recomputing the warp transform.
 }}}

-- 
Ticket URL: <http://crystalspace3d.org/trac/CS/ticket/950>
CrystalSpace <http://www.crystalspace3d.org/>
Free open-source 3D SDK.
------------------------------------------------------------------------------
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d