This is part 2 for some of the UI that I developed in Freedom Through A Lens. This is about once everyone has been spoken to, the photographs have been taken, and the photojournalist is back at their office choosing which photos to use in their piece of media. I say a piece of media because the specificity of which is left open for interpretation.
Everything here is UI. But like I discussed in part 1 this UI canvas is a child of another separate Camera and it’s render mode isn’t Screen Space: Overlay, it’s using Screen Space: Camera (this camera). The intent behind this section is that once the photojournalist got back to the office they’d have a single photo of all of the people who allowed them to do so. But the presentation of which, because there would be a small amount of photos, they would be scattered across the desk in a non-organized fashion. But scattered in a way that every photo wasn’t completely covered by another. Then once the player hovered over an image, it would move towards the camera enlarging it. If they selected the image, it would translate back to an already set spot. If they stopped hovering over the photo, it would translate back to its original position. There was a maximum of three photos that could fit on the piece of media. Once three photos had been selected – there would be a confirmation if these were the photos they wanted to use. If they chose to re-select the photos, all of the photos would translate back to their starting position. The remaining images that had not been selected, moved off-screen. Originally as I set this up, there was always going to be 7 photos, 3 of which got chosen and 4 got discarded. When there were more photos not being selected it was more effective to watch.
Transforms always move from the pivot point of the object, not the centre. Which is the opposite with RectTransform’s, along with the syntax of how to move objects.
Transforms are moved by transform.position.
Rect Transforms are moved by rectTransform.anchoredPosition or anchoredPosition3D.
The anchored position is wherever the anchor is set.
The four little white arrows are the pivot points. They’re moving in 3 dimensions from the anchor point (x,y,z VALUES) to the position of the set object (x,y,z VALUES). When the moving object’s anchor point is centre, and its x,y,z are zero, it moves the centre of the object to the x,y,z values of the set object. Whereas if the moving object’s anchor point is not centre – and for example is top left, and those values are zero. The zero values still lerp to the set objects x,y,z values, but in screen space the anchor point moves to a completely different location.
So all of this is being done where every photo has a manually placed object to move to. That move to object is a child object of the same object the photo is a child to.
So this is all done under the same parent object essentially. I’ve tried to make it so that the photo could lerp to a position of an object that isn’t in an immediate child transform of the same parent. And it doesn’t end up working well. I’m going to have an educated guess because when the object that was a child of the same parent moves to just be a child of the canvas, its x,y,z values get’s changed. And much like having different anchored positions – because the x,y,z values are lerping from their current state to the new ones, the on-screen position are very different. So unfortunately every photo has its own manually placed move to objects. Because they each need more than a single position to move to.
Hovering & Selecting
In order to hover over a photograph and initiate the lerp to position I wanted to use the Unity EvenTrigger that can be used just in the inspector.
Specifically PointerEnter and PointerExit.
When the cursor has entered the button: Move towards the desired object.
When the cursor has exited the button: Move away form the desired object.
The cursor entering and exiting the button toggled the moveTo bool. The bool is part of a script that’s attached to the button. The enter and exit accesses the script on that button and runs either one of two methods to turn the bool true or to turn the bool false.
The lerp operates from a 0 to 1 (0% to 1o0%) and the timer is just the percentage. If true – up the percentage, if not, down the percentage.
See the jitter? That’s because the mouse is entering and exiting the bounds of the photo in a very short time span. I needed to follow the image to stop it from doing this, and that’s not what I wanted at all. That’s also not what I wanted players to have to do either. So there needed to be some kind of buddy system. A zone that the cursor could enter to trigger the movement, but also so that if the cursor was within that zone or still within the photo the bool would remain true.
The solution was to have button (with a non-transparent image) that can’t be interacted with in the exact same position and size as the photo. This is the parent object. This is the master object that will detect the cursor enter and exit and have the script that controls the toggle of the bool.
The Fake area is the object with the event trigger and the script that has the method to get the ‘myButton’ objects script and turn its moveTo bool to true or false.
When I tested this out, even though I hovered over the fake area to trigger the move and while the mouse was still hovered over the photograph – even though parts of the photograph or the cursor weren’t within the fake area, the photo still lerped to the correct position.
I had the desired effect, but I was curious as to why it did what it did and how. I fiddled around with some things and discovered that because the photograph is still a child object of the fake area object the image that has ‘Raycast Target‘ bool is part of the system that checks for the mouse hover. With the image on the photograph that also has Raycast Target still parses info to the parent and states the cursor is still being hovered over by the mouse. COOL HUH?!
There was only one last problem to solve, and it was an easy one thankfully. Unity 5.5’s UI system renders the last child object first. I might not be saying that right, but the furthest child from the canvas in the hierarchy gets rendered first.
The solution is to just set the index of the object that’s being hovered over to a specific child index of this objects parent. In this case if the amount of object changed over time and this required some manual upkeep every now and then.
There’s more to talk about with this but I’ll conclude it at that for now.
Until next time –