|
|
|
[
Permlink
| « Hide
]
Ceera Murakami added a comment - 10/Jul/07 11:31 AM
This issue has been a pain for quite a while now. What it is doing is that if you try to focus on the inner face of a hollowed prim, the camera can get no closer than the exterior surface of an un-cut, un-hollowed prim of that shape, on that line of sight. So if you are inside a hollow cylander, and look at the wall with alt-zoom, the camera winds up outside the cylander, behind you.
I marked this as a duplicate of VWR-98. Please refer to that issue for further comments&questions.
The description of this bug doesn't match VWR-98 - according to the video repro in VWR-98, one can click a 'nametag' and end up reproducing the spun-out camera.
Also, since the reporter(s) haven't said anything to indicate that he/she agrees with this issue being a duplicate, you should 'resolve' this issue instead of closing. Fighting this bug was a terrible frustration while building a domed club. I had to line the inside with various boxes, because every time i alt-clicked the dome my camera zoomed outside. I agree with Celierra, this is not a dupe of VWR-98 at all.
Definitely something I'd like to see fixed. I can't reproduce this bug with Second Life 1.18.2 (0) Aug 10 2007 09:34:24 (Second Life Release)
See attached video. Actually, Benja, your video DOES reproduce this issue... it's just hard to spot in the setup you have. Notice what happens when you zoom in on that hollow face just after you first start alt-zooming. I can see why you'd think you're actually zooming into that face, but pay attention to the point at which the camera stops zooming in and starts changing its field of view (this is normal behavior as you zoom super-close to anything in-world). If you look carefully at what's happening, that field-of-view zooming is actually happening several meters out from the face of the prim, which is evidenced by how the view changes when you pan. Your camera is actually focusing on a point in the central axis of the cylinder, which is the erroneous behavior I was trying to describe in the issue description.
This is different than VWR-98. I initially thought it was the same issue, near the end of the 98-video I show this one, that's incorrect, it's a different issue.
I'm currently rendering an animation better explaining this issue, will post it here tomorrow. Here's my video. In the first part, you see me in a hollowed cube, unable to alt-clicking the cam
-Create a large hollowed cube -Stand inside it, so that your cam is inside it too -alt-click the hollowed face *Observed: Camera snaps to outside the cube =Expected: Camera stays inside the cube I tried to make this behavior clearer with the second part of the video, a hollow cube again, you now see the camera rotating around a point on the hollow side. Ooh, fancy lead-in. Showoff.
Wow, your diagram at the end really helps crystallize this issue. This seems to me that it may be more than what I was thinking (that an incorrect point is being used as a focus point for the camera). It may be that this is a malfunctioning of the weird half-hearted attempts the camera code makes to prevent you from embedding your camera inside a prim. It may be that this code is overzealously failing to allow you to get your camera "inside" a hollow prim. I noticed this issue a long time ago, as all of my SL "residences" have been skyboxes consisting, at least partially, of hollow box prims for walls. So I've formed the habit of alt-clicking on the floor, ceiling or pretty much anything but the walls to change cam position, but sometimes I forget (or miss) and my cam ends up out in the cold.
Update: This is caused by the camera being constrained to the rotated bounding box (extents) of the prim. This ignores hollows it seems.
The picking code, which decides the point you are interested in, apparently does take cuts and hollows into account. It's pretty easy to turn off the rotated bounding box constraint, but that exposed flaws in the picking algorithm. Apparently it sometimes picks points pretty deep under the face in question. This causes it to be hard to determine how much the minimum should be to keep the prim from intersecting the near clip (being able to zoom "through" the prim). So it looks like at this point, the only option is to make the picking code more accurate, so it picks a point a lot closer to the face where you clicked, consistently, instead of a point potentially pretty deep inside the prim. Needless to say, this is not going to be an easy fix. On the plus side, better picking code might be useful for the highly requested "face touch UV" LSL function. From what I've seen, the current picking code is not so hot for picking something near where you actually clicked. OK, I actually made some progress on this without touching the picking code. I'm tentatively positive on this.
Exciting stuff! I remember Gigs told me he was working on this... and this issue came up in our UI triage today. Looking forward to the work being done.
 Here's the patch!
