In the H3 library, you can find the corse parent index of a H3 hexagon using the h3ToParent method. Is the corse parent the same as the parent? If not how do I find the true parent index?
The H3 docs generally use "coarse" to indicate larger-hex resolutions with lower numbers (e.g. res 1 hexes, 607,220km2), and "fine" to indicate smaller-hex resolutions with higher numbers (e.g. res 10 hexes, 0.015km2). This is to avoid confusion with "bigger"/"smaller" terminology (is a bigger resolution a large hex or a larger res number?).
The h3ToParent method can return the direct parent of a hexagon (i.e. the coarser hexagon that contains it at the next resolution up), or its ancestor at any given coarser resolution - the second argument specifies the resolution of the parent you want to obtain.
In this image, for example, all of the larger hexagons are "parents" of the smallest hexagon in the center. If the resolution of the center hex is 7, then:
H3Index directParent = h3ToParent(centerHex, 6);
H3Index grandParent = h3ToParent(centerHex, 5);
// etc
Related
How do I set the texture of a SCNText object? This is what I have and nothing changes in the appearance:
// myNode is a working SCNText element
let mat = SCNMaterial()
met.diffuse.contents = UIImage(contentsOfFile: "texture.png")
myNode.geometry.firstMaterial = mat
A text geometry may contain one, three, or five geometry elements:
If its extrusionDepth property is 0.0, the text geometry has one element corresponding to its one visible side.
If its extrusion depth is greater than zero and its chamferRadius property is 0.0, the text geometry has three elements, corresponding to its front, back, and extruded sides.
If both extrusion depth and chamfer radius are greater than zero, the text geometry has five elements, corresponding to its front, back, extruded sides, front chamfer, and back chamfer.
Scene Kit can render each element using a different material. For details, see the description of the materials property in SCNGeometry Class Reference.
just like for any other geometry, simply set its materials property.
I have a set of m non-rotated, integer (pixel) aligned rectangles, each of which may or may not overlap. The rectangles cover thousands of pixels. I need to find the minimum sized bounding box that covers all areas that are covered by n of the m rectangles.
A (dirty) way of doing this is to paint a canvas that covers the area of all the targets. This is O(mk) where m is the number of rectangles and k is the number of pixels per rectangle. However since k is much greater than m I think there is a better solution out there.
This feels like a dynamic programming problem...but I am having trouble figuring out the recursion.
Solution which is better but still not great:
Sort the start and end points of all the rectangles in the X direction O(mlogm), iterate and find the x positions that may have over n rectangles, O(m) loop. For each x position that may have over n rectangles, take the rectangles at that position and sort the starts and stops at that position (O(mlogm)). Find the region of overlap, keep track of the bounds that way. Overall, O(m^2logm).
Hello MadScienceDreams,
Just to clarify, the bounding box is also non-rotated, correct?
If this is the case, then just keep track of the four variables: minX, maxX, minY, maxY–representing left-most, right-most, top-most, and bottom-most pixels–that define the bounding box, loop through each of the rectangles updating the four variables, and defining the new bounding box given those four variables.
EDIT
It looks like you are asking about finding the bounds of some subset of rectangles, not the whole set.
So you have M rectangles, and you choose N rectangles from them, and find the bounds within that.
Even in this situation, looping through the N rectangles and keeping track of their bound would be at most O(m), which isn't bad at all.
I feel that I must be misunderstanding your question since this response isn't what you are probably looking for; is your question actually trying to ask how to precompute the bounds so that given any subset, know the total bounds in constant time?
Is this defines your question? For bounding box => #rect_label >= n
How about we starts with one box and find the next box that has nearest furthest corner from it. Now we have a region with two box. Recursively find the next region, until we have n boxes.
While we need to start on every box, we only need to actively work on the currently smallest regions. The effect is we start from the smallest cluster of boxes and expand out from there.
If n is closer to m than 0, we can reverse the search tree so that we start from the omni-all-enclosing box, chopping off each bordering box to create the next search level. Assuming we only actively work on the smallest remaining region, effect is we chop off the emptiest region first.
Is it too complicated? Sorry I can't remember the name of this search. I'm not good at maths, so I'll skip the O notation. >_<
I propose the following algorithm :
prepareData();
if (findBorder('left')) {
foreach (direction in ['top', 'right', 'bottom']) {
findBorder(direction)
}
} else noIntersectionExists
prepareData (O(mlogm)):
Order vertical bounds and horizontal bounds
Save the result as:
- two arrays that point to the rectangle (arrX and arrY)
- save the index as a property of the rectangle (rectangle.leftIndex, rectangle.topIndex, etc.
findBorder(left): // the other direction are similar
best case O(n), worst case O(2m-n)
arrIntersections = new Array;
//an intersection has a depth (number of rectangles intersected), a top and bottom border and list of rectangles
for(i=0; i < 2*m-n-1; i++){ // or (i = 2*m-1; i > n; i--)
if(isLeftBorder(arrX[i])){
addToIntersections(arrX[i].rectangle, direction);
if(max(intersections.depth) = n) break;
} else {
removeFromIntersections(arrX[i].rectangle, direction);
}
}
addToIntersections(rectangle, direction): // explanations for direction=left
Best case: O(n), worst case: O(m)
hasIntersected = false;
foreach(intersection in intersection){
if(intersect(intersection, rectangle)){
hasIntersected = true
intersections[] = {
depth: intersection.depth,
bottom: min(intersection.bottom, rectangle.bottom),
top: max(...)}
intersection.depth++
intersection.bottom = max(intersection.bottom, rectangle.bottom)
intersection.top = max(...)
}
}
if(!hasIntersected)
intersections[]={depth:1, bottom:rectangle.bottom, top:rectangle.top}
This gives an overall order between O(n^2) and O(m*(m-n/2))
I hope my pseudo code is clear enough
I'm working on an autonomous rover that navigates partially by ultrasound proximity sensors. Before we implement the hardware we want to do some testing of our algorithms with a simulator, which I am now writing.
One task that I'm having some trouble with is that the ultrasound sensor has a 60 degree field of view. If an object is detected, any point along that 60 degree arc at that radius may have an object, but all points below that radius are guaranteed not to have an object.
What I need to do is write a function that is given an (x,y) coordinate and a bearing (I'm restricting this to the 4 cardinals for now) and have it return to me a list of pixels within a radius and a list of pixels at that radius. With repeated scans from multiple locations and bearings all objects can be found.
My initial thought was to work iterative-ly. Start at the row in front of the sensor and sweep back and forth in progressively wider scans (1,1,3,3,5,5,7,7,etc). However eventually the radii stop aligning with the rows. My new search path would be to figure out how to draw an arc with pixels, then step the radius up to the first collision.
This question asks a similar question, but is only interested in specific points so I believe it is a fundamentally different problem.
how to calculate all points(longitude,latitude) within a given radius from given point (longitude,latitude)?
You can use any Floodfill method to get all integer points in the sector.
Precalculate starting and ending angles as
S_Angle = Center_Bearing - Pi/6
E_Angle = Center_Bearing + Pi/6
Important values:
S_Cos = Cos(S_Angle)
S_Sin = Sin(S_Angle)
E_Cos = Cos(E_Angle)
E_Sin = Sin(E_Angle)
Border conditions for sector floodfill:
(x-x0)*S_Sin-(y-y0)*S_Cos >= 0 //point is left to starting ray
(x-x0)*E_Sin-(y-y0)*E_Cos <= 0 //point is right to ending ray
(x-x0)^2+(y-y0)^2 <= R^2 //point is in the range
(probably you may need to exchange >= and <= in the first inequalities pair)
I'm writing a cocos2d-x application. I have a sprite with a couple of child sprites over it. These sprites represent one logical object on the screen that is transformed as a whole object. Now, when the object is touched, I need to discover which of the child sprites was touched.
The problem is that, while the parent sprite gives me all the information (bounding box, scale, rotation etc.) as it currently is, the child sprites stay with their original numbers, despite being transformed together with the parent, and I cannot figure out the correct way to calculate the "real" dimensions for the children.
As it looks to me, two facts cause all the difficulties:
The child bounding box has its initial dimensions which are reported relative to the parent's initial bounding box.
I cannot calculate the parent's initial bounding box after the parent was rotated (see the picture below), thus I cannot calculate where now is the lower left corner of the parent sprite, which I need as the relation point for child transformations.
Here's a drawing of such a situation:
So, to summarize, in order to check whether a touch hit a child sprite, I need to calculate the current bounding box of the children, based on the parent's transformations. I can calculate the scaling and the rotation of the child, but I don't know where it should be positioned relative to the parent because the parent's bounding box is very different from what it was in the beginning. Add weird anchor points to the story and it becomes even more complicated. The perfect solution would be to get the vertices of the original sprite and not the bounding box. Is it possible?
Any ideas? Am I missing something?
The source code of boundingBox() maybe helpful. You can get the affinetransform by nodeToParentTransform(),and use CCPointApplyAffineTransform to get the new position of the four points. Then you can write a new method to check if the touch locate in the new rect.
Assume you Have a parent
CCSprite* parent;
and a Child,
CCSprite* child; //child Tag is 100
you can give it a try in your touch method:
YOUR_CLASS::ccTouchBegan(CCTouch* pTouch, CCEvent* pEvent){
CCPoint touchLocation = parent->convertTouchToNodeSpace(pTouch);
if (CCRect::CCRectContainsPoint(parent->getChildByTag(100)->boundingBox(),touchLocation)){
//do something
CCLOG("touch on child");
}
}
If someone wants to find out the letters bounding boxes in a rotated label:
int maxIdx = label->getStringLength() -1;
Mat4 trans = label->getNodeToParentTransform();
for(int idx = 0; idx<=maxIdx; idx++) {
Sprite* letter = label->getLetter(idx);
Rect letterRect = letter->getBoundingBox();
Point p = PointApplyTransform(letterRect.origin, trans);
Rect rect = Rect(p.x, p.y, 10, 10); // Letter Approximation rect
}
I have code that needs to render regions of my object differently depending on their location. I am trying to use a colour map to define these regions.
The problem is when I sample from my colour map, I get collisions. Ie, two regions with different colours in the colourmap get the same value returned from the sampler.
I've tried various formats of my colour map. I set the colours for each region to be "5" apart in each case;
Indexed colour
RGB, RGBA: region 1 will have RGB 5%,5%,5%. region 2 will have RGB 10%,10%,10% and so on.
HSV Greyscale: region 1 will have HSV 0,0,5%. region 2 will have HSV 0,0,10% and so on.
(Values selected in The Gimp)
The tex2D sampler returns a value [0..1].
[ I then intend to derive an int array index from region. Code to do with that is unrelated, so has been removed from the question ]
float region = tex2D(gColourmapSampler,In.UV).x;
Sampling the "5%" colour gave a "region" of 0.05098 in hlsl.
From this I assume the 5% represents 5/100*255, or 12.75, which is rounded to 13 when stored in the texture. (Reasoning: 0.05098 * 255 ~= 13)
By this logic, the 50% should be stored as 127.5.
Sampled, I get 0.50196 which implies it was stored as 128.
the 70% should be stored as 178.5.
Sampled, I get 0.698039, which implies it was stored as 178.
What rounding is going on here?
(127.5 becomes 128, 178.5 becomes 178 ?!)
Edit: OK,
http://en.wikipedia.org/wiki/Bankers_rounding#Round_half_to_even
Apparently this is "banker's rounding". I have no idea why this is being used, but it solves my problem. Apparently, it's a Gimp issue.
I am using Shader Model 2 and FX Composer. This is my sampler declaration;
//Colour map
texture gColourmapTexture <
string ResourceName = "Globe_Colourmap_Regions_Greyscale.png";
string ResourceType = "2D";
>;
sampler2D gColourmapSampler : register(s1) = sampler_state {
Texture = <gColourmapTexture>;
#if DIRECT3D_VERSION >= 0xa00
Filter = MIN_MAG_MIP_LINEAR;
#else /* DIRECT3D_VERSION < 0xa00 */
MinFilter = Linear;
MipFilter = Linear;
MagFilter = Linear;
#endif /* DIRECT3D_VERSION */
AddressU = Clamp;
AddressV = Clamp;
};
I never used HLSL, but I did use GLSL a while back (and I must admit it's terribly far in my head).
One issue I had with textures is that 0 is not the first pixel. 1 is not the second one. 0 is the edge of the texture and 1 is the right edge of the first pixel. The values get interpolated automatically and that can cause serious trouble if what you need is precision like when applying a lookup table rather than applying a normal texture. You need to aim for the middle of the pixel, so asking for [0.5,0.5], [1.5,0.5] rather than [0,0], [1, 0] and so on.
At least, that's the way it was in GLSL.
Beware: region in levels[region] is rounded down. When you see 5 % in your image editor, the actual value in the texture 8b representation is 5/100*255 = 12.75, which may be either 12 or 13. If it is 12, the rounding down will hit you. If you want rounding to nearest, you need to change this to levels[region+0.5].
Another similar thing (already written by Louis-Philippe) which might hit you is texture coordinates rounding rules. You always need to hit a spot in the texel so that you are not in between of two texels, otherwise the result is ill-defined (you may get any of two randomly) and some of your source texels may disapper while other duplicate. Those rules are different for bilinar and point sampling, you may need to add half of texel size when sampling to compensate for this.
GIMP uses banker's rounding. Apparently.
This threw out my code to derive region indicies.