Camera collision VS Portal cross check

Hi there,
I got one problem when my chase-camera's performing a raycast check.because of the collision check,the camera may not cross the portal,but directly be placed into the room. maybe like this:
t( chasing target)
| \
| \
| ncp (new camera position, after yaw around target)
|-----| ============wall(the left end is a portal)
|
ocp(old camera position)

therefore I have to set the camera node 's home zone to NULL every frame,to let the manager re-calculate it.Err..I thought it is not a good idea,so could someone geive some advice,thanks in advance.
bytheway ,i'm new here,so pardon that i don't know if there were already some posts talking about this.if there is,i'll really appreciate it if someone give me the link.

I'm not sure I follow your diagram but the solution I use for the chase cam is to run the ray in the physics engine rather than in Ogre. This way the camera collisions work against physics meshes/bodies instead of Ogre meshes.

-Fish

sorry I just found my ascii art is messed up.I'd preview it first.
it is a top view of the room or somthing.
| T
| | \
| | \
| | nc
|===|--------|====
| |
| oc

well, "|----------|"stands for a portal,while===means walls.
"T" is the chase target,"oc" is the old camera position in just last frame."nc" is the new posistion in this frame,it is decided by raycast check agianst walls.
so,in this situation,the camera are not cross the portal.
now i'm trying to build a movable entity from portal's coners,so that i could found it using raycast,and then make zone-change manually if needed.

Hey, you've just brought out a case that I've never really thought about before. But heck, my game might even have the same problem as described.

Anyways, I see two solution for this.
1. Make portal wider so it will not hit this problem.
2. When camera and target are in different zone, always do raycast to see if a portal is in between and is pointing towards target. If it is not, move camera to target's zone.

Hey, you've just brought out a case that I've never really thought about before. But heck, my game might even have the same problem as described.
....
thanks ,i prefer the second sulotion since for the first ,a large portal which is larger that the chase-camera distance is not what i want.anyway,that would be my choice.and thanks,Lf3THn4D.your idea is really great.

by the way,there's another issue: instance-jump( goto a position immediately and directly,ignoring any other things)
when doing this,i found the PCZManager's stuck in a dead recursion when it's deciding the camera node's(or the character's node) zone.
I thought this is because the character's jumping in a un-common way which is not "moving cross" portals,so it will jump through many portal ,
that is, the linear "moving track" of the jumping-origin and the jumping-target position,is crossing some protals.those are un-predictable.
so my hacking to this problem is to call the PCZSceneNode::_update() twice,manually, so that the position is updated.and set the node-homezone to NULL.
then no movement is detected,and the scenemanager will re-calculate the node's home zone.
I admit this kind of "jump" is weird ,but..it is a possibility in games,isn't it?
and I thought it is better to discuss problems with mroe experienced guys.

You're welcome. I actually had a better idea on the camera pass portal problem. Instead of doing raycast from camera to target, if we do it backwards, we will know exactly which zone to put camera in. This works even for when "teleporting" or initializing where we simply place our character in a particular spot in a given Zone. Chances are, if the position is near a portal, the camera would be in the wrong zone if it starts beyond the portal. So the reverse method will solve that. For optimal performance, i think we should instead do a hybrid solution. When "teleporting" or placing, do second method. When moving character around, do first method.

About your calling _update() twice manually thing, yes I'm doing about the same thing. What I do is call _update(true, true); then call needUpdate() which queues the node for another update. This is a rather old legacy code though. That reminds me that I actually did remember there's already a way to do it properly. You can try using savePrevPosition(). That should work I think.

You're welcome. I actually had a better idea on the camera pass portal problem. Instead of doing raycast from camera to target, if we do it backwards...
hey,thanks for your advice.but actually,I was using the character-to-camera raycast! .and I thought I could solve the problem soon.but recently I'm focused on other things.so this would be handled a few days later.and I'll be here if other problems are encountered.thank you again,pal.