Has anyone successfully got a dialog to show a special camera angle of their choosing? I know T7 got that cool screenshot during a fight scene. There should be a way of setting up either a Placeable or an entry in the .git files' CameraList to be able to invoke a special vantage point.

here's an example layout from a dialog file in which I used a different camera angle and camera id(predefined from the git file).


EntryList [List] = ...
0 [User-defined Struct: 0] = ...
AnimList [List] = ...
CameraAngle [DWORD] = 6
CameraID [INT] = 7
CamVidEffect [INT] = -1




also, there is a script command that you could probably use.
I haven't implemented this in a script yet, but it might help.

void SetDialogPlaceableCamera( int nCameraId );

Originally posted by messkell

I haven't implemented this in a script yet, but it might help.

void SetDialogPlaceableCamera( int nCameraId );

How do you think that would work? would "nCameraId" be a vector(xyz) or could it be an invisible placeable?

The approach I've attempted is to add the CameraID field to the Entry or Reply list struct, and add an entry in the .git file's CameraList struct with ID=n. But this appears to have no effect during the dialog.

The CameraList struct however, does not provide X, Y, Z Positions unfortunately. ( It may only be used in conjuction with the CameraModel field instead, I don't know.)

I've also tried the SetDialogPlaceableCamera function without results. From the name of the function, it really sounds like there should be a placeable that would function as a camera (given its X/Y/Z Position and Bearing).

TK102, in addition to the camera angle, here are few example dialog entry/reply list line entries that can be used to alter the viewpoint during a conversation.


CamHeightOffset [FLOAT] = 1.000040054321
TarHeightOffset [FLOAT] = -0.500000000000

tk, are you asking if you can set the camera position on the fly in game, or just setting the camera in general? I think you are asking for the former?

All I've done is alter the camera ranges to be a bit farther away. Note that there are different camera parameters for different situations.

I would like to position the camera in a certain spot during key moments of the dialog. I remember seeing the parameters Messkell mentioned, but have not tried using them. So thank you for reminding me about them, Messkell.

I'm going to try to test something else using the Listener tag and see if I can't get the effect I'm looking for.

Originally posted by tk102
I would like to position the camera in a certain spot during key moments of the dialog. Ah, got it.

Sorry I can't help you :(

Tk102, here are a few brainstorming ideas:



I think that the SetDialogPlaceableCamera function didn't work for
the following reasons:

1. you need to add an invisible placable to the "placeables list" in
the .git file for whichever module you want to use.

example, see entries #9, #10, #11 under the Placeable List [List]
in the"m26ad.git". these inivisible placeables act as placeable
cameras.
also, look at the inv.placeables named camer4.utp - camer7.utp in
the "manm26ad_s.rim" to see how they are structured.


2. you need a trigger nearby the inv.placeable that signals the dialog event(placeables don't have their own
user defined events) in order to implement the
SetDialogPlaceableCamera function(only works during dialog).

I'm not sure if you required to move to the invisible placeable object in order for the placeable camera to work.



if any information is incorrect, throw a mackeral at me :)

I don't have the game in front of me at the moment but I will look into that. What do you suppose gets passed as the int parameter to SetDialogPlaceableCamera in the scenario you proposed?

Okay I figured out a bit more. It appears that SetDialogPlaceableCamera only functions when the conversation is paused. Thus is must be sandwiched like so:

ActionPauseConversation();
SetDialogPlaceableCamera(22);
DelayCommand(3.0,ActionResumeConversation());


In addition, this can only be called once per pause. You'll have to resume the conversation and pause again to change the camera a second time.

The int parameter is CameraID field of a struct in the CameraList of the .git file.

But I still haven't figured out how the location of the camera is specified. The CameraList structs don't give much clue.

perhaps they are defined in the mdl/mdx files although I think that is a very silly thing of Bioware to do. But who knows, perhaps they have a different reason not to mention that I don't have any formal training in programming to criticize Bioware =)

