Skip to content
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.

[BUG-6325] More Flag parameters for llSetCameraParams() #14196

Open
3 tasks
sl-service-account opened this issue Jun 11, 2014 · 4 comments
Open
3 tasks

[BUG-6325] More Flag parameters for llSetCameraParams() #14196

sl-service-account opened this issue Jun 11, 2014 · 4 comments

Comments

@sl-service-account
Copy link

sl-service-account commented Jun 11, 2014

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.
proposed 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 normally.
CAMERA_RELATIVE_MOVEMENT, integer isFalse, • if TRUE, adjusts movement controls relative to the FOCUS with "strafing" left/right movement overriding the default left/right rotation movement.

Links

Related

Original Jira Fields
Field Value
Issue BUG-6325
Summary More Flag parameters for llSetCameraParams()
Type New Feature Request
Priority Unset
Status Accepted
Resolution Accepted
Reporter Stikku Habsburg (stikku.habsburg)
Created at 2014-06-11T04:06:21Z
Updated at 2022-11-30T19:18:14Z
{
  'Business Unit': ['Platform'],
  'Date of First Response': '2014-06-11T13:08:19.432-0500',
  'How would you like the feature to work?': 'proposed new camera functions and noted changes/retains:\r\nCAMERA_POSITION, vector position, • current camera position behavior\r\nCAMERA_POSITION_KEY, key id, vector local_offset\r\nCAMERA_POSITION_NAME, string name, vector local_offset\r\nCAMERA_POSITION_LOCK, integer isFalse, • current function\r\nCAMERA_FOCUS, vector position, • current camera focus behavior\r\nCAMERA_FOCUS_LOCK, integer isFalse, • current focus lock behavior\r\nCAMERA_FOCUS_KEY, key id, vector local_offset, • focus on Avatars\r\nCAMERA_FOCUS_NAME, string name, vector local_offset, • focus on objects\r\nCAMERA_FOCUS_SEE, vector position, • new proposed camera of "looking towards" the focus with the camera positioned in the default position relative to own avatar.\r\nCAMERA_FOCUS_SEE_KEY, key id, vector local_offset, CAMERA_FOCUS_SEE_NAME, string name, vector local_offset,\r\nCAMERA_DISTANCE, float value, • current function\r\nCAMERA_ZOOM, float value, • used with Camera Focus See\r\nCAMERA_PITCH, float value, • current function\r\nCAMERA_ROLL, float value, • 0 = default, -180/180 being the left and right rotational extremes (upside down)\r\nunnamed parameters function as normal.',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'Second Life Wiki > LlSetCameraParams\r\n[edit] Params not setting\r\nI 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.\r\nrun_time_permissions(integer perm)\r\n{\r\n    if(perm & PERMISSION_CONTROL_CAMERA) // This is returning TRUE\r\n    {\r\n        llClearCameraParams();\r\n        llSetCameraParams([CAMERA_ACTIVE, TRUE,\r\n                           CAMERA_FOCUS, pos + <8.0,4.0,-6.0>,\r\n                           CAMERA_FOCUS_LOCKED, TRUE,\r\n                           CAMERA_POSITION, pos - <8.0,4.0,1.0>,\r\n                           CAMERA_POSITION_LOCKED, TRUE]);\r\n    }\r\n}\r\n-- Fred Gandt (talk|contribs) 18:10, 27 April 2010 (UTC)\r\nThe 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)\r\nHmm. 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)\r\nThe 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.\r\nNow 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)\r\nBefore 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)\r\n[edit] What is the target?\r\nCAMERA_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???\r\nAll I can see is CAMERA_FOCUS, which set\'s a target position. How can a position rotate?\r\nWe 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)\r\n[edit] Camera Manipulation\r\nI\'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.\r\nI 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.\r\n',
}
@sl-service-account
Copy link
Author

Stikku Habsburg commented at 2014-06-11T05:21:29Z

Forgive the disordered appearance of this request. I copied and pasted it from the SL wiki's discussion for llSetCameraParams, where I posted this earlier before knowing about JIRA

@sl-service-account
Copy link
Author

Alexa Linden commented at 2014-06-11T18:08:19Z

Thank you for your suggestion.

@sl-service-account
Copy link
Author

Lucia Nightfire commented at 2014-06-11T23:49:48Z

Sadly, the camera is orientated to the user in all respects even when locked. Currently there is no ability to maintain an auto updated focus on anything other than the user by script like there is with the viewer without resetting the camera params at a high frequency which results in movement that is far from smooth. This will certainly be a welcome addition.

@sl-service-account
Copy link
Author

Stikku Habsburg commented at 2014-06-12T01:19:08Z

Very excited that this request has been accepted.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant