what's the difference between INTERSECT and CROSS?

hi,Chaster, excuse me for boring...i have read the source code but still be confusing, there are some other questions:
1.in traditional bsp scene, every zone has its definite space and there's no overlap in each other, but in pcz scene, it seems that the pcz zone doesn't have one? then how do we determine the "homezone" of a node?
2.in my option i only understand the "quad" portal, which is like the window or door in realife. but what 's the "AABB" portal stands for? is it the group of 6 quad portals?
3.in source OgrePortal.cpp line 737, the comment said "for aabb's we check if the center point went from being inside to being outside the aabb (or vice versa) for crossing. ", but the code below is:

//if (previousInside == false &&
if (currentInside == true)
{
return Portal::INTERSECT_CROSS;
}
why the first if stmt is commented?

i could hardly understand the code below...
why can we consider they are INTERSECT_CROSS when the node is in the box and the box's normal is outward pointing? is the "outward pointing" stands for the box is a entry to the outter space?

else if (mType == PORTAL_TYPE_AABB)
{
// for aabb's we check if the center point went from being inside to being outside
// the aabb (or vice versa) for crossing.
AxisAlignedBox aabb;
aabb.setExtents(mDerivedCorners[0], mDerivedCorners[1]);
//bool previousInside = aabb.contains(pczsn->getPrevPosition());
bool currentInside = aabb.contains(pczsn->_getDerivedPosition());
if (mDirection == Vector3::UNIT_Z)
{
// portal norm is "outward" pointing, look for going from outside to inside
//if (previousInside == false &&
if (currentInside == true)
{
return Portal::INTERSECT_CROSS;
}
}
else
{
// portal norm is "inward" pointing, look for going from inside to outside
//if (previousInside == true &&
if (currentInside == false)
{
return Portal::INTERSECT_CROSS;
}
}
// doesn't cross, but might be touching. This is a little tricky because we only
// care if the node aab is NOT fully contained in the portal aabb because we consider
// the surface of the portal aabb the actual 'portal'. First, check to see if the
// aab of the node intersects the aabb portal
if (aabb.intersects(pczsn->_getWorldAABB()))
{
// now check if the intersection between the two is not the same as the
// full node aabb, if so, then this means that the node is not fully "contained"
// which is what we are looking for.
AxisAlignedBox overlap = aabb.intersection(pczsn->_getWorldAABB());
if (overlap != pczsn->_getWorldAABB())
{
return Portal::INTERSECT_NO_CROSS;
}
}
return Portal::NO_INTERSECT;
}

hi,Chaster, excuse me for boring...i have read the source code but still be confusing, there are some other questions:
1.in traditional bsp scene, every zone has its definite space and there's no overlap in each other, but in pcz scene, it seems that the pcz zone doesn't have one? then how do we determine the "homezone" of a node?

You need to know this (or figure it out using a bounding volume method for example) when the node is first added to the scene.


2.in my option i only understand the "quad" portal, which is like the window or door in realife. but what 's the "AABB" portal stands for? is it the group of 6 quad portals?

An AABB portal is an axis-aligned bounding box portal. Note that this is a special case box (i.e. it's axis aligned). It's not the same as 6 quad portals.


3.in source OgrePortal.cpp line 737, the comment said "for aabb's we check if the center point went from being inside to being outside the aabb (or vice versa) for crossing. ", but the code below is:

//if (previousInside == false &&
if (currentInside == true)
{
return Portal::INTERSECT_CROSS;
}
why the first if stmt is commented?

Your codebase doesn't seem to be up to date. This code no longer exists in OgrePortal.cpp

Keep in mind that the AABB and Sphere Portals are different from the Quad portals because they are volumetric as opposed to planar. If the "norm" of an AABB portal is pointing "out" (there is only "in" and "out" for AABB and sphere portals because they are volumes instead of planes) then if an arbitrary node is inside the AABB (or sphere), you know that it crossed over the portal.

Chaster

thanks chaster...i have been wating for a long time...
i'll download the lastest code as soon as i arrive home, but before that i'd like to ask 2 questions:

1.why can we consider the relationship between a AABB portal and a node is CROSS when the normal of the portal is inward pointing and the node's center is outside the portal's AABB? shouldn't we check there's any collision between the node's AABB and the portal's?

2.why can we consider a node belongs to a zone when the node has none CROSSING against all the portals of the zone? if the node is very far away from the zone, it may not cross any protal of the zone, but will it belongs to the zone??

hi,chaster,i have downloaded the latest source from svn, the code i list above isn't changed but only moved to OgrePortalBase.cpp.
i'm curious why it's true:"for aabb's we check if the center point went from being inside to being outside the aabb (or vice versa) for crossing. "
should not the crossing be concluded by checking if there's collision between the AABB of both?
but the real code gives a more confusing result: it only check the current position without conforming to the comment above..
i'm fully at sea...

Sorry for the hideously slow response (I am unable to check the forums much nowadays since I have so much going on with my own work, and PCZSM is very, very low on my priority queue)..

AABB's are volumetric, therefore, there is no clear "cross over" point like there is for planar quads crossing over each other. So, if a AABB portal goes outside (when it was previously inside) then it is assumed to be "crossed over" (and vice versa).

Chaster

hi,chaster,i have downloaded the latest source from svn, the code i list above isn't changed but only moved to OgrePortalBase.cpp.
i'm curious why it's true:"for aabb's we check if the center point went from being inside to being outside the aabb (or vice versa) for crossing. "
should not the crossing be concluded by checking if there's collision between the AABB of both?
but the real code gives a more confusing result: it only check the current position without conforming to the comment above..
i'm fully at sea...