Rectangles are located in a doubly-linked list. In this context, a rectangle is a figure, formed using a data of the rectangle's structure (no matter how).
struct rect {
int l; /* left */
int t; /* top */
int r; /* right */
int b; /* bottom */
};
Its fields has the strict positions (I guarantee it for any rectangle).
[l; t] [r; t]
+------+
| |
| |
+------+
[l; b] [r; b]
Rectangles are stored in objects.
struct object {
struct rect *rect;
bool selected;
};
And objects are stored in the list's nodes.
struct node {
struct object *obj;
struct node *next;
struct node *prev;
};
Rectangles draws consistently, beginning from the list's head -- first draws a rectangle, closer to the beginning of the list. Thereby, an each next figure overlaps previous figures.
I select rectangles, with a selection rectangle, that forms by mouse cursor. The selection check is done, during iterating over the list from the end.
struct node *node = getend(list);
struct object *obj;
do {
obj = node->obj;
/* Check, if a selection rectangle somehow
* intersects with a rectangle of the current
* object. */
if (rcheck(sel_rect, obj->rect))
obj->selected = true;
}
while ((node = node->prev));
Take a look to the demonstration of my problem, a little below.
As you can see, the selection rectangle selects two rectangles: yellow and green. In this case, only the yellow figure should be selected; in general -- if behind a forward rectangle another figure is located (a backward rectangle), and a selection rectangle does not cover a "visible" part of this figure (on the animation it's the green polygon, formed by overlapping the yellow figure), but covers its "hidden" part, then a backward rectangle should not be selected.
A forward rectangle means, that it's located closer to the end of the list; a backward rectangle - that it's located closer to its beginning.
This alrogithm is used in game's two-dimensional map editor, for rectangular textures selection.
Five different approaches:
Screen Space Selection
Render the rectangles from back to front order onto a temporary array/grid of "pixels", but using "rectangle ID" instead of colors. Use the selection rectangle to select "pixels" and examine them to determine the "rectangle IDs" for selected rectangles. This is likely to be the simplest option (and likely to have the worst performance).
Selection Rectangle Subdivision
Search from front to back (like you are); but when you find a rectangle that overlaps the selection rectangle use its edges to split the selection rectangle up into sub-rectangles and discard sub-rectangles that overlap the found rectangle. This will leave you with zero to 8 sub-rectangles that don't overlap the found rectangle. Repeat this process using each of the resulting sub-rectangles (instead of the original selection rectangle) to find more rectangles that were selected. Note that (for "worst case") the number of sub-rectangles can increase by 7 for each rectangle selected.
Rectangle List Subdivision
Pre-process the list of rectangles using the edges of front rectangles to sub-divide any back-polygons, and discard any overlapping sub-rectangles; so that the resulting list of rectangles no longer contains anything that overlaps. After this; find all (sub)rectangles that overlap with the selection rectangle. Note that this is nicer if the list of rectangles doesn't change often and the same "pre-processed list of rectangles" can be re-used many times.
Selection Polygon Subtraction
Assume the selection area is an arbitrary shape with N vertices and N sides, which just happens to be 4 vertices and 4 sides in the beginning. Search from front to back (like you are); but when you find a rectangle that overlaps the selection polygon subtract the overlapping areas from the selection polygon. This is incredibly complicated; partly because the selection polygon can be split into "separated/non-touching" pieces and/or can become "donut like". This can be combined with the previous approach - e.g. use the edges of the overlapping rectangle to split the selection polygon into sub-polygons, then discard overlapping sub-polygons, then merge sub-polygons that share a common edge to reduce the number of sub-polygons.
Rectangle List Subtraction
Pre-process the list of rectangles (and convert them all into arbitrary shaped polygons) using a similar approach to "Selection Polygon Subtraction". After this; find all (sub)polygons that overlap with the selection rectangle. Note that this is nicer if the list of rectangles doesn't change often and the same "pre-processed list of polygons" can be re-used many times.
Notes
There's more advanced techniques for polygon subtraction than the "split then merge if you can" approach I described, which are much more complicated and give better performance. For one research paper, see https://www.pnnl.gov/main/publications/external/technical_reports/PNNL-SA-97135.pdf
Myself, I'd probably use the "Selection Rectangle Subdivision" approach if the highest possible performance isn't a necessity (and if the list of rectangles changes more often than the selection rectangle).
I though of the solution myself, and it turned out to be a little more difficult, than I expected. And it took me a while.
The method of the list traversing wasn't changed -- I do the selection check for each node from front to back.
First, I select root rectangle (first rectangle, intersecting with the selection). Next, if other rectangles intersecting, they are checked on intersecting with root to make sure they aren't just aside.
I memorize rectangles between r (the current rectangle) and root (including root) -- it will be needed for the further checks. Rectangles are stored in rect_list (in another list).
Traversing this list starts. On this moment, I firstly check r and sr (a node's rectangle) aren't intersecting together, and store their intersection in ir. Also, the selection rectangle should intersect ir.
if (!rintersect(r, sr, ir))
continue;
if (!rcheck(sel_rect, ir))
continue;
Now, I scan the area around ir -- points of each side of rectangle with coordinates:
struct rect scan_area {
ir.l - 1,
ir.t - 1,
ir.r + 1,
ir.b + 1
};
to check for a point in current rectangle and in the selection, but not in all memorized rectangles (list_check does this).
bool l = false;
bool t = false;
bool r = false;
bool b = false;
struct point p;
int i;
for (i = ir.l; i <= ir.r; i++) {
p.x = i;
p.y = ir.t - 1;
if ((t = list_check(rect_list, p))
break;
p.y = ir.b + 1;
if ((b = list_check(rect_list, p))
break;
}
for (i = ir.t; i <= ir.b; i++) {
if (t || b)
break;
p.y = i;
p.x = ir.l - 1;
if ((l = list_check(rect_list, crd))
break;
p.x = ir.r + 1;
if ((r = list_check(rect_list, crd))
break;
}
if ((obj->selected = l || t || r || b))
break;
I wouldn't say this alrogithm highly inefficient, comparing it with the first Brendan's proposed way: screen space selection, because I need to check all rectangles, firstly; check all pixels of these rectangles, including each pixel of the selection, secondly.
Objectively, this alrogithm isn't fast (O(n^3)). However, it isn't noticeable within my task.
Related
Very complicated for me to explain the problem, but I will try my best.
I am making a game. There is an area of game objects and a canvas that draws every object in that area using some "draw_from" function - void draw_from(const char *obj, int x, int y, double scale) so that it looks as if a copy of that area is made on-screen.
This gives the advantage of scaling that area using the scale parameter of the draw_from() function.
However, a problem occurs when doing so. For simplicity imagine there are just two actors in that area - one that is right above the other one.
When they are scaled-down, they will appear in different vertical positions, further from each other.
I need to calculate the new correct positions for each of the objects and pass them to draw_from, but I just seem to be unable to figure out how. What is the correct way to recalculate the new positions if each of those objects is scaled down with the same value?
Here is a decent illustration of the problem more or less:
As you can tell the draw_from function will draw the object centered on the x/y coordinates. To draw an object at 0:0 (top-left corner) you must do draw_from(obj, obj->width/2, obj->height/2, 1.0); Not sure if the scaling is implemented that way exactly, but I created a function to obtain the new width and height of the scaled object:
void character_draw_get_scaled_dimensions (Actor* srcActor, double scale, double* sWidth, double* sHeight)
{
double sCharacterWidth = 0;
double sCharacterHeight = 0;
if(srcActor->width >= srcActor->height)
{
sCharacterWidth = (double)srcActor->width * scale / 1.0;
sCharacterHeight = sCharacterWidth * (double)srcActor->height / (double)srcActor->width;
}
else
{
sCharacterHeight = (double)srcActor->height * scale / 1.0;
sCharacterWidth = sCharacterHeight * (double)srcActor->width / (double)srcActor->height;
}
if(sWidth)
(*sWidth) = sCharacterWidth;
if(sHeight)
(*sHeight) = sCharacterHeight;
}
In other words, I need to maintain the distances between those objects across down-scales and I explained how draw_from and /somehow/ how its scaling works.
I need the correct parameters to pass to the draw_from's x and y arguments.
From that point, I think it will get just too broad if I continue elaborating further.
Not the solution I hoped for, but it is still a solution.
The more hacky and less practical (including performance-wise) solution is to draw every object on an offscreen canvas with a scale of 1.0 then draw from that canvas to the main canvas at any scale desired.
That way only the canvas should be repositioned and not every object. It gets really easy from there. I still would prefer the conventional purposed mathematical solution.
I'm working on a program in which I need to find all lines which are in a circles located at some cartesian point of some radius.
At the moment, for every circle, I am iterating over all the lines and checking if the line enters/contacts the circle at any point.
The code essentially looks like this.
for (int i = 0; i < num_circles; i++)
{
for (int j = 0; j < num_lines; j++)
{
if(lineIntersectWithCircle(circle[i], lines[j]))
{
//Append line[j] to a list of lines intersecting with circle[i];
//some code
}
}
}
I've been thinking of many way to optimize this, but I'm having trouble.
I have sorted the circles by minimum Cartesian distance and sorted lines by maximum distance away. This way you can somewhat optimize, but it's quite minimal because once you reach the point where line[j].max > circle[i].min, you still have to iterate through all the rest of the lines.
I am fine with my intersection checking method, I just would like to minimize the amount of times I need to call it.
Is there a good way of doing this?
Cheapest way is just check the bounding extents/rectangles of the two shapes (line and circle) prior to the more expensive intersection test. Chances are that you can even compute the extents on the fly of the line/circle, not precompute, and still get a decent performance boost unless your line/circle intersection is already dirt cheap.
A really effective approach but one that requires a bit more work is to just create a grid. You can use the bounding rectangles computed above to cheaply see which grid cells your shapes intersect.
struct GridNode
{
// Points to the index of the next node in the grid cell
// or -1 if we're at the end of the singly-linked list.
int next_node;
// Points to the index of the shape being stored.
int shape;
};
struct GridCell
{
// Points to the first node or -1 if the cell is empty.
int first_node;
};
struct Grid
{
// Stores the cells in the grid. This is just illustrative
// code. You should dynamically allocate this with adjustable
// grid widths and heights based on your needs.
struct GridCell cells[grid_width * grid_height];
// Stores the nodes in the grid (one or more nodes per shape
// inserted depending on how many it intersects). This is
// a variable-sized array you can realloc needed (ex: double
// the size when you're out of room).
struct GridNode* nodes;
// The maximum number of nodes we can store before realloc.
int node_cap;
// The number of nodes inserted so far. realloc when this
// exceeds node_cap.
int node_num;
};
... something to this effect. This way, most of the time you can insert elements to the grid doing nothing more than just some integer (emulating pointers) operations and adding some grid node entries to this variable-sized nodes array. Heap allocations occur very infrequently.
I find in practice this outperforms quad-trees if you have many dynamic elements moving from one cell to the next like in a 2D video game where everything is moving around all the time while we need rapid collision detection, and can even rival quad-trees for searching if you are careful with the memory layout of the nodes to minimize cache misses when iterating through grid cells that intersect the shape you are testing against. You can even do a post-pass after the grid is constructed to rearrange the memory of each node for cache-friendly list iteration based on how efficient you need the intersection searches to be. If you want to get fancy, you can use Bresenham to figure out exactly what grid cells a line intersects, e.g., but given the quadratic complexity of what you're doing, you stand to improve exponentially without bothering with that and just doing it in a very simple way with bounding rectangles.
Basically to find an intersection, first grab the bounding rect of the shape. Then see which cells it intersects in the grid. Now check for intersection with the shapes contained in the grid cells the original shape intersects. This way you can work towards constant-time complexity except for gigantic shapes (worst-case with O(n)) which are hopefully a rare case.
I even find use for these in 3 dimensions when things are moving around a lot. They're often cheaper than the octree, BVH, and kd-tree variants which provide extensive search acceleration but at the cost of more expensive builds and updates, and if you use this strategy of a singly-linked list for each grid cell which doesn't have to individually allocate nodes, you can store it in a very reasonable amount of memory even with the 3rd dimension. I wouldn't use a 3-dimensional version of this for raytracing, but it can be very useful for 3D collision detection, like detecting collision between particles moving every single frame.
As with anything it depends on your use case. If you have a fixed number of lines or infrequently added, you may want to precompute some of the calculations needed to find out if any part of the line is within radius distance of the center of the circle
Starting with the equation for the shortest distance between a line and a point and comparing that distance is less than the radius of the circle:
//abs(Cx*(y1-y0)-Cy*(x1-x0)+x1*y0-y1*x0)/sqrt((y1-y0)*(y1-y0)+(x1-x0)*(x1-x0))<R
//pull out some constants and cache these as they are initialized
//int y10 = y1-y0, //add to the line struct
// x10 = x1 -x0,
// delta = x1*y0-y1*x0,
// sides = (y10)*(y10)+(x10)*(x10);
// R2 = R*R; //add to the circle struct
//now the equation factors down to
//abs(Cx*(y10)-Cy*(x10)+delta)/sqrt(sides)< R //replace constants
//abs(Cx*(y10)-Cy*(x10)+delta) < sqrt(sides) * R //remove division
//pow(Cx*(y10)-Cy*(x10)+delta , 2.0) < sides * R * R //remove sqrt()
//int tmp = Cx*(y10)-Cy*(x10)+delta //factor out pow data
//tmp * tmp < sides * R2 //remove pow() and use cache R squared
//now it is just a few cheap instructions
Now the check should be just 4 integer multiplies, 2 add/subtract and a compare.
lineIntersectWithCircle(size_t circle, size_t line){
struct circle C = circle_cache[circle]; //these may be separate arrays
struct line L = line_cache[line]; //from your point data
long tmp = C.x * L.y10 - C.y * L.x10 + L.delta;
return (tmp*tmp < L.sides * C.R2);
}
... but you may want to check my math - its been a while. Also I assumed the points would be integers - change to float as needed - it should still be relatively fast.
If that isn't fast enough you can add additional data for the bounding boxes of the circle and line
bool lineIntersectWithCircle(size_t circle, size_t line){
struct circle C = circle_cache[circle]; //these may be separate arrays
struct line L = line_cache[line]; //from your point data
//if the bounding boxes don't intersect neither does the line
//this may not be _that_ helpful and you would need to:
// figure out the bounding boxes for each line/circle
// and cache additional data
if (C.leftx > L.rightx || L.leftx > C.rightx) //a box is to the side
return 0;
if (C.topy < L.boty || L.topy < C.boty) //a box is below/above
return 0;
//the bounding boxes intersected so check exact calculation
long tmp = C.x * L.y10 - C.y * L.x10 + L.delta;
return (tmp*tmp < L.sides * C.R2);
}
I am a beginner programmer that is working on elementary tests for myself to grasp core values of working with C. I have a test case and don't really know where to begin in structuring it for compiling with GCC. I have a basic theory and pseudocode summary but mainly needing a little help stepping forward.
I have googled the related questions and permutations to this question and have been unable to make heads or tails of the logic for C.
Given the following logic:
Using the C language, have the function OverlappingRectangles(strArr)
read the strArr parameter being passed which will represent two
rectangles on a Cartesian coordinate plane and will contain 8
coordinates with the first 4 making up rectangle 1 and the last 4
making up rectange 2. It will be in the following format:
"(0,0),(2,2),(2,0),(0,2),(1,0),(1,2),(6,0),(6,2)." Your program should
determine the area of the space where the two rectangles overlap, and
then output the number of times this overlapping region can fit into
the first rectangle. For the above example, the overlapping region
makes up a rectangle of area 2, and the first rectangle (the first 4
coordinates) makes up a rectangle of area 4, so your program should
output 2. The coordinates will all be integers. If there's no overlap
between the two rectangles return 0.
I'm lost.
Should have added this at first:
Given a string(n1,n2,n3,n4,m1,m2,m3,m4)
Split string into string1(n1,n2,n3,n4) string2(m1,m2,m3,m4)
If n1+n4 < m1 or n2+n3 < m2 or m1+m4 < n1 or m2+m3 < m1
Calculate area of intersecting rectangle and divide into area of first rectangle.
Else
Print 0
You have a string of the form:
(x1,y1)(x2,y2)(x2,y1)(x1,y2)(x3,y3)(x4,y4)(x4,y3)(x3,y4)
defining 2 rectangles:
r1 = (x1,y1) to (x2,y2)
r2 = (x3,y3) to (x4,y4)
You need to first:
define a representation (structure) for the rectangles
parse (read) the string to extract the numbers for x1-x4 and y1-y4 -- look at e.g. sscanf and its return value for doing this
You can create a helper function, e.g.:
const char *parse_rectangle(const char *str, rectangle *r);
That will read a rectangle r from str in the form (x1,y1)(x2,y2)(x2,y1)(x1,y2)(x3,y3) (including any validation) and return a pointer to the next character.
Now, you will have two rectangles.
You can then compute the intersection of these rectangles as a third rectangle, e.g.:
int intersection(const rectangle *r1, const rectangle *r2, rectangle *result);
which will return 1 if the rectangles intersect, or 0 if they don't and fill result with the intersection. If you are using C99, you can use _Bool instead.
Now, you need a function to compute the area, e.g.:
int area(const rectangle *r);
You can pass this through the intersected rectangle and the first rectangle to get the areas of both.
Now, you simply divide the first rectangle area by the intersected rectangle area and print the result.
I have got a four 2d vertices A B C D of rotated rectangle,
I need to rasterize/draw it (efficiently) in pixelbufer
with setpixel(x,y,color)
how to do it?
i was trying with some code like
// convertilg a b c d do up down left right,
// calculating some dx_left dx_right on y--
// etc (frustrating on special cases when there are 2 up_y vertices in same line etc)
for(;;)
{
drawhorizontalline(y, xstart, xend, color);
if(y==downy) break;
y--;
xstart+=dxstart;
xend+=dxend;
if(y==lefty) dxstart = dxright;
if(y==righty) dxend = dxleft;
}
but it is most frustrating (terribly bug prone and most frustrating)
i am really tired of debuging this all day yesterday and i need to find
maybe some working code rather than to try to debug this
To fill your rectangle handle it as closed convex polygon (almost the same as triangle filling)
order your points to match winding rule
so there are lines AB BC CD DA or reverse
create left and right buffer
address is y-coordinate, its an array of x-positions and if needed also array of color,texture coordinates,.... for starters:
int buf_x0[ys],buf_x1[ys];
where ys is screen y-resolution
implement any draw line algorithm
but instead of draw to screen just store x coordinate of pixel to buffer.
instead of: setpixel(x,y,color); do: buf_x?[y]=x;.
Which buffer is the destination depends on the line Y direction
if dy<0 then fill buff_x0
if dy>0 then fill buff_x1
if dy==0 then buf_x0[y]=min(x) and buf_x1[y]=max(x)
Beware you have to sort the line endpoints by x coordinate before rasterizing to avoid seams/holes in meshes caused by different pixels produced for reversed endpoints lines.
apply this line algorithm to all border lines of polygon (AB,BC,CD,DA)
after this the buffers contains start and end x-positions of your horizontal lines
fill the rectangle on screen
for (y=min(Ay,By,Cy,Dy);y<=max(Ay,By,Cy,Dy);y++)
draw_horizontal_line(y,buf_x0[y],buf_x1[y],color);
Image for clarity (taken from my lectures on low level computer graphics)
image description:
vertical rectangles represents the border buffers buf_x0[],buf_x1[]
clockwise winding rule ensures the destination buffer. If its coded properly than buf_x0[y] <= buf_x1[y] so draw of horizontal line colapses to single for loop
Also se these:
simple 2D raster C++ example of mine
simple 3D voxel grid C++ example of mine
This is for a Terrain Generation and rendering program.
I have a loop that looks like this:
x = -MAX_SIGHT_DISTANCE;
y = -MAX_SIGHT_WIDTH;
while (x < MAX_SIGHT_DISTANCE)
{
while (y < MAX_SIGHT_WIDTH)
{
value = noise2d(x+camera.x, y+camera.y);
if (pointInFrustum(x-camera.x, y-camera.y, value, direction, FOV, MAX_SIGHT_DISTANCE) == 1)
{
// TODO: STORE VALUE TO AN ARRAY....SOMEHOW...
}
dz = value-camera.z;
distance = sqrt(x*x + y*y + (dz)*(dz));
x += DISTANCE_FUNCTION(distance);
y += DISTANCE_FUNCTION(distance);
}
}
It's supposed to find a semi-random height value at different resolutions: Much higher resolution up close, and lower resolution farther away.
Later,
for x
{
glBegin(GL_TRIANGLE_STRIP);
for y
{
glVertex(x, y);
glVertex(x+1, y);
}
glEnd();
}
This is supposed to be the rendering code (in pseudo-code, of course).
I have to specify the coordinates of each point. I'd really like to use triangle strips here, so I need to have all points in one strip following each other.
Comes my question: How do I store these points? In python I'd create a list, and then just render everything in the list.
Problem is this is in C, arrays aren't dynamic. So I need a size. How can I know that size? How can I loop through it in an intelligent way (since it has variable widths)? And how can I prevent stuff like the end of one row joining with the beginning of another row?
Or am I doing the whole thing wrong?
How about you use a dynamic data structure like a stack of linked-lists?
Each linked list would hold the points for each triangle strip.
The stack would contain the a linked list for each triange strip.
Linked list would suit your problem because you dont really need to index your elements.