Camera not facing where it should

[Kexikus 995]

So, I'm currently trying to rotate two cameras. I never had problems with that but these two just don't do what I want them to do.

 

I got the rotation by using an orientation armband which gave me an orientation of about 180° and thus quaternions of approximately -1 and 0. But when I enter those, the camera will face in the direction of what would be 270°. It's not an issue with the armband though, as using that to get the rotation for some waypoints worked perfectly fine. So I tried to enter the quaternions for 90° (0 and 1) which should result in the desired 180° if the camera is rotated by another 90° as it seemed. But that worked perfectly, the camera was rotated just as it should be.

 

Now I'm really out of ideas on what could be going on here. The cameras just don't do what they're told. Any ideas on why that could be?

[JCarter426 1,215]

First, what sort of cameras? Static ones in the GIT file?

 

Second, the orientation in the game isn't consistent. Some modules have 0° as north, some don't. So you might just be in one of those modules.

[Kexikus 995]

Yeah, it's a static camera in the .git.

 

And the problem is not where 0° is facing. As I said, I got the rotation from the orientation armband, so I know that I want 180°. The problem is that for some reason 90° and 180° face in opposite directions and that makes no sense at all.

camera.zip

[Sith Holocron 2,478]

Could you tell us which module you're referring to?

[Kexikus 995]

The module is tat_m17ab, the Tatooine docking area.

 

I've attached the files to this post in case anyone wants to have a look. You need the three .utcs and the .git. You can then load the provided savegame (I hope it won't crash) and if you leave the Ebon Hawk with Juhani in your party (she won't have a portrait but is selectable), you should get the second Xor encounter after you talk to the customs officer.

 

The cameras in question are the first two cameras in that scene with the ID 444 and 445. In the provided .git they should face Xor and his lackeys (direction of 180°), but instead they face the underside of the Ebon Hawk. I also added a file called m17ab_90.git where I changed the orientation of the 444 camera to 90°. That one works fine and faces straight away from the Ebon Hawk.

 

camera.zip

 

Any help with this would be really appreciated. Thanks.

[JCarter426 1,215]

Yeah, it's a static camera in the .git.

 

There are approximately zero reasons to use those, but ok.

 

And the problem is not where 0° is facing. As I said, I got the rotation from the orientation armband, so I know that I want 180°. The problem is that for some reason 90° and 180° face in opposite directions and that makes no sense at all.

The module is tat_m17ab, the Tatooine docking area.

[...]

The cameras in question are the first two cameras in that scene with the ID 444 and 445. In the provided .git they should face Xor and his lackeys (direction of 180°), but instead they face the underside of the Ebon Hawk. I also added a file called m17ab_90.git where I changed the orientation of the 444 camera to 90°. That one works fine and faces straight away from the Ebon Hawk.

 

Well, you're right - it does look like you want 180°. I've attached an animated camera that confirms this, though it's not going to tell you anything you don't already know.

 

I don't know what to say other than that BioWare wasn't at all consistent with orientation. 90° being south is typical of some other modules, such as m01aa. It's probably just a quirk of that area. Though it is weird that only the static cameras would be incorrect, that wouldn't be the most shocking oddity with this game.

Camera Rotation Test (m17ab).zip

[Kexikus 995]

There are approximately zero reasons to use those, but ok.

 

Well, in my case there actually is a reason for that. The cameras are used in the Xor cutscene that's present across three different modules and each of them uses static cameras with the same IDs. I only edited that one instance and I'd rather not make it a special case by using animated cameras and thus requiring a unique dlg and thus requiring a unique trigger script.

 

But you say that in a way that leads me to believe that it's always better to use animated cameras. Would you mind clarifying why that is? I always though that they'd be much more work.

 

Well, you're right - it does look like you want 180°. I've attached an animated camera that confirms this, though it's not going to tell you anything you don't already know.

 

I don't know what to say other than that BioWare wasn't at all consistent with orientation. 90° being south is typical of some other modules, such as m01aa. It's probably just a quirk of that area. Though it is weird that only the static cameras would be incorrect, that wouldn't be the most shocking oddity with this game.

 

Yeah, waypoints work as well. I'll check the other static cameras in the area. Maybe I can find a reason for what's going on.

[JCarter426 1,215]

Well, in my case there actually is a reason for that. The cameras are used in the Xor cutscene that's present across three different modules and each of them uses static cameras with the same IDs. I only edited that one instance and I'd rather not make it a special case by using animated cameras and thus requiring a unique dlg and thus requiring a unique trigger script.

Oh, that does make sense. That's a strange way to go about it, but I can see why they would do that.

 

You could still do it all in the same dialogue without requiring a new trigger, but it might end up being more work so it might not be worth it.

 

But you say that in a way that leads me to believe that it's always better to use animated cameras. Would you mind clarifying why that is? I always though that they'd be much more work.

Static cameras:

a ) are required to be placed in a module's GIT file, which means they can't be placed after you've entered the module and make for a compatibility nightmare

