Page 1 of 2

Camera Areas

PostPosted: Wed Jan 09, 2008 6:59 pm
by andylegate
Got a question here about using Camera Regions.

Can you use a Camera to follow the avatar in 3rd person for like when they are walking through a tunnel, to keep the camera view inside the tunnel?

Reason I ask is that I noticed that if I'm in 3rd person view (which I hate) and am close to a wall, the camera will go outside the wall, like if I go to use my relto book. Will putting in a Camera region keep that from happening?

Re: Camera Areas

PostPosted: Wed Jan 09, 2008 7:14 pm
by Lontahv
Yes you can! If you look in "Scripts" in blender and then take a look through the menus until you find something like "assign default col settings" and that should give the col_type and a few other camera no-go-though things. :)

Re: Camera Areas

PostPosted: Wed Jan 09, 2008 7:25 pm
by Nadnerb
The default 3rd person (avatar camera) will move closer to your avatar when a solid object obstructs it's view. If this is not happening for you, then you are already using an avatar camera region as I describe below, and have encountered one of the problems with the pyprp defaults.

If you're not using an avatar camera region, they are the kind of region that actually sets up your default camera view. I recently set up one of these regions, in fact, in my tunnel age, to keep the camera from bumping up against the ceiling all the time.

To do this, create a camera activator region and tie it to a camera. The camera is where all the settings are, but in this case it doesn't matter where you put the actual camera object in blender. For the camera, give it the properties:
Code: Select all
string   cambrain   avatar
float   AvCam_X      0
float   AvCam_Y    6
float   AvCam_Z    6

The camera will always look at your avatar's head (unless you change the POA) and it will be fixed 0 units left, 6 units behind, and 6 units above your avatar's feet. (putting it about six feet behind, and level with, your avatar's head) (The default camera is about 12ft above and behind your avatar's feet)

Currently there is a slight problem with using this type of camera region. The camera will not smoothly animate but will be firmly planted behind your avatar, and it will ignore collision with walls. I had to fix this by modifying my copy of pyprp to export the CameraBrain with different flags, (0x00000420) but I've talked to Trylon, and this should be the default in the upcoming plugin release. (as well as allowing you to actually change these flags from the blender interface)

If you don't want to wait until the new version is released, you can use the bit of the stable version which I modified.
alc_Classes.zip
(45.01 KiB) Downloaded 370 times

Also, looking over your post,
the camera will go outside the wall, like if I go to use my relto book.

What on earth do you mean by that? :|

Will putting in a Camera region keep that from happening?

No. A camera region does not keep the camera from leaving the region itself, it is a detector region that sets the camera type when your avatar enters it. It is possible, however, to add geometry that is not visible, but will affect the camera if it comes between it and your avatar. It is worth noting, however, that this behavior is not perfect, and the camera will occasionally clip the edges of a wall/collider, allowing you to see the other side for a second if the collider is drawable.

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 6:41 am
by andylegate
Cool! Thanks for the info.

No, I wasn't using a region already. But last night I tried to do one quickly, a Avatar Cam.......when I tested it, I got a good close up of my butt!! hehehe....that's when I knew it was time to go to bed! hehehehe

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 10:14 am
by D'Lanor
A camera region is a rather elaborate way to fix this. Nadnerb and Lontahv I believe hinted at the default method for this: Simply set a Camera Avoid Flag on your wall object. Setting that flag should probably become an age builder's standard routine for any wall type object.

I would suggest to try this first and if it does not satisfy your needs you can still use the other method.

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 10:34 am
by Nadnerb
Ah, well, I'll admit I made a few assumptions here, such as assuming that your tunnel walls and floor were the same object, and that you had already set the col_flags5 value (0x00000044) which disables friction and sets camera avoidance, which is what I always do upon creating an object intended to be walked on... and forgotten that wasn't the default. :P

Edit: scratch that, camera avoidance is the default for all objects with col_type 4, at least for the plugin version I'm using. ("stable version")

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 10:47 am
by andylegate
You know, that's a good point to bring up. Setting the col_flags5 on walls.
That's not something I normally would do as........well I'm sorry we don't normally try to walk on walls! :D

So all of my walls only have the col_type setting simply to make them solid. Only where you walk did I put col_flags5 in.

So! I will try that first. But it is fun to experiment with the Camera regions as I'm still learning. Never know when I might need ti later.

D'Lanor - Thanks for including that Link. It's high time I went back and reread this tutorial!! I think I'll grab a sandwich and read!


:D Sorry, but I'm in a GREAT mood today, don't know why, but I'm just feeling great today..........

-----something bad must be getting ready to happen. Such is my life! ROFL!

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 11:02 am
by D'Lanor
Hehe, thanks to my own link I noticed that there also is a kCameraAvoidObject flag. After setting that my walls seem to avoid peaking through even better. 8-) (Or maybe I am just imagining that...)

My test age was created back in 2005 when you basically had to set every flag manually. However, if camera avoidance is the default setting now wouldn't that cause unwanted camera swoops around objects which are not meant to be walls?

Re: Camera Areas

PostPosted: Thu Jan 10, 2008 11:17 pm
by Chacal
Correct me if I'm wrong, but setting colision or camera avoid on a complex object can mean a performance hit because of the complex calculations it entails. Every time you move or the camera moves, the game client must determine if there's a collision or not. This must be kept as simple as possible.

Cyan uses very simple, low-poly colliders for both, and never uses the visible models for it, except in very few places like Relto. Cyan also uses camera regions intensively.

I'd go with what Cyan does.

Re: Camera Areas

PostPosted: Fri Jan 11, 2008 10:03 am
by andylegate
Hmmm.....well I did it for my visable objects, and there was no drop in performance (and my machine is anything BUT highend! hehe).
But then again, the Age is not as big as Cyan's ages, and I only used it on certain places where the problem with the camera straying outside the wall is possible (no reason to put it on the bushes, or pool, etc.).

But yah, I guess that would be something to keep in mind.