I personally guessed, perhaps it is defined as how Meskell said about the invisible placable. In addition to the X/Y/Z data in the Placable List in the git files, the cameras' properties are further specified by the CameraList struct. But then again this is just a guess, I have done no test whatsover.

I can't find any connection between placeables and cameras. I was analyzing the unk_m44ac module (meeting with evil Basitila), and tracing out how the Trigger scripts worked to swap camera angles. For that area there are 22 CameraList structs, but only 9 placeables (only one of which is invisible), so they must be defined elsewhere.

I remember the unk_m44ac module. I did some modifications to it some time ago. The invisible placeable is used for the available good/evil scenarios. It uses a heartbeat script to see which scenario you chose and if certain conditions are met to allow access to the computer.

I wonder if it serves a dual purpose for placeable cameras?

anyways, I tried a couple of other script functions, such as SetCameraFacing (to no avail in conversation) and setcameramode.

setcameramode only worked during conversation and is only available for the pc player.

void main()
{
object oParty1 = GetPCSpeaker();

ActionPauseConversation();
SetCameraMode(oParty1,CAMERA_MODE_CHASE_CAMERA);
DelayCommand(4.0f,ActionResumeConversation());

}

this function is somewhat limited because it only allows for the following 3 types of camera modes.

CAMERA_MODE_CHASE_CAMERA
CAMERA_MODE_TOP_DOWN
CAMERA_MODE_STIFF_CHASE_CAMERA

Have you found any scripts, source or decompiled, that made use of SetCameraFacing? nwscript.nss mentions that it can be used in area transitions. I can't really think of an instance of that.

Can you also describe the effect of the modes of SetCameraMode? :)

I have never located a single source script that contains any of the camera functions, such as setcamerafacing, that are allowable for kotor.

I did try to implement the setcamerafacing function before, and during conversations. I also tried to execute it in a trigger.
none of these methods proved "fruitful". perhaps it is only useable
during an area transition as you stated.

as for the SetCameraMode function, I only tried the camera mode "CAMERA_MODE_CHASE_CAMERA " which changed the camera viewpoint to a very high, almost top down perspective.

The SetCameraMode function was implemented during the
conversation, and once the conversation was finished, the
viewpoint stayed the same.

hopefully with some time, luck, and experimentation the "camera mystery" will be solved.

Well at least you found a function that behaves in a predictable manner. :)

In case you didn't know (not likely, heh heh) the GFF editor doesn't show and can't deal with/create certain GFF datatypes that are needed by cameras. These hold the XYZ position and orientation. The first is a tuple of floating point numbers (position) and the second looks like a quaternion (four floats) for the orientation.

<slaps forehead>
Of course! Jeez, I should've thought of that! It occured to me about a month ago that the new data types we discussed (http://www.lucasforums.com/showthread.php?s=&threadid=121572&perpage=40&pagenumber=3) were probably used in Location and Vector structures.

Wow Fred. I'm just stunned.

You get my favorite smiley

:guitar2

and his band

:sheepdanc :r2d :guitar1 :band1 :mm1 :sbdance :lock:

Okay, emotions resettling.

I guess that means we have to come up with a new GFF Editor or resort to Hex Editing.

Edit:
That also explains why camera angles get wacked out during certain conversations when the .git is edited in GFF Editor. :rolleyes:

Originally posted by Fred Tetra
In case you didn't know (not likely, heh heh) the GFF editor doesn't show and can't deal with/create certain GFF datatypes that are needed by cameras. These hold the XYZ position and orientation. The first is a tuple of floating point numbers (position) and the second looks like a quaternion (four floats) for the orientation.


Fred, thanks for the reminder. I had completely forgotten about that thread.

Hex editing the values is a pain, because each floating point number consists of 4 bytes (sign, mantissa and exponent, probably)

