| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
- Removed logging for MAINT-3555
- Added NULL guard to fix MAINT-3703 (hopefully)
|
|
|
|
Serves me right for not waiting through the compile!
|
|
|
|
supposed to be highlighting. Did some more cleanup and documentation.
Also corrected a bug in Richard’s patch that resulted in the object scaling up when the mouse went the opposite direction from the scale. The issue is that the vector length is an absolute value. To allow for "negative" results to be found and discarded, I instead used a dot product with a parallel unit vector to get the signed magnitude - or, if you prefer, the mono-dimensional vector.
This bug only surfaced once the code made to actually work as intended in regards to the highlighting. Turns out that if the snapped value was at 2, any axis that was showing values would highlight its "2" text - and the same for all other values.
To fix this, I used a simple enum and repurposed the property that tracked whether or not the cursor was in a snap regime. Now it not only tracks whether or not the cursor is in a snap regime, but which one it is in. This allowed the highlight render code to be able to differentiate which row was supposed to highlight and which did not.
A couple more duplicated math operations were reduced by rearranging the order of some variable definitions. If at all possible, only do division once. The result is much cleaner and easier to read code.
Several deprecated vector functions were updated to match their new versions. If you are going to mark something deprecated, why not just take the time to go through and find all uses and clean it up!?
faceToUnitVector() was cleaned up to use the single-output design, matching cornerToUnitVector().
A mess of trailing whitespace was cleaned out.
Many more LLManipScale private variables are now documented - though I only documented those I understood fully while reading where they were created and how they were used.
|
|
opposite direction of the scale.
I had discovered a set of bugs in the fix he sent me involving when the user decided to move the mouse in the opposite direction. This fixes the bug where the scale would start sliding around.
|
|
|
|
From Richard: There are a bunch of things I changed...mainly I eliminated all the grid_offset nonsense and instead simply calculate the tick index for the current drag position and use that to generate a snapped position as needed. I still use approx_equal because I want grid numbers to light up even when they aren't the axis you are currently snapping to.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
- LLFloaterView::mToolbarRects[3] was transformed to LLRect mToolbarLeftRect, mToolbarBottomRect, mToolbarRightRect;
|
|
about the return type for calls to LLView::getParent(): never assume a down
cast is possible.
|
|
|
|
|
|
- Removed a lot of logging code to reduce application close time
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
enabled viewer play inworld - should be local only.
|
|
There was a lot of repeated division that was obscuring meaning, along with a variable that was always identical to another preexisting variable. This last was probably an archaism, and was just due for removal.
|
|
being performed
|
|
|
|
cause of the crash
|
|
|
|
|
|
codesigning
|
|
|
|
simplest change to solve issue.
The highlighting code assumed that the axis of the scaling movement was aligned with the scale tick marks - e.g. one of the cardinal directions with respect to the OBB of the selection. This was and is NOT true when dragging from the corner, aka scaling more than one axis at a time. The solution was to calculate the measured distance by projecting the snapped distance along the snap direction onto the axis of the relevant snap guide. This gives the correct values, and is nice and clean - both in the change involved, and in the values returned.
However, while the fundamental misunderstanding in the code has been cleaned up by this change, the tick_val variable has so much jitter in the bottom end that the is_approx_equal function doesn’t come true > 98% of the time. This is the next problem to solve.
|
|
|
|
|
|
|