b ) use the obscure quaternion rotation system

c ) are restricted to a single module

d ) can't be animated

 

Animated cameras:

a ) can be animated but don't have to be animated

b ) use intuitive XYZ values for rotation

c ) are contained in a model file that can be named whatever and used wherever (though difference in module layout is obviously still an issue)

 

There is one and only one thing static cameras can do that animated cameras can't: You can change cameras in the middle of a dialogue node with SetDialogPlaceableCamera. Unless I had to do that, I wouldn't ever use them. I hadn't ever considered a circumstance like the Xor encounter, though. That's a unique case because it can pop up in different areas, as you said.

[Fair Strides 509]

1. Static cameras have Quaternion orientations just like everything except for doors and IIRC placeables.

2. Static cameras (don't know about Animated, but I assume no) are oriented 90 degrees counter-clockwise from what you'd expect. This is why you had to enter the numbers for 90 degrees to get a 180-degree facing. I learned a bit about this in college math, but I honestly cannot recall the reason for this rotation...

3. Animated cameras, and indeed all models, use Quaternions; the tools do the conversion for you so you don't have to bother with them (trust me, they're ugly and annoying).

[Kexikus 995]

2. Static cameras (don't know about Animated, but I assume no) are oriented 90 degrees counter-clockwise from what you'd expect. This is why you had to enter the numbers for 90 degrees to get a 180-degree facing. I learned a bit about this in college math, but I honestly cannot recall the reason for this rotation...

 

I don't know about that but I've always been able to use the quaternions I get from the orientation armband directly and got what I wanted.

 

I'm still investigating this current issue. At the moment it seems like I always get one of two possible outcomes (facing directly north or facing directly south) when I enter anything that I don't copy from another camera. That includes simple values like 0°,90°, etc. I have absolutely no idea why that's happening though...

 

Edit: Instead of editing the already existing cameras, I deleted those and created two copies of another camera. Now I get better results, i.e. there are now more than two possible directions. But the cameras are still oriented wrong. In fact they're oriented 90° clockwise from what I was expecting...

 

Edit 2: Manually adding a counter-clockwise rotation of 90° to compensate rotates the camera by 180° so it's still facing the wrong direction.

 

Edit 3: Okay. Doing a counter-clockwise rotation of 45° from my original orientation resulted in the needed 90° rotation. I guess I solved the issue, but something seems to be seriously wrong with the camera orientation in this module.

[JCarter426 1,215]

Static cameras have Quaternion orientations just like everything except for doors and IIRC placeables.

 

Doors, placeables, creatures, waypoints, and anything else that's spawned. Static cameras are the only game objects that do use them.

 

don't know about Animated, but I assume no

 

That would be a no.

 

the tools do the conversion for you so you don't have to bother with them

 

That's all that matters, right? You don't have to mess with that stuff in 3ds Max or even AniCam. You do have to if you want to place any camera in a GIT file.

 

Manually adding a counter-clockwise rotation of 90° to compensate rotates the camera by 180° so it's still facing the wrong direction.

 

Okay. Doing a counter-clockwise rotation of 45° from my original orientation resulted in the needed 90° rotation. I guess I solved the issue, but something seems to be seriously wrong with the camera orientation in this module.

 

Sounds like it's doubling everything you enter? That doesn't make sense... at all...

[LiliArch 115]

Have you tried editing static cameras in any other module?

[Kexikus 995]

Yes, I worked with static cameras for years and never encountered any problems. I don't think I've ever edited existing cameras and only added new ones / made copies of existing cameras but that should make no difference.

[LiliArch 115]

As long as the data structure match, it shouldn’t make a difference, yeah. I was just checking that it’s not a default behavior of static cameras in general.