For a school assignment we have to make a graph editor like the next one (given example):
Most of the assignment goes well, we're stuck on one point: drawing the edges between vertices. In the given example, the lines are nicely drawn from points relatively close to the connecting vertex. For example the top one has two lines on its bottom edge, one more to the left and one more to the right.
We are not sure on how to let the drawing of the lines keep the positions of the connecting vertex in account and how to adjust the positions of the beginning and end points on that (what calculations to make). Can someone help out?
In fact, that's rather simple: Draw the lines first, from the position of each vertex to the position of the respective other vertex (the "position" here refers to the center of the rectangle). Afterwards, draw the rectangles for the vertices. They will be painted over the edges, and the result will look exactly like the screenshot.
If you extend the connector lines, you can see they are drawn from the geometric center of the graph node rectangles:
Since you already seem to have a good positioning algorithm for your nodes, all you need to do is draw the connector lines first. Then draw the node rectangles on top of them.
Related
I have a َquestion about the graphstream library
I want to write a program that counts the number of intersections between the nodes that are represented as a square with a specified size.
The main Problem is that, the nodes will be visualized as squares but if the coordinates of these nodes are just points x,y and here is exactly my Problem, because I want to check the intersections with the edges with the x,y coordinates but I can not do this properly!
because in some cases the corner of the square or its edges intersect with the edges but the original point that represents the square or the node in graphstream does not, I tried all the possible solutions with collinear points , slopes and everything but nothing worked for me, the question is, is there anyway in Grpahstream so that I can find out the coordinates of the edges or the corners of the square so that I can check with the line segment equation if they intersect ?
I mean something like that as shown in the picture
https://i.stack.imgur.com/PG4Dv.png
Best regards
the goal is to find all the rectangles you get when you come from all sides (north, west, east, south) in an orthogonal polygon. However, I can't get any further on concrete implementation.
So here is what I've done so far.
First: I have a list of coordinates (in a XML file), I want to read them into Java to determine the points and the edges of the polygon.
So now coming to my main problem. I want to find all rectangles that lie within this polygon,
[![the polygon]starting from all sides (north, east, south, west). I have a problem with this step. It occurred to me to use a SweepLine algorithm, but I am unsure how to implement it to get the desired result (overlapping rectangles coming from all sides). For that I have painted those pictures to clarify what I mean. If you come from the north edges of the polygon you would find the green rectangles. [![rectangles in the polygon coming from the north edges]
If you come from the west edges of the polygon you would find the red rectangles.
[rectangles in the polygon coming from the west edges]
and with that the overlapping rectangles..
[overlap of green and red rectangles]
However, I'm not sure how to do this the most easiest way. I researched a lot sweep line Algorithms, but I'm not sure how to implement it and whether this is an efficient way. My goal is to find those rectangles and save them in a proper way so that I can use them for further steps (e.g. finding positions in the polygon where many rectangles overlap)
Maybe someone could help me with that. Would appreciate this a lot!
If you already know all the edges and have determined whether they face North, South, East or West, determining the rectangles could be done like this:
Iterate through the edges.
Let's say we have a north-facing edge between (n.x1, n.y) and (n.x2, n.y). The corresponding rectangle must have its north-facing edge be the one we just looked at and its south-facing edge must, at least in part, consist of one or more south-facing edges.
We iterate through all south-facing edges and find the ones such that at least one point on the edge has an X coordinate within the range (n.x1, n.x2).
Additionally, they need to actually be south of the north-facing edge, so keep the ones where s.y > n.y.
Now, what we have left is a list of all south-facing edges that could possibly limit our rectangle's height. However, the rectangle is limited by whichever is the closest, so we simply pick the remaining south-facing edge, s, with the lowest y coordinate.
We now have a rectangle between (n.x1, n.y) and (n.x2, s.y).
Corresponding logic is implemented for each cardinal direction.
I have an array with the coordinates of the center of small circles which have the same radius. I know how to find when the mouse is over a circle, but my array is big and I want the fastest way to calculate this operation.
Is there a way of finding if the mouse is over a circle without looping all the array for each movement of the mouse?
Initially, set up some 'zones' for quicker reference:
Separate the whole surface into a small number of rectangles that don't intersect.
For each of these rectangles, list all circles that are at least partially contained in it. (A circle may end up listed in multiple rectangles, but that's okay.)
Every time you want to check whether the mouse is over a circle, you won't have to go through the whole array of circles. Instead:
Figure out which rectangle you're in.
Check only the circles that are listed under that rectangle.
This looks like a problem of optimizing the boundary check for a large number of items. The approach of going linearly does not scale well for thousands of circles.
This is a good topic to read on the net. But first, without going there, I'll try to explain (as an exercise) what I would explore. I would create a binary tree and partition the space, then instead of using an array I would put the circle points in such a tree. Looking the tree elements that are closer to the actual X,Y location becomes a matter of doing a binary search on the tree. The you have the closest point as a result of that search and can check for collision on it. There is still more to be done to the algorithm, and further optimizations are needed. For example, how to check for more points and not only the final one? Potentially I need a tree for the X coordinate, and another for the Y coordinate, etc... But I would explore these ideas. I will come back to this post and expand my reply with an actual example and a more concrete solution.
What if you check the coordinates that are r(radius) distance from the mouse? Then you could narrow your search down in the array if it is ordered.
I've recently been looking into LibGDX and seem to have hit a wall, seen in the picture, the blue dot represents the users finger, the map generation it self is where i seem to get stuck, does LibGDX provide a method of dynamically drawing curved objects? I could simply generate them myself as images but then the image is hugely stretched to the point of the gap for the finger can fit 3! But also would need to be 1000's of PX tall to accommodate the whole level design.
Is it such that i should be drawing hundreds of polygons close together to make a curved line?
On a side not i'll need a way of determining when the object has from bottom to top so i can generate another 'chunk' of map.
You don't need hundreds of polygons to make a curve like you drew. You could get away with 40 quads on the left, and 40 on the right, and it would look pretty smooth. Raise that to 100 on each side and it will look almost perfectly smooth, and no modern device is going to have any trouble running that at 60fps.
You could use the Mesh class to generate a procedural mesh for each side. You can make the mesh stay in one spot, locked to the camera, and modify it's vertices and UVs to make it look like you are panning down an infinitely long corridor. This will take a fair amount of math up front but should be smooth sailing once you have that down.
Basically, your level design could be based on some kind of equation that takes Y offset as an input. Or it could be a long array of offsets, and you could use a spline equation or linear equation to interpolate between them. The output would be the UV and X coordinates which can be used to update each of the vertices of your two meshes.
You can use the vertex shader to efficiently update the UV coordinates, using a constant offset uniform parameter that you update each frame. That way you don't have to move UV data to the GPU every frame.
For the vertex positions, use your Mesh's underlying float[] and call setVertices() each frame to update it. Info here.
Actually, it might look better if you leave the UV's and the X positions alone, and just scroll the Y positions up. Keep a couple quads of padding off top and bottom of screen, and just move the top quad to the bottom after it scrolls off screen.
How about creating a set of curved forms that can be put together variably. Like the gap in the middle will at the top and bottom of each image be in the middle (with the same curvature at end and beginning points)...
And inbetween the start and end points you can go crazy on the shape.
And finally, you can randomly put those images together and get an endless world.
If you don't want to stop in the middle each time, you could also have like three entry and exit points (left, middle, right)... and after an image that ends left, you of course need to add an image that starts left, but might end somewhere else...
I'm currently writing an application that actually acts as a "cut" tool for 3D meshes. Well, I had some problems with it now which I am clueless on how to solve, since it is my first application.
I have loaded a model from an object file onto the canvas, then on the same canvas, I use the mouse drag event to draw lines to define the cutting point.
Let us say I want to cut a ball into half and I draw the line in the middle. How do I detect the vertices of the ball under the line.
Secondly, if I rotate/translate the ball, would all the the vertices information change?
Think of what you'd do in the real world: You can't cut a ball with a line, you must use a knife (a line has no volume). To cut the ball, you must move the knife through the ball.
So what you're looking after is a plane, not a line. To get such a plane, you must use some 3D math. What you have is the canvas orientation and the "side view" of the plane (which looks like a line).
So the plane you're looking for is perpendicular to the canvas. A simple way to get such a plane is to take the canvas orientation and create a plane which has the same orientation and then rotate the plane around the line by 90°.
After that, you can visit all edges of your model and determine on which side of the plane they are. For this, determine on which side of the plane the end points of the edge are. Use the cross product. If they are on the same side (both results of the cross products will have the same sign), you can ignore the edge. Otherwise, you need to determine the intersection point of the edge and plane. Create new edges and connect them accordingly.
See this page for some background on the math. But you should find some helper methods for all this in your opengl library.
if I rotate / translate the ball, would all the the vertices information change
Of course.
It's not going to be that easy.
I assume the line you are drawing induces a plane which then cuts the sphere.
To do so, you have to calculate the intersecting area of the sphere and the plane.
This is not a trivial task and I suggest using an existing framework for this or if you really want to do this yourself, read about basic intersection problems to get a feeling for this kind of problem. This paper offers a good introduction to various intersection tests.
In general boundary represended volumes, as in your case, are difficult to handle when it comes to more advanced manipulations. Cutting a sphere in half is easy compared to burring a small hole into it. Sometimes it's better to use a volume representation, like tetrahedral meshes or CSG.
Regarding your second question, you shouldn't rotate or translate the sphere, rotate and translate the camera.