Notes: 1. Alt-zooming on nametags is still weird. It was already weird before, so it's just a different kind of weird now. If anything, it's a little more tolerable. 2. The camera is no longer constrained to the bounding box of the focus prim or avatar. The only way you can see this is if you zoom all the way in, and then pan up or down, left or right, to force your camera to intersect with the prim or av. When doing a straight alt-zoom, the behavior is similar to before, except it works correctly on hollow and weird prims now. This is a desirable behavior in a lot of cases anyway, as it is near impossible to get lost attachments out of your body with the current constraints. Note that it was always possible to pan other prims (even in the same linkset) through your camera in this manner. 3. I have written a test script for this patch and for camera constraints/picking in general: https://wiki.secondlife.com/wiki/Camera_and_Picking_Test It is not complete, as it is focused on this patch and the issue it touches mainly. It should be expanded to cover all the functional specs of the alt-zoom feature and the camera control feature. I'm all for the design decision in #2. I find it constantly annoying that my camera sort of half-assedly bumps into the prim I'm zooming on; often I actually DO want to send my camera through it. The limitation is almost never perfect and ends up just getting in my way. I'm especially interested to hear that this will help me in getting attachments out of my head.
I can't wait to test a client with this patch. I'm glad to see it isn't just me having this issue again. It's slowed me down to a crawl in retexturing and building, because I pretty much waste time shepherding my camera into the right angle.. only to have it spin on itself and not the prim.. or I have it going on a little trek.
Sadly, I'm trying to figure out how to install the patch.. and my research doesn't tell me how. So, could someone please explain this to a poor idiot redhead? Raudf, it's a pretty complex process that involves recompiling the client. Nicholaz may pick this patch up in his viewer soon though. If you are on Linux I can send you an already compiled version with this patch.
Needs a null pointer check on one of the lines, to avoid a crash. camera-less-crashy patch attached.
Richard Linden has provided feedback on this patch. He rejected the idea of being able to pan through the focus prim, and also not munging the center.
I will add these constraints back in. The center munging one is easy to add back, the no-clip one is pretty hard, but I have some ideas how to do it. You should read the thread on the sldev list. It's more or less valid, I guess. I think I can add some form of clipping constraint back in, it'll just take a while longer.
Thank you Gigs for taking this one on. I'm all for it. It will make building so much easier.
Here's an updated patch that applies cleanly to the 4.0 RC
Oops, regressed that crash bug fix when I ported forward. Use 4.0-2 patch instead for testing this with 4.0RC.
I still haven't done the work to add those constraints back in to make this suitable for LL. Still waiting for this fix. I would take it the way it is, so it looks like I will have to bite the bullet and learn to recompile the client so I can try it out. I use a lot of hollowed cut and tortured prims so this bug really affects me and I would guess those viewing my tortured builds.
The best way to encourage this to be fixed sooner is to make a donation at http://slurl.com/secondlife/Hippotropolis/132/132/29/
 . Remember, open source programmers need to eat, too! This issue seems to have gotten worse in Windlight (see
I'll see if I can port my patch forward to windlight soon.
Gig, this patch, while great and interesting, does seem to induce serious troubles when you attempt to rez an object on the ground from you inventory (drag and drop). SL complains about not being able to rez at the position. Rezzing only works again after you change the camera angle (and often you have to change it quite a few times before it works).
As I was not the only one to run across this issue, I am removing this patch from the Cool SL Viewer ( http://sldev.free.fr/ That message comes from the server, not the client. I get it all the time lately, even in viewers without my camera patch.. like constantly.
I'll look into whether my patch is making this worse or not, but I'd hesitate to blame the patch for that. Uhm sorry Gigs, but afaik with the patch, I couldn't rez things to ground 90% of the time.
Without the patch. No problems. Henri - Was taking this patch out the only thing you did for the last viewer release? Or could it have been a different change that made the difference? @ Gigs
I'm sorry, but with your patch I got rezzing problems 90% of the time (yes, it becomes a real pain to rez anything and you need to move the camera a lot of times to find the right angle which will provide a valid rezzing spot), while without it, this rezzing problem happens only every now and then (less than 10% of the time). @Fluff I confirm that the only removal of this patch solves the problem (it was the object of the Cool SL Viewer 1.18.5.3 release 8: nothing else was changed in this release when compared to the release 7). Marine Kelley also adopted this patch in one release of her RestrainedLife viewer, but she removed it a couple of releases later for the same reasons... OK, if you all have solid reproduction then it probably is the patch. This patch will likely have to be rewritten nearly from scratch for windlight anyway. I'm sorta waiting for windlight to be released before putting too much into this... since Linden Lab is taking about 6 months to get new patches in, there's no point is me rewriting it for the first look.
It was the patch.
The deal was that the server side raycasting for rez relies on the ray intersecting the object, a solution for this that Qarl Linden came up with is to just make the ray really long when rezzing. My patch shortened the ray slightly, and it was already too short for many cases, so it just made it worse. I could add that to this patch, however, the work that Qarl is doing right now overlaps so much with this patch that I think I'm going to give up on the patch for now and let Qarl do it. I'm going to forward this bug to Qarl and ask him to try to address it with what he's working on. I just posted a repro for VWR-98
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Reopened
Normal
alt-zooming on hollow face mishandled
I'll wait and see if Nicholaz gets it in. This is more of a pain in the butt than the shoe up the butt error...