Shift Ctrl Drag

[Porky Gorky]

Greetings.

Here is an issue that has been bothering me lately

When using shift ctrl on a prim it brings up the bounding boxes (dunno if that's the technical name) that can be dragged to change the size of the prim.

Here is a pic of this being done on a prim that has the dimensions 0.5m x 0.5m x 0.1

 

Here is a pic of this being done on a prim that has the dimensions 0.5m x 30m x 0.1

 

 

As you can see the bounding boxes in the second image are huge compared to the first. If I zoom in on a prim like the one in the 2nd image and press shift ctrl I find it tricky to grab the green box on the Y axis especially if I am looking at the prim from a side on 2d perspective. With enough camera tilting I can grab it in the end but doing so annoys me and disrupts my workflow.

So what can I do to reduce the size of these bounding boxes on prims such as the one in the 2nd image?

Thanks.

[Alicia Sautereau]

This has been an issue since prims could be larger then 10 meters
Encounterd it in olg and klee said it`s near impossible to fix (1.5 year ago), don`t ask why...

 

[Porky Gorky]

Fair enough, I guess I shall remain annoyed.

I have a completely unrelated question that I am going to bung in this thread to save starting another. I've been meaning to ask this question for years.

I select a prim, then shift select a second prim, then click on the texture tab. This displays the texture properties for the 2nd prim selected. In the the old days you used to be able to highlight the first number in the repeats field then just click tab repeatedly, cycling through all the fields on the texture tab. This would then apply all the properties from the 2nd prim to the first prim selected (repeats, rotation, offsets etc). This was a very quick way of copying the texture properties from one prim to another. Nowadays I need to copy and paste the data from each field individually on the texture tab, or type the numbers in manually.

It's annoying!

So is this a client side problem, am I just missing something or using the wrong viewer?

Or did LL just break this function somewhere along the line?

Cheers.

[Alicia Sautereau]

I think this might be an issue with the viewer your using

I`m used to building like that aswell and just tested it to be 200% sure and it works (select all identical faces -> select pre-aligned face tabs+enter)

[Drongle McMahon]

Technically these are called drag handles. The bounding box is the translucent box that encompasses the whole object.

I had a look at the source code. The size of the drag handles is set in llmanipscale.cpp, in a function LLManipScale::render(). This seems to make them a fixed proportion of the view height, multiplied by the distance from the camera to the center of the object. So when the camera is near one end of a long plank, that makes them much larger than when it's the same distance from the end of a short plank. The handles at the center should be the same size in both cases. As Alicia says, this has become much more noticeable since objects can be much bigger.

I don't see why this should be hard to fix. I suppose the relationship to camera distance is so that the handles on the far side of the object remain visible and easy enough to select even for big objects, where perspective makes them shrink on the screen. It should be possible to modify the dependence on object center distance to make a compromise between this objective and allowing selection of handles near the camera. This could be a simple cutoff or a square root function, for example. Whether that would work better, I am not sure.

ETA. It would also be possible to add a slider that simply scaled the handle size. That would probably be the most convenient solution for builders.

ETA. In fact you could intervene before the individual handles are rendered and apply a maximum subtended angle at that point. That's more complicated though.

 

[Porky Gorky]

---

Alicia Sautereau wrote:

I think this might be an issue with the viewer your using

I`m used to building like that aswell and just tested it to be 200% sure and it works (select all identical faces -> select pre-aligned face tabs+enter)

---

That last word in your post is the winner. I don't hit the enter key after tabbing You never used to have to do that, just tabbing would copy the numbers across.

Oh well, it's only been 5 or 6 years that this problem has been bugging me. Thanks for solving it :matte-motes-big-grin:

This reminds me of when I first started building and selling prefabs in 2004. I was in business for over 6 months before I suddenly realised that you could edit the properties on a select face of a prim . This was like a revelation to me.

I seem to be a master of missing the bleeding obvious!

Thanks very much.

 

 

[Chosen Few]

What a silly way to set it up.  Those handles are a UI element, and as such, their sizing on screen should be static, entirely independent from object scaling.  They should use a fixed amount of pixels at all times, regadless of camera zoom, just like all the other manipulators.

[Chosen Few]

---

Porky Gorky wrote:

I don't hit the

enter

key after tabbing You never used to have to do that, just tabbing would copy the numbers across.

---

For what it's worth, I'm actually glad they made that change.  It helps prevent accidental edits. It also brings SL's behavior more into alignment with how tabbing and entry work in a lot of other programs.

While it makes deliberate take edits one keystroke longer, which might seem less efficient if you're used to the old way, it does actually make more logical sense this way.  Logically, simply tabbing from field to field shouldn't change any of the data in the fields, even if multiple objects are selected.  The Tab key is just for moving the cursor.  Entering data is what the Enter key is for.  The tab key only serves as an entry tool, if it's pressed after new text has been entered into a field.

[Drongle McMahon]

"What a silly way to set it up"

I am inclined to agree. I have been trying to think of good reasons why it's the way it is. Perhaps the perspective effect makes it easier to see which handle is which?

[Porky Gorky]

---

Chosen Few wrote:

---

Porky Gorky wrote:

I don't hit the

enter

key after tabbing You never used to have to do that, just tabbing would copy the numbers across.

---

For what it's worth, I'm actually glad they made that change.  It helps prevent accidental edits. It also brings SL's behavior more into alignment with how tabbing and entry work in a lot of other programs.

While it makes deliberate take edits one keystroke longer, which might seem less efficient if you're used to the old way, it does actually make more logical sense this way.  Logically, simply tabbing from field to field shouldn't change any of the data in the fields, even if multiple objects are selected.  The Tab key is just for moving the cursor.  Entering data is what the Enter key is for.  The tab key only serves as an entry tool, if it's pressed after new text has been entered into a field.

---

Yes, I agree, I often used to make editorial mistakes by being a bit TAB happy. TAB ENTER makes much more sense.

I really cannot believe that I have missed this for all these years. Seriously, I have spent thousands of hours building in SL, I even worked full time in SL, building custom regions between 2007 and 2010 and in all that time it didn't occur to me to try TAB ENTER. 

It beggers belief !