For example there is an image using canvas with a rectangle in World Space. In doing so the camera/device can look around freely with the image placed into the "real" world. I wonder if there is a way to limit that "movement", spanning left to right, top to bottom but the device/camera view is limited at a certain point. Even if users turn the device/camera 360degrees, the view is stuck at a certain point. Say if the user pans left the camera/device stops at rotationY: 9, If right then stops at rotationY :-15, rotationX is stuck at 0.
I saw there's a BoundBox in the documentation but not sure what that is. There's a DeviceMotionModule but no idea how to use it. I don't know what the script example given is suppose to do.
Look into using DeviceMotion. https://sparkar.com/ar-studio/learn/documentation/reference/classes/devicemotionmodule
The script example rotates the 3d plane according to the rotation of the phone.
You will have to do some maths to position your objects according to rules and signal you get from DeviceMotion.
Using the reactive module you can access the "Clamp" method which is actually made to restrict values between two bounds. I recently found this out because I had a similar problem. From this page
clamp(x: ScalarSignal, min: ScalarSignal, max: ScalarSignal): ScalarSignal
Returns a signal with the value that is the value of the given x signal constrained to lie between the values of the given min and max signals.
Note: The behavior is undefined if min is greater than max.
Related
I've recently begun toying with Unreal Engine (UE5 Early Access) and I started with the Puzzle Example Template. In the PuzzleBlockGrid blueprint, there is a variable called BlockSpacing that is used to calculate the (X,Y) coordinates a block before spawning it.
This is the blueprint.
I collapsed the logic for calculating the position to tidy up the graph a bit. I've highlighted the path to the variable in question.
Changing the value of Block Spacing has no effect on the placement of the blocks. I have verified this by printing the calculated values to the screen (not shown in pictures). I have tried changing Block Spacing to a wide range of values (10^10, 1, 0, 10^-10, -100: Default was 400). No matter the value entered, the calculated values are always the same. The only way I could get a different result is to bypass the Block Spacing and Multiply nodes; in which case, all positions are calculated to be (0,0).
Am I missing something?
Just FYI the calculated coordinates that I get are:
I realized that this is happening because Block Spacing is public and the value was set in the level map's viewport editor details pain, which overrides the initial value set in the blueprint.
I have gone through a couple of YOLO tutorials but I am finding it some what hard to figure if the Anchor boxes for each cell the image is to be divided into is predetermined. In one of the guides I went through, The image was divided into 13x13 cells and it stated each cell predicts 5 anchor boxes(bigger than it, ok here's my first problem because it also says it would first detect what object is present in the small cell before the prediction of the boxes).
How can the small cell predict anchor boxes for an object bigger than it. Also it's said that each cell classifies before predicting its anchor boxes how can the small cell classify the right object in it without querying neighbouring cells if only a small part of the object falls within the cell
E.g. say one of the 13 cells contains only the white pocket part of a man wearing a T-shirt how can that cell classify correctly that a man is present without being linked to its neighbouring cells? with a normal CNN when trying to localize a single object I know the bounding box prediction relates to the whole image so at least I can say the network has an idea of what's going on everywhere on the image before deciding where the box should be.
PS: What I currently think of how the YOLO works is basically each cell is assigned predetermined anchor boxes with a classifier at each end before the boxes with the highest scores for each class is then selected but I am sure it doesn't add up somewhere.
UPDATE: Made a mistake with this question, it should have been about how regular bounding boxes were decided rather than anchor/prior boxes. So I am marking #craq's answer as correct because that's how anchor boxes are decided according to the YOLO v2 paper
I think there are two questions here. Firstly, the one in the title, asking where the anchors come from. Secondly, how anchors are assigned to objects. I'll try to answer both.
Anchors are determined by a k-means procedure, looking at all the bounding boxes in your dataset. If you're looking at vehicles, the ones you see from the side will have an aspect ratio of about 2:1 (width = 2*height). The ones viewed from in front will be roughly square, 1:1. If your dataset includes people, the aspect ratio might be 1:3. Foreground objects will be large, background objects will be small. The k-means routine will figure out a selection of anchors that represent your dataset. k=5 for yolov3, but there are different numbers of anchors for each YOLO version.
It's useful to have anchors that represent your dataset, because YOLO learns how to make small adjustments to the anchor boxes in order to create an accurate bounding box for your object. YOLO can learn small adjustments better/easier than large ones.
The assignment problem is trickier. As I understand it, part of the training process is for YOLO to learn which anchors to use for which object. So the "assignment" isn't deterministic like it might be for the Hungarian algorithm. Because of this, in general, multiple anchors will detect each object, and you need to do non-max-suppression afterwards in order to pick the "best" one (i.e. highest confidence).
There are a couple of points that I needed to understand before I came to grips with anchors:
Anchors can be any size, so they can extend beyond the boundaries of
the 13x13 grid cells. They have to be, in order to detect large
objects.
Anchors only enter in the final layers of YOLO. YOLO's neural network makes 13x13x5=845 predictions (assuming a 13x13 grid and 5 anchors). The predictions are interpreted as offsets to anchors from which to calculate a bounding box. (The predictions also include a confidence/objectness score and a class label.)
YOLO's loss function compares each object in the ground truth with one anchor. It picks the anchor (before any offsets) with highest IoU compared to the ground truth. Then the predictions are added as offsets to the anchor. All other anchors are designated as background.
If anchors which have been assigned to objects have high IoU, their loss is small. Anchors which have not been assigned to objects should predict background by setting confidence close to zero. The final loss function is a combination from all anchors. Since YOLO tries to minimise its overall loss function, the anchor closest to ground truth gets trained to recognise the object, and the other anchors get trained to ignore it.
The following pages helped my understanding of YOLO's anchors:
https://medium.com/#vivek.yadav/part-1-generating-anchor-boxes-for-yolo-like-network-for-vehicle-detection-using-kitti-dataset-b2fe033e5807
https://github.com/pjreddie/darknet/issues/568
I think that your statement about the number of predictions of the network could be misleading. Assuming a 13 x 13 grid and 5 anchor boxes the output of the network has, as I understand it, the following shape: 13 x 13 x 5 x (2+2+nbOfClasses)
13 x 13: the grid
x 5: the anchors
x (2+2+nbOfClasses): (x, y)-coordinates of the center of the bounding box (in the coordinate system of each cell), (h, w)-deviation of the bounding box (deviation to the prior anchor boxes) and a softmax activated class vector indicating a probability for each class.
If you want to have more information about the determination of the anchor priors you can take a look at the original paper in the arxiv: https://arxiv.org/pdf/1612.08242.pdf.
I have a bar chart that show the count of number of models for each agency,
The problem is that I have a large difference between the values that makes the report to look not so good.
Does anyone have any ideas of a good way to resolve this problem?
Have you considered using a logarithmic scale?
With your chart Right-click the y-axis, and click Vertical Axis Properties.
In Axis Options, select Use logarithmic scale.
Leave the Log base text box as 10 (this is the scale most commonly used by logarithmic charts)
This will display a chart with a scale that goes up by a factor of 10 for each ‘unit’ up, so the distance between 1 and 10 is the same as that between 100 and 1000.
For example the shown dataset is displayed as this chart when using the logarithmic scale
This method is a simple and recognised way to clearly show values of widely different scales.
Update
If want an indicative bar for the vales that are 1 then you could use the expression
=iif(Fields!val.Value = 1, Fields!val.Value * 1.1, Fields!val.Value)
To make all values that are 1 equal to 1.1 so showing a tiny bar appearing a the bottom of the chart, as seen here
Unfortunately I don't know of a way to change that first 1 to a zero (formatting-wise). This is partly because you are now using a logarithmic scale and zero and negative values don't really exist. This is due to a fundamental property of logarithms in mathematics, that
LOG10(10)= 1
LOG10(1) = 0
LOG10(.1)=-1
Therefore, when you perform a log10 of zero, it just doesn't exist.
I have been looking into the RagdollDemo and have kind of got stuck in the part where setEulerZYX() is used in basis matrix.
transform.setIdentity();
transform.setOrigin(btVector3(btScalar(-0.35), btScalar(1.45), btScalar(0.)));
transform.getBasis().setEulerZYX(0,0,M_PI_2);
m_bodies[BODYPART_LEFT_UPPER_ARM] = localCreateRigidBody(btScalar(1.), offset*transform, m_shapes[BODYPART_LEFT_UPPER_ARM]);
I did some research, yet couldn`t fully understand what exactly does this function do and why it is needed. Any help would be very nice.
It is a way (there are others) to set the rotation of the body.
http://bulletphysics.org/Bullet/BulletFull/classbtMatrix3x3.html#a0acce3d3502e34b4f34efd275c140d2a
So this is setting it to 0,0,M_PI_2, M_PI_2 being Pi/2 means this is a rotation on the x axis of 1/4 turn, i.e. 90 degrees.
I have a car object, and I want it to gradually rotate to the direction where the user clicked.
Every frame I did math to calculate the new direction it needs, and it's stored at car.direction. The actual direction is of course in car.rotation.
Now I want to update the rotation every frame until it's equal to the direction. However I tried everything and can't figure out how to do that.
By the way, I'm using FireFly, that is a gameengine built on top of Starling Framework, But I don't think it's relevant.
I would go with Marty's suggestion, use the smallestAngle function to determine which direction you should be rotating. Basically you can move some percentage of the smallestAngle during every frame update until the percentage of that smallestAngle is below some threshold (and have it "snap" the rest of the way).
Something like
//each time this is called it will get 1/4 closer, but never get to 0, hence the need for a threshold avoid paradoxes
//http://en.wikipedia.org/wiki/Zeno's_paradoxes#Dichotomy_paradox
var angleToMove:Number = smallestAngle()/4; //the divide by 4 here means get 1/4 of the angle gap closer each time this function is called, I assume this is on a timer or frame handler, making the 4 greater will make it follow more slowly, making it lower will make it follow more quickly, never reduce to or below 0 unless you want wonkiness
if(angleToMove<someRadianThreshold)
angleToMove = smallestAngle();
//use angleToMove to adjust the current heading/rotation