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.
Related
I have multiple examples, this is just the first one. I've been extracting some information from this file (I really wish there were a better way!) and something changed that broke my parser. Here's an example of the problem:
The first line displays the date over at the right margin, the second displays "Room 1" in a slightly larger, bolded font against the left margin farther down the page. Note, though, that the first line has a Y location about 250 units below the second. There's obviously something about the location I'm not understanding.
(I only need to be able to properly Y-sort the items. While this one is in the right order I have found them out of order in the past.)
<Glyphs RenderTransform="0.0403884,0,0,0.0403119,0,0" Fill="#ff000000" FontUri="/Documents/1/Resources/Fonts/6C15166D-E658-4B97-A6C0-E217017F767F.odttf" FontRenderingEmSize="327.68" StyleSimulations="None" OriginX="14079.4" OriginY="2270.24" Indices="26,60;17,61;3,59;48,63;68,60;85,60;70,60;75,61;3,62;21,60;19,60;21,61;21" UnicodeString="7. March 2022" />
<Glyphs RenderTransform="0.0646215,0,0,0.0644991,0,0" Fill="#ff000000" FontUri="/Documents/1/Resources/Fonts/FF418D14-C0F5-49FA-8F94-42C185369528.odttf" FontRenderingEmSize="327.68" StyleSimulations="None" OriginX="836.8" OriginY="1929.92" Indices="53,59;82,60;82,59;80,62;3,58;20" UnicodeString="Room 1" />
The reason you are seeing this unintuitive behavior can be determined by a careful (if painful) reading of the XPS standard. You are comparing the OriginY values of two sets of glyphs. Per the spec, section 12.1, OriginY is specified in the effective coordinate space. A bit further down, it mentions that RenderTransform establishes a new coordinate frame for the glyph run, and in so doing, it affects the origin x and origin y of the glyphs.
To determine the actual coordinates of the glyphs on the page, you need to apply the render transform to the OriginX and OriginY. An explanation of how the RenderTransform works can be found in section 14.4.1
For this specific example, it is possible to recover the actual coordinates of the glyphs by multiplying the OriginX by the first value in the RenderTransform, and OriginY by the fourth value in the RenderTransform. This will not hold true in all cases as the fifth and sixth values may specify additional x and y offsets, and the second and third values can introduce skew and rotation effects as well.
I'm currently working on a Object Detection project using Matterport MaskRCNN.
As part of the job is to detect a Green leaf that crosses a white grid. Until now I have defined the annotation (Polygons) in such a way that every single leaf which crosses the net (and gives white-green-white pattern) is considered a valid annotation.
But, when changing the definition above from single-cross annotation to multi-cross (more than one leaf crossing the net at once), I started to see a serious decrease in model performance during testing phase.
This raised my question - The only difference between the two comes down to size of the annotation. So:
Which of the following is more influential on learning during MaskRCNN's training - pattern or size?
If the pattern is influential, it's better. Because the goal is to identify a crossing. Conversely, if the size of the annotation is the influencer, then that's a problem, because I don't want the model to look for multi-cross or alternatively large single-cross in the image.
P.S. - References to recommended articles that explain the subject will be welcomed
Thanks in advance
If I understand correctly the shape of the annotation becomes longer and more stretched out if going for multicross annotation.
In that case you can change the size and side ratio of the anchors that are scanning the image for objects. With default settings the model often has squarish bounding boxes. This means that very long and narrow annotations create bounding boxes with a great difference between width and height. These objects seem to be harder to segment and detect by the model.
These are the default configurations in the config.py file:
Length of square anchor side in pixels
RPN_ANCHOR_SCALES = (32, 64, 128, 256, 512)
Ratios of anchors at each cell (width/height). A value of 1 represents a square anchor, and 0.5 is a wide anchor
RPN_ANCHOR_RATIOS = [0.5, 1, 2]
You can play around with these values in inference mode and look if it gives you some better results.
In coding this can easily be accomplished with a conditional loop and/or a custom function. But how would this be done in Fusion360?
What if I created a parametric design of a drawer having dovetails. How would the number of dovetails be increased or decreased based on a changing User Parameter? For example, changing the dimension of the User Parameter of Height from 5" to 8" - how can this also increase the number of dovetails on each side of the drawer?
Say I've created a drawer with several User Parameters used for creating the dimensions of the drawer - (Width, Height, & Depth). The drawer's four sides - (face, right, left, back) are created as separate components and are then given dimensions from the User Parameters.
Any change to the dimension of a User Parameters is then parametrically applied to the dimensions of each of the four sides of the drawer. For example, a change in dimension of User Parameter, Height, then changes the heights of all four sides of the drawer. Those other dimensions derived from the unchanged User Parameters (Width and Depth) remain the same.
Next the dovetails are created. The easiest way is to create a single dovetail by dimension. Once create, the dovetail can be easily placed on the ends of each all four sides. But then what?
It's much trickier to create User Parameters for the dimensions of the dovetail - including the distance between dovetails. It's completely unknown how to create x number of dovetails- with that number being dependent upon the height of the drawer.
For this you can use functions for rounding (round, floor, ceil)
Here is an example https://a360.co/2UimVKh
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.
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.