Situation:
I have potentially tens of thousands of moving (2D) points. They affect each other only to a certain radius. They can move from place to place (not teleporting, just flying around the screen, essentially).
Since I have to check for updates every tick, it is rather important to do this efficiently.
My naive solution is to simply create a grid type structure with grid spacing somewhere around the radius of effect and as points move from cell to cell, update which cell they are in. So when I need to do effects checking, I only have to check a point's cell and a few neighboring cells.
I am familiar with quadtree, but I worry that it is a bit more expensive than what I need to do, but I am open to suggestions if this is indeed the correct route.
Also, for added information, this is in Java.
Thanks
i was and for my next project will be in a similar situation.
I choosed the simple grid variant, because its simpler and faster to implement.
tens of thousands is at the border where an quad tree or k-d tree could make sense. (especially when many cells would be empty)
You should try to test if an grid approach is sufficient. probably it is.
Related
For my work I had to get into OpenGL 3d rendering recently, and I admit I'm quite new to this topic.
Without getting into too much detail, I have to deal with a HUGE array of data (vertices) from which I need to draw a shape. Basically, think of a plane of a very odd shape in 3d space. This shape is being added to on the fly. Think of a car moving on a plane and painting it's trail behind it - but not just a simple trail, but with holes, discarded sections, etc. And it generates a new section several times per second for hours.
So, obviously, what you end up with is A LOT of vertices, that do get optimized somewhat, but not enough. Millions of them.
And obviously I can't just feed it to a GPU of embedded system as a vertex VBO.
So I've been reading about culling and clipping, and as far as I understand I only need to display the visible triangles of this array, and not render everything else.
Now, how do I do that properly?
The simplest brute-force solution would be to go through all triangles, and if they lie outside of frustum - just not draw them. Generate a buffer of what I DO draw and pass it to GPU
One idea I had is to divide world space into squares, a kind of chunks, and basically split the "trail" mesh between them. So each square will hold data for it's part of the trail, and then I could use frustum culling, maybe, to decide which squares to render and which to skip.
But I'm not convinced it's a great solution. I also read that you should reduce the number of GL function calls as much as possible, and calling it for hundreds of squares doesn't seem great.
So I decided to ask for advice among people who would understand the subject better then me. Sadly, I don't get much learning time - I need to dive right into it.
If anyone could give me some directed tips it'd be appreciated.
You'd be better off using some form of spatial partitioning tree (e.g. OctTree, QuadTree, etc). That's a similar approach to your second suggestion, however because it's hierarchical, searching the tree is O(logN) vs O(n).
Similar to the game Factorio im trying to create "3D" terrain but of course in 2D Factorio seems to do this very well, creating terrain that looks like this
Where you can see edges of terrain and its very clearly curved. In my own 2D game Ive been trying to think of how to do the same thing, but all the ways I can think of seem to be slow or CPU intensive. Currently my terrain looks like this:
Simply 2D quads textured and drawn on screen, each quad is 16x16 (except the water thats technically a background but its not important now), How could I even begin to change my terrain to look more like a Factorio or other "2.5D" games, do they simply use different textures and check where the tile would be relative to other tiles? Or do they take a different approach?
Thanks in advance for your help!
I am a Factorio dev but I have not done this, so I can only tell you what I know generally.
There is a basic way to do it and then there are optional improvements.
Either way you will need two things
Set of textures for every situation you want to handle
Set of rules "local topology -> texture"
So you have your 2d tile map, and you move a window across it and whenever it matches a pattern, you apply an appropriate texture.
You probably wouldn't want to do that on the run in every tick, but rather calculate it all when you generate the map (or map segment - Factorio generates new areas when needed).
I will be using your picture and my imba ms paint skills to demonstrate.
This is an example of such rule. Green is land, blue is water, grey is "I don't care".
In reality you will need a lot of such rules to cover all cases (100+ I believe).
In your case, this rule would apply at the two highlighted spots.
This is all you need to have a working generator.
There is one decision that you need to make here. As you can see, the shoreline runs inside the tile, not between tiles. So you need to chose whether it will run through the last land tile, or the last water tile. The picture can therefore be a result of these two maps (my template example would be from the left one):
Both choices are ok. In fact, Factorio switched from the "shoreline on land" on the left to the "shoreline on water" on the right quite recently. Just keep in mind that you will need to adjust the walking/pathfinding to account for this.
Now note that the two areas matched by the one pattern in the example look different. This can be a result of two possible improvements that make the result nicer.
First is that for one case you can have more different textures and pick a random one. You will need to keep that choice in the game save so that it looks the same after load.
Another one is more advanced. While the basic algorithm can already give you pretty good results, there are things it can't do.
You can use larger templates and larger textures that span over several tiles. That way you can draw larger compact pieces of the terrain without being limited by the fact that all the tiles need to be connectable to all (valid) others.
The example you provided are still 2D textures (technically). But since the textures themselves are 'fancy 3D', they appear to be 3D/2D angled.
So your best bet would be to upgrade your textures. (and add shadow to entities for extra depth).
Edit:
The edges you asked about are probably layed-out by checking if a 'tile' is an edge, and if so it adds an edge-texture on top the background. While the actual tile itself is also a flat image (just like the water). Add some shadow afterwards and the 3D illusion is complete.
I hope this answers your question, otherwise feel free to ask clarification.
Pardon the wall of text. I'll add images later. I need to generate a somewhat realistic map of cubic meter voxels, with water, sand, grasses, trees, minerals, deserts, beaches, islands, etc, without any sort of voronoi cop-out(i.e. be smart about relating these factors to each other). Yes, this is a game.
I figured I'd generate critical points randomly and interpolate them for elevation and humidity readings, but I'm at a loss with random generation. Basically I need a somewhat even distribution of points without having to make the full list at once. I need to generate roughly 20x20x20 at a time, and probably work with approximately 1000x1000x1000 cells of critical points, but I'd expect strange things to happen at the edges of the large cells. Does anyone know of any way to select points in this way? The real trouble is that points should prefer to be in proximity to others in "mountain-range" style chains.
The problem here is that this is happening across these 1-km cells.
I can simply pick points this way within a cell, but since a cell and its neighbor need to be dependent on each other, my trivial algorithm would have encountered the need to head to infinity for one of these cells, or see a grid-like pattern of broken chains. The chains should not break more frequently on cell boundaries. If they do a somewhat problematic wafer-like pattern shows in generation and makes for a poor generation that is unusable for design/gameplay reasons.
n.b. For the purposes of these, the system-level random generator can be seeded and is practically uniform. As far as within a cell, I can select chains just fine.
I also considered having a cell spill over into any ungenerated cells so its chains start connected to existing ones, but that would break the determinism of generation simply based on location and seed, adding order of generation as a factor.
Again, for the purposes of realism and design I'm trying to stay away from using Perlin. Or should I post on gamedev.SE?
The key concept is to create the interfaces between a cell and all six of its neighbors before filling in the cell. Picture creating your entire world as a grid of hollow boxes, but before you do that, create it as a wire-frame outline, but before you do that, create the grid of wire-frame intersections.
Here's a simplistic approach -- you'll have to improve this. First, consider this method of generating the entire world at once:
(1) select all the vertex voxels -- perhaps the upper north west voxel in each cell -- and set its world attributes to reasonable values based entirely on location and seed.
(2) select the lines of voxels connecting the vertices, and fill in all their world attributes, based on location and seed, but constrained to match up with the existing vertex voxel values at each end.
(3) select the planes of voxels describing the faces bounded by the existing lines, and fill in in all their world attributes, based on location and seed, but constrained to match up with the existing line voxel values along the edges.
(4) fill in the cell, based on location and seed, but constrained to match up with the existing bounding six faces.
Now, consider that this method doesn't need to be done all at once. All that is necessary is that you create all six faces of a cell before filling it in, and that you create all four bounding lines of a face before you fill that in, and that you create the two end points of a line before filling that in. After the first cell, some of these will already exist.
The reason I said that you'll have to improve this idea is that it produces noticeable gradient boundaries at the cell boundaries. I'm afraid that each interface voxel will not only need to contain world attributes, but the rate of change of each attribute across the interface at that point. This implies that each line voxel will have to contain two rates of change for each attribute, and each vertex, three.
I'm not going to describe how you would constrain the gradient of a world attribute as it approaches a voxel with a predefined gradient because I'm sure you can handle it, my answer is already too long, and I don't know how.
I tried to find out thousands of point in million polygon via web services .At first i implemented the algorithm(Point in polygon) in java ,but it take a long time .And then i split the table in mysql and tried to using the multiple thread to solve it ,but still inefficiently. Is there any faster algorithm or implementation for solve this?
Plus description about the polygon. 2D ,static,complex polygon(also with hole).
Any Suggestion will be appreciate.
Testing a point against a million polygons is going to take a lot of time, no matter how efficient your point in polygon function is.
You need to narrow down the search list. Start by making a bounding box for each polygon and only selecting the polygons when the point is within the bounding box.
If the polygons are unchanging you could convert each polygon to a set of triangles. Testing to see if a point is in a triangle should be much faster than testing to see if it's in an arbitrary polygon. Even though the number of triangles will be much larger than the number of polygons, it might be faster overall.
If the collection of polygons is static it may be helpful to first register them onto a spatial data structure - an R-tree might be a good choice, assuming that the polygons do not overlap each other too much.
To test a point against the polygon collection the enclosing leaf in the tree would first be found (an O(log(n)) style operation) and then it would only be necessary to perform the full point-in-polygon test for the polygons that are associated with the enclosing leaf.
This approach should greatly speed up each point test, but requires an additional setup phase to build the R-tree.
Hope this helps.
If you deal with millions of polygons, you need some kind of space partitioning, or it's gonna be slow, no matter how optimized your hit-test function is or how many threads work on solving your query.
What kind of space partitioning ? it depends:
2D? 3D?
Is your polygon set static? If not, do it changes frequently?
What kind of request are you doing on this set?
What kind of polygon is it? Triangle? Convex? Concave? Complex? With holes?
We need more information to help you.
EDIT
Here is a simple space partitioning scheme.
Suppose there is a Cartesian grid over your 2D space with a given step.
When you add a polygon:
Compute its bounding box
Find all the grid cells that intersect with the bounding box
For each cell, add a line in a special table.
The table looks like this: cell_x, cell_y, polygon_id. Add the proper indexes (at least cell_x and cell_y)
Of course, you want to choose your grid step so most of the polygons lay in less than 10 cells, or else your cell table will quickly becomes huge.
It's now easy to find the polygons at a given point:
Compute in which cell your point belongs
Get all polygons associated to this cell
For each polygon, use your hit-test function
This solution is far from optimal, but easy to implements.
I thik here is the case where divide and conquer would do, you could try making subpolyons or simplifying some of the poonts, maybe try an heuristic approach, there are my 5 cents.
I've built a 2D grid in java where each cell can have a certain attribute, say color. At each iteration of the main loop, that color can possibly change.
What I want to be able to do:
- when zoomed in, it will show a small subset of the grids and the actual color of each grid.
- as you zoom out and see more cells at once, the cells will start to get too small to be seen individually, so I want to be able to just represent that area(a collection of cells) as a single color (say the most often occurring one in that collection)
One thing I thought of for doing this would be to use a hierarchical tree/pyramid structure, where at the leaves you have each cell. Each parent node contains summary information of each of its children. So to draw the map at a high zoom level, I'd only need to go down a few levels in the tree instead of looking at each cell individually. However, propagation of changes from leaves to parents and subsequently to each higher level seems like it'd take quite awhile in a large grid for every loop iteration.
Is there a better way to do this? This problem seems like it should have been handled before by people in the graphics/gaming world but I'm having trouble even finding the right keywords to Google, so any help or direction is appreciated. Thanks.
Perhaps quadtree would be a helpful search term.
http://www.google.com/m/url?client=safari&ei=idePTdD_LuWJiAKbgM3pAQ&hl=en&oe=UTF-8&q=http://en.wikipedia.org/wiki/Quadtree&ved=0CBMQFjAA&usg=AFQjCNEjIDTtDl-nIhlMVz6WemoQ_w8jYg
I think you're on the right track. What you propose is a typical implementation of a 2D scene graph and determining bounds of parent nodes.
Keep in mind that even though leaf nodes might change colors, the change may not be propogated all the way up due to previous state. What you need to be sure to do is track dirty leaves so you don't do the update for everything when its not necessary.
I think you should implement what you propose and then see if performance is really an issue. How many cells are in your grid?