So I'm doing the project of an introduction to Java course and it seems that I chose something that goes way beyond what I'm able to do. :P
Any help would be greatly appreciated. This is what I'm having problems with:
You have a cursor that is controlled by a player (goes forward or
turns 90°) which leaves a colored line as it goes. If you manage to go
over your own line and close a polygon of any shape (only right angles
though), its surface changes color into the color of your line.
I can detect when this situation arises but I am kind of lost as how to actually fill the correct polygon just closed. I can't seem to imagine an algorithm that would cover any case possible.
I looked at the Scanline fill algorithm but I think it would start having problems by the time there are already some polygons already filled in the map.
The Floodfill algorithm would be perfect if I had a way of finding a point inside the polygon, but, as there are many different possibilities, I can't think of a general rule for this.
I'm using an array 2x2 of integers where each color is represented by a number.
Does anyone have an idea on how to approach this problem?
If you can detect the situation then this can be solved in very simple manner. The question is which point to choose as start point for floodfill. The simple answer is: try all of them. Of course it makes a sense to start only with points adjacent to the one where your cursor is located. In this case you will have at most 8 points to check. Even better - at least 2 of them are definitely painted already if current point forms a polygon.
So you have 8 points to check. Launch floodfill 8 times starting from each of those points.
Two things which you probably should keep in mind:
You should try filling the area in cloned version of your field in order to be able to get back if floodfill will not find a polygon.
Launching floodfill second time and later you should reuse this cloned version of your field to see whether it was filled there. This will allow you to check every point at most once and this will make your 8 floodfills almost as fast as 1 floodfill.
Check this question, using Graphics2 and Polygon to fill an arbitrary polygon: java swing : Polygon fill color problem
Finding out whether a point is inside or outside a polygon: http://en.wikipedia.org/wiki/Point_in_polygon
Make sure you use double buffering. If you set individual pixels and don't use double buffering the component may redraw after every pixel was set.
Related
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 have many problems unsolved, and i'm kind of new at LWJGL.
Here is a screen: http://image.noelshack.com/fichiers/2015/07/1423885261-sans-titre.png
(this is 20x20x20 simple cube)
But as you can see, my fps are not bigger than 40 and every face of the cube is showing. How can i fix the fps drop and hide the hidden block behind another one ?
I have glEnable(GL_DEPTH_TEST); and glEnable(GL_CULL_FACE); but it only work INSIDE the block :x ...
Sorry for my english too but i really need help :p
Culling
If culling only works if you are inside a block your vertex winding order is most likely mixed up. If so you might want to change it from the default GL_CCW to GL_CW or fix your vertex order to the default. Reference here
SpeedUp
For this your question has too few information. If you are not doing so already you might want to switch to using Vertex_Buffer_Object. Preferably using a single geometry that is only translated.
An additional approach would be to only render objects that are in line of sight of the camera. One method for this is a Binary Search Tree
I am trying to draw an interactive planar straight line graph (PSLG) on a JApplet. I am using mouse-clicks to determine the vertices of the PSLG.
Here is the algorithm which I am following for drawing edges of the PSLG
1. The point where user performs a mouse-click is added as a vertex of the PSLG.
2. If he clicks a second point,an edge is directly created among the point and the previously clicked-point
Here are certain flaws which I observed due to the use of this algorithm:
Inability to create disjoint-planar sets like say just a line segment
A closed polygon is only created if the user clicks at the exact location where the start point was [Essentially, if the user clicks very close to the start point, there is no way to tell that this point is actually the start point since it appears within a certain tolerance range from the point].
I've checked out some similar questions over here and people suggest to use the JFreeChart library. But as far as I get, the scenario in those questions was that the points of the PSLG were already known. I do not know whether JFreeChart can be used for creating interactive PSLG's
I thought about adding points and having a button which would say add edges among points,but if that's the case selecting the 2 points will still involve the proximity problem encountered in 2.
I was wondering if anybody could suggest me a better approach on how to handle this situation.
Thanks in advance
GraphPanel could be adapted to this task, although it might benefit from a more advanced edge model for faster searching. Also consider JGraph.
Yesterday I tried to solve a Problem I had the entire Day and it is still unsolved. I searched for every combinations of words I could imagine to find solutions on Google etc. But without success. :(
The Problem consists of following idea:
I started programming GLES20 (Not GLES10!) on Android. There are many other ways how to compute matrixes and objects. So there aren't any methods like "Pop" or "push" Matrix.
I want to rotate a globe/sphere only by touching and moving my fingers. Touching functions etc works fine but the rotation itself never does. Everytime I first rotate by x-axis and then rotating by y-axis the rotation is still computed by local space axis of the object and Not two global axis. This happens whatever I do... :/
There are some people searching the solution for the Same Problem, but mostly GLES10 or completly different programming languages, never GLES20 and Java.
I will also post some Code parts later, when I get access to a Computer.
perhaps someone already understands what my Problem is.
Thank you so much! :)
Chrise
In OpenGL ES 2.0 there aren't any of the matrix functions and you're supposed to take care of your own matrices. So, for pushing and popping matrices what you need to do is when you're drawing you copy your matrix to a temporary one, do whatever transformation on it and pass the temporary matrix to the vertex shader.
Yesterday I came across Craig Reynolds' Boids, and subsequently figured that I'd give implementing a simple 2D version in Java a go.
I've put together a fairly basic setup based closely on Conrad Parker's notes.
However, I'm getting some rather bizarre (in my opinion) behaviour. Currently, my boids move reasonably quickly into a rough grid or lattice, and proceed to twitch on the spot. By that I mean they move around a little and rotate very frequently.
Currently, I have implemented:
Alignment
Cohesion
Separation
Velocity limiting
Initially, my boids are randomly distributed across the screen area (slightly different to Parker's method), and their velocities are all directed towards the centre of the screen area (note that randomly initialised velocities give the same result). Changing the velocity limit value only changes how quickly the boids move into this pattern, not formation of the pattern.
As I see it, this could be:
A consequence of the parameters I'm using (right now my code is as described in Parker's pseudocode; I have not yet tried areas of influence defined by an angle and a radius as described by Reynolds.)
Something I need to implement but am not aware of.
Something I am doing wrong.
The expected behaviour would be something more along the lines of a two dimensional version of what happens in the applet on Reynolds' boids page, although right now I haven't implemented any way to keep the boids on screen.
Has anyone encountered this before? Any ideas about the cause and/or how to fix it? I can post a .gif of the behaviour in question if it helps.
Perhaps your weighting for the separation rule is too strong, causing all the boids to move as far away from all neighboring boids as they can. There are various constants in my pseudocode which act as weights: /100 in rule 1 and /8 in rule 3 (and an implicit *1 in rule 2); these can be tweaked, which is often useful for modelling different behaviors such as closely-swarming insects or gliding birds.
Also the arbitrary |distance| < 100 in the separation rule should be modified to match the units of your simulation; this rule should only apply to boids within close proximity, basically to avoid collisions.
Have fun!
If they see everyone, they will all try to move with average velocity. If they see only some there can be some separated groups.
And if they are randomly distributed, it will be close to zero.
If you limit them by rectangle and either repulse them from walls or teleport them to other side when they got close) and have too high separation, they will be pushed from walls (from walls itself or from other who just were teleported, who will then be pushed to other side (and push and be pushed again)).
So try tighter cohesion, limited sight, more space and distribute them clustered (pick random point and place multiple of them small random distance from there), not uniformly or normaly.
I encountered this problem as well. I solved it by making sure that the method for updating each boid's velocity added the new velocity onto the old, instead of resetting it. Essentially, what's happening is this: The boids are trying to move away from each other but can't accelerate (because their velocities are being reset instead of increasing, as they should), thus the "twitching". Your method for updating velocities should look like
def set_velocity(self, dxdy):
self.velocity = (self.velocity[0] + dxdy[0], self.velocity[1] + dxdy[1])
where velocity and dxdy are 2-tuples.
I wonder if you have a problem with collision rectangles. If you implemented something based on overlapping rectangles (like, say, this), you can end up with the behaviour you describe when two rectangles are close enough that any movement causes them to intersect. (Or even worse if one rectangle can end up totally inside another.)
One solution to this problem is to make sure each boid only looks in a forwards direction. Then you avoid the situation where A cannot move because B is too close in front, but B cannot move because A is too close behind.
A quick check is to actually paint all of your collision rectangles and colour any intersecting ones a different colour. It often gives a clue as to the cause of the stopping and twitching.