Talk:LlSetCameraParams
Params not setting
I am finding that params are not setting if the last controls used before sitting on the scripted object were the camera controls (LL 1.23) although they set as expected if the movement controls were the last touched before sitting. Is this a caveat or am I missing something? Here are the settings that produce the results. <lsl>run_time_permissions(integer perm) {
if(perm & PERMISSION_CONTROL_CAMERA) // This is returning TRUE
{
llClearCameraParams();
llSetCameraParams([CAMERA_ACTIVE, TRUE,
CAMERA_FOCUS, pos + <8.0,4.0,-6.0>,
CAMERA_FOCUS_LOCKED, TRUE,
CAMERA_POSITION, pos - <8.0,4.0,1.0>,
CAMERA_POSITION_LOCKED, TRUE]);
}
}</lsl> -- Fred Gandt (talk|contribs) 18:10, 27 April 2010 (UTC)
- The scripted camera only overrides the default camera mode, not user mode. I suspect it's intentional (otherwise you could have the script pound on the camera controls to keep the user from looking elsewhere). Try using sit cam first, I think they can steal from user, then use follow cam. -- Strife (talk|contribs) 05:24, 29 April 2010 (UTC)
- Hmm. So would we call that a caveat Strife? I'm not sure what you mean by a "sit cam". I tried llForceMouselook but it wasn't overriden by llSetCameraParams so, that was a washout. It does make sense I suppose that we should be able to manually override set params but it would be nice if I could force them to set for the user without a stipulation that they must use their movement controls for the params to take effect. I'll add this as a caveat for now. See what you think? -- Fred Gandt (talk|contribs) 14:52, 29 April 2010 (UTC)
- The thing is I remember when they added the llSetCameraParams, the project was called FollowCam. The old camera functions were for vehicles and locked it to a fixed local position, so I call them Sit Cam. Maybe Rigid Cam is a better name. The two functions are llSetCameraAtOffset & llSetCameraEyeOffset.
- Now that I really look at the article it is pretty spartan; there is a bunch of missing information. I'll put it on my todo list. -- Strife (talk|contribs) 04:31, 30 April 2010 (UTC)
- Before HUDs (and FollowCam) people would use llSetCameraAtOffset & llSetCameraEyeOffset for game terminals. You would sit down and it would put the camera in a position where there was a very tiny display just in front of it. An inworld HUD. I should probably contribute to the HUD article as well, there is some good info rattling around my brain that should be placed in Deep Notes.-- Strife (talk|contribs) 04:35, 30 April 2010 (UTC)
What is the target?
CAMERA_BEHINDNESS_ANGLE Sets the angle in degrees within which the camera is not constrained by changes in target rotation. What target are we talking about here???
All I can see is CAMERA_FOCUS, which set's a target position. How can a position rotate?
- We need a little context before the features make sense. llSetCameraParams was a main part of the FollowCam project. A primary goal of FollowCam was to make vehicle camera movement much more smooth an less jerky. So the idea is the camera follows behind the vehicle, at a certain distance, now if the vehicle jerks back and forth left to right, the camera if it were fixed straight behind the vehicle at a fixed offset would then jerk back and forth as well. This could result in the user getting motion sickness. With CAMERA_BEHINDNESS_ANGLE, the vehicle can jerk back and forth and the camera won't jerk along with it. Or at least that is the theory, CAMERA_BEHINDNESS_LAG also helps reducing the jerky movement. -- Strife (talk|contribs) 21:53, 25 December 2013 (PST)
Camera Manipulation
I've recently tried my hand at attempting to create a custom camera script to the affect of only giving myself a headache over the seemingly lack of concise ability to fully manipulate the camera. To specify, I am attempting to create a lock on function that will focus lock the camera to another avatar. I've run into quite a few issues after completing that simple task. For starters, the Camera will, if not position locked to a llGetPos() vector for x and y, rotate and move when i rotate my own character. Specifically, when the position is not even set, the camera will rotate around the focus point 360° as i simply hold left or right on my keyboard. Secondly, trying to define further improvement to the Camera's behavior using the limited parameters has been difficult. The purpose of my lock on camera is to Focus on the target Avatar while also keeping my own avatar in view. Issues arise from the fact that the Camera must be position locked with a Rot2fwd vector just to keep myself in view from any angle, given my own avatar facing the target. Again, this works decently enough also until I begin to rotate and the camera becomes evident that it's merely fixed to a point in space behind my own head, as this point rotates around me. Even with focus lock set, movement controls are not relative to the point of focus, which is very much unlike how normal movement functions while inside or outside of mouselook. Furthermore, while setting the camera focus and position lock to an avatar's dynamic position everchanging through the use of a timer, it becomes evident that a timer cannot refresh fast enough for the viewed motion of the camera to not be jerky and unnatural, truly as if it were actually attached to a non-physical prim moving by means of llSetPos(), and not the organically fluid motion often experienced with simple manipulation of the Camera which any one may experience day-to-day in normal SecondLife usage.
I propose an overhaul to this camera controlling function, as it is by far the most primitive function in LSL I've run into yet. Camera controls could be used to a much greater effect for so much more than just vehicles, and even enhance vehicle camera views given it had a broader range of parameters to define the Camera's behavior. If the CAMERA_POSITION flag parameter is not set nor even called, the CAMERA POSITION should not change if CAMERA_FOCUS is centered on a target. CAMERA_FOCUS should also have parameters for agents and objects, so tracking movement doesnt need to be called with a timer event and llGetPos(). A "CAMERA_ZOOM" flag using a float value would be more natural than CAMERA_DISTANCE which is made redundant by CAMERA_POSITION. To define, CAMERA_ZOOM would additively change the position of Camera relative to the focus, which with a better CAMERA_FOCUS flag (better being the nixed Camera Position it includes right now), would be the relative position of the Camera between the user Avatar and their target, instead of being a free-rotating camera explicitly around CAMERA_FOCUS. Stikku Habsburg 03:49, 10 June 2014 (PDT)
- prposed new camera functions and noted changes/retains:
CAMERA_POSITION, vector position, • current camera position behavior
CAMERA_POSITION_KEY, key id, vector local_offset
CAMERA_POSITION_NAME, string name, vector local_offset
CAMERA_POSITION_LOCK, integer isFalse, • current function
CAMERA_FOCUS, vector position, • current camera focus behavior
CAMERA_FOCUS_LOCK, integer isFalse, • current focus lock behavior
CAMERA_FOCUS_KEY, key id, vector local_offset, • focus on Avatars
CAMERA_FOCUS_NAME, string name, vector local_offset, • focus on objects
CAMERA_FOCUS_SEE, vector position, • new proposed camera of "looking towards" the focus with the camera positioned in the default position relative to own avatar.
CAMERA_FOCUS_SEE_KEY, key id, vector local_offset, CAMERA_FOCUS_SEE_NAME, string name, vector local_offset,
CAMERA_DISTANCE, float value, • current function
CAMERA_ZOOM, float value, • used with Camera Focus See
CAMERA_PITCH, float value, • current function
CAMERA_ROLL, float value, • 0 = default, -180/180 being the left and right rotational extremes (upside down)
unnamed parameters function as normal. Stikku Habsburg 05:21, 10 June 2014 (PDT)