I wasn't sure anyone would be interested in the cameras as much as myself, so I haven't added much support for them in the module editor, other that showing where they are.

If there is enough interest, I'll add support for them, since I can do that (likely) faster than someone else can write a custom editor for cameras <heh heh>

A challenge Fred?

CamEdit now available for download.

Readme.txt (http://webpages.charter.net/krumsick/kotor/CamEdit_readme.txt)


[edit: download available at PCGM]

hehe, tk wins!!!!!

j/k

nice work tk

Good work TK! You win!!!;)

*edit*
(note: the author of this post admits being in a conflict of interest, having beta tested the CamEdit tool:D )

If anyone figures out how the four floating point numbers in the camera's orientation work, be sure to post about it.

It'll save some time when I start working on the module editor again.

Originally posted by tk102
CamEdit now available for download.





Tk102, excellent progress on the camera scenario...I salute you.

Fred,
I think you're right about the Orientation field containing a quaternion. The 4 floats are probably the w, x, y, z values. Take a look at this website:

http://www.euclideanspace.com/maths/algebra/realNormedAlgebra/quaternions/transforms/index.htm)

There's code there for transforming a point in space along with an example.
At the bottom of the page are a list of 90° transformations that we should be able to demonstrate in-game if these are in fact quaternions.

The most dramatic and simple would be to make the 4 floats: 0, 1, 0, 0. That should put the camera upside down.
Edit: it doesn't

It turns out that I had already added camera editing support to KT, but I had forgotten; it's been a month since I looked at the code. (I'm moving and haven't had much time)

Right now, you can edit the X/Y/Z position and the four other "visible in GFF editor" fields (whose names escape me at the moment).

I will try a test where I set the cameras' orientations to some strange values and see what happens.

Can your editor do that, to save me some testing?

Yes, it can change the values. I'd test the hypothesis myself but I don't have the game on this machine and I'll be home kind of late tonight.

I messed around with the values a bit, but not enough cases to determine which field is which.

If I discover anything, I'll post it here...

I did a lot of experiments on an Endar Spire camera last night, trying to replicate the airplane pictures shown on the website that I posted. There seemed to be some limits in place, preventing severe rotations like vertical and upside down rotations. But the yaw rotations function as expected.

(Wish they'd used use yaw, pitch, and roll -- it would've so much easier to mod.)

Are the values indeed w,x,y,z, in that order? I thought it might be x,y,z,w, based on a conversation with a friend who does VR for a living. But then again, who knows?

I believe w is the first value because 1,0,0,0 has no effect at all (well, the same effect as 0,0,0,0).

I understand x,y,z, but what is w?

Go to the website I posted above, read it, and come back.

There is also the possibility that we are barking up the wrong tree. These may also be values for an axis angle transformation.

See:
http://www.euclideanspace.com/maths/geometry/rotations/axisAngle/index.htm)

The first 3 values would be the axis and the last would be angle in radians(?).

Hypothesis: 1,0,0,3.1416 should make the camera upside down.

Edit: It doesn't either.

BTW, in case you don't, you may be interested to know that lyt files seem to work in a similar manner. Here is a screenshot of the m01aa.lyt (Endar Spire) file: http://img47.photobucket.com/albums/v144/Darth333/Endar_lyt001.jpg)

The .lyt files don't seem to affect door position. I think they are something different (doorhooks?).
In the .git file however, Bearing does play an important role.
http://img56.photobucket.com/albums/v170/tk102/image2.jpg)
I believe Fred's module editor makes heavy use of that field ... ?

Doors are indeed positioned and oriented in the .git file.

Just a quick note about camera angles. It seems Bioware found camera placement as difficult as we do. In many dialogs you'll find a number of invisible###.utp placeables that are used as Speakers in dialogs. (They have tags like "carths_chest", and "sta45aa_invis_conv_target"). I'm looking at sta_m45aa.rim as an example, specifically k_sta_carth.dlg. What a pain.