I'm trying to create a very specific geodesic tessellation, but I can't find anything online about it.
It is normal to subdivide the triangles of an icosahedron into triangle patches and project them onto the sphere. However, I noticed an animated GIF on the Wikipedia entry for Geodesic Domes that appears not to follow this scheme. Geodesic spheres generally comprise a mixture of mostly hexagonal triangle patches, with pentagonal patches forming at the vertices of the original icosahedron; in most cases, these pentagons are linked together; that is, following a straight edge from the center of one pentagon leads to the center of another pentagon. In the Wikipedia animation, however, the edge from the center of one pentagon doesn't appear to intersect the center of an adjacent pentagons; instead it intersects the side of the other pentagon.
Where can I go to learn about the math behind this particular geometry? Ideally, I'd like to know of an algorithm for generating such tessellations.
Marcelo,
The most-commonly employed geodesic tessellations are either Class-I or Class-II. The image you reference is of a Class-III tessellation, more-specifically, 4v{3,1}. The classes can be diagrammed, so:
Class-III tessellations are chiral, and can have left-handed or right-handed twist. Here's the mirror-image of the sample you referenced:
You can find some 3D models of Class-III spheres, at Google's 3D Warehouse:
http://sketchup.google.com/3dwarehouse/cldetails?mid=b926c2713e303860a99d92cd8fe533cd
Being properly identified should get you off to a good start.
Feel free to stop by the Geodesic Help Group; http://groups.google.com/group/GeodesicHelp?hl=en
TaffGoch
Here's an image from one of Joe Clinton's NASA publications:
I believe it is actually just a matter of resolution (i.e., number of sub-divisions). The tessellation you show does seem to emanate from an icosahedron scheme: cf p.7 here, mid-page example. Check out the rest of the document for some calculation details - also its cited references, and some further code samples here.
Marcelo,
If you want to devise algorithms to generate any class of geodesic spheres, you can do it here:
http://thomson.phy.syr.edu/thomsonapplet.htm
Start by using the "custom(m,n)" option, select your desired parameters, then hit the "pause" button. Switch to "lattice energy" and hit the "Auto" button.
If you're intimately familiar with java, you can save the "jar" file(s) for this app, and examine the contents, to back-engineer the algorithms.
BTW, this java app also has a "File" menu option, which can activate a new window, listing the "Point set" (vertex coordinates.) I copy & paste them into an Excel spreadsheet, from which I can generate a "csv" file that can be, subsequently, imported into 3D-graphic programs.
Taff
Related
The Wikipedia page for L-Systems describes many of them, including a couple rules that converge toward the Sierpinski triangle. That particular fractal also has a 3D version, which basically uses pyramids instead of triangles. Is there a way to reach this one with an L-system? That same wikipedia page mentions the existence of 3D L-systems, but doesn't explain how they work or give any example as to what their rules would look like.
So first, how do 3D L-systems differ from their 2D counterpart (if there are major differences), and second, can they be used to create this Sierpinski Pyramids?
I'm trying to create it in Processing, as I managed to draw the 2D version in this software using an L-system before. An example of making a 3D L-system work would be appreciated, but not necessary
A 2D L system in instructions for creating recursive 2D trees with branches that contain number of sub-branches, angle, and length. A 3D version expends the branches to have roll, pitch and yaw. Its easiest to create one with turtle graphics. (If you just use a orthographic projection, you can see the tree, which is of course flattened again to 2D, but looks more complex and less symmetrical than a 2D tree)
Otherwise the system is the same.
I don't know the instruction sequence specifically for creating a Seipinsky pyramid. Presumably you stat at the apex pointing down, then do a pitch of 45*,
and four Rolls with 4 As between them.
I have a problem that reminds me of Voronoi, but I'm hoping that my variation will allow me to avoid using the Voronoi algorithm, and write something quicker.
Here's a horrible image I made in Paint to illustrate my problem:
Say I have an area of a map. Each dot represents a shop. Each square represents a neighbourhood. The voronoi diagram shows the areas closest to each shop.
If one of those areas dominates a square, then that whole square belongs to that shop.
Is it possible to determine which squares belong to which shop, without having to calculate an intermediate voronoi diagram? It seems as though, since this is like a very rough approximation of a voronoi diagram, there should be a super fast shortcut to generating it.
Perhaps I'm misunderstanding, but can't you just find the vertex which is closest to the centroid of each square?
#user2615897 points out that this isn't generally correct (see comment). None-the-less, I think it would be a good approximation for a grid which looks like your example (specifically: roughly equal-area cells, with spacings comparable to the square-sizes).
My intuition is that without explicitly constructing the diagram, any approach will only be an approximation... but I'm not sure.
This (segment) of a configuration illustrates the point:
The red vertex is nearest the center of the central square, while the green-vertex owns the most area.
I have a 2d world made of tiles. Tiles are either passable, non-passable or have some sort of movement penalty.
All entities and tiles have their own hitboxes and sizes for collision detection.
Each tile tile has dimensions of 16x16px.
Most examples I've read seem to suggest that we're moving from center of one tile to the center of another tile. And as we see from the picture below, that red part looks hardly optimal nor it doesn't take entity size into account. Also pathding nodes are also placed into 2d array, with only 8 possible directions from each node.
But wouldn't actually shortest path be something like this?
How should I implement pathfinding?
Should tiles be splitted into smaller nodes for pathfinding or is there some other way to get more accurate routes? Even if I splitted each tile to have 10x10 pathfinding nodes, It still wouldn't find shortest line between 2 points.
Should there be more than 8 directions and if so, how should that be implemented?
For example if my world was 50x50 tiles big, how should the pathfinding map look like and how it should be generated?
It depends on your definition of "shortest path" and what you plan to do with it.
In your example, it appears that you consider a valid move to be from the center of one tile to the center of any other tile in unobstructed view. How you'd validate moves to partially obstructed tiles is not clear. This differs from the geometrically shortest path, which would obviously hug the wall, and the realistic shortest path, would would use a unit width and turn radius to avoid walls and sudden changes in direction.
A common approach is to use A* as usual, and then post-process the path in a number of ways to optimize and smooth it. This works both for grid based worlds like yours, and for more general navmeshes.
Gamasutra had a nice overview of this called Toward More Realistic Pathfinding, with a variety of ideas and techniques from smoothing zigzags and adding curves, to optimizing paths for units with acceleration and direction.
I had almost same problem and I have coded a pre-computation software for all tiles to all tiles with some optimization
You can find source code here : https://github.com/FurkanGozukara/pathfinding-2d-tile-map
The development video is here : https://www.youtube.com/watch?v=jRTA0iLjv6M
I did come up with my own algorithm and implementation. Therefore it is probably not the best nor the most optimized one. Although it is already implemented into my free browser based game MonsterMMORPG and it works great : https://www.monstermmorpg.com/
Ok, here is the thing. Recently i decided i wanted to understand how Random map generation works. I found some papers and some arguments. The most interesting one was "Diamond Square algorithm" and "Midpoint Displacement". I still have to try to apply those to a software, but other than that, i ran into this site: http://www-cs-students.stanford.edu/~amitp/game-programming/polygon-map-generation/
As you can see, the idea is to use polygons. But i have no idea how to apply that a Tile-Based map, not even how to create those polygons using the tools i have (c++ and sdl). I am assuming there is no way to do it ( please correct me if i am wrong.) But if i am not, how does a non-tile map works, and how are these polygons generated?
This answer will not give you directly the answers you're looking for, but hopefully will get you close enough!
The Problem
I think what blocks you is how to represent the data. You're probably used to a 2D grid that simply represent the type of each tile. As you know, this is fine to handle a tile-based map, but doesn't properly allow you to model worlds where tiles are of a different shape.
Graphs
What I suggest to you, is to see the problem a bit differently. A grid is nothing more than a graph (more info) with nodes that have 4 (or 8 if you allow diagonals) implicit neighbor nodes. So first, what I would do if I was you, would be to move from your strict standard 2D grid to a more "loose" graph, where each node has a position, a position, a list of neighbors (in most cases you'll have corners with 2 neighbors, borders with 3 and "middle" tiles with 4) and finally a rendering component which simply draws your tile on screen at the given position. Once this is done, you should be able to have the exact same results on screen that you currently have with your "2D Tile-Based" engine by simply calling the rendering component with each node who's bounding box (didn't touch it in what you should add to your node, but I'll get back to this later) intersects with the camera's frustum (in a 2D world, it would most likely if the position +/- the size intersects the RECT currently being drawn).
Search
The more generic approach will also help you doing stuff like pathfinding with generic algorithms that explore nodes until they find a valid path (see A* or Dijkstra). Even if you decided to stick to a good old 2D Tile Map game, these techniques would still be useful!
Yeah but I want Polygons
I hear you! So, if you want polygons, basically all you need to do, is add to your nodes a list of vertices and the appropriate data that you might need to render your polygons (either vertex color, textures and U/V maps, etc...) and update your rendering component to do the appropriate OpenGL (this for example should help) calls to draw your nodes. Once again, the first step to iteratively upgrade your 2D Tile Engine to a polygon map engine would be to, for each tile in your map, give each of your nodes two triangles, a texture resource (the tile), and U/V mappings (0,0 - 0,1 - 1,0 and 1,1). Once again, when this step is done, you should have a "generic" polygon based tile map engine. The creation of most of this data can be created procedurally by calculating coordinates based on tile position, tile size, etc...
Convex Polygons
If you decide that you ever might need NPCs to navigate on your map or want to allow your player to navigate by clicking the map, I would suggest that you always use convex polygons (the triangle being the simplest for of a convex polygon). This allows your code that assume that two different positions on the same polygon can be navigated to in straight line.
Complex Maps
Based on the link you provided, you want to have rather complex maps. In this case, the author used Voronoi Diagrams to generate the polygons of the map. There are already solutions to do triangulation like that, but you might also want to use other techniques that are easier to work with if you're just switching to 3D like this one for example. Once you have interesting results, you should consider implementing serialization to save/open your map data from the game. If you want to create an editor, be aware that it might be a lot of work but can be worth it if you want people to help you creating maps or to add elements to the maps (like geometry that's not part of the terrain).
I went all over the place with this answer, but hopefully it helps!
Just iterate over all the tiles, and do a hit-test from the centre of the tile to the polys. Turn the type of the tile into the type of the polygon. Did you need more than that?
EDIT: Sorry, I realize that probably isn't helpful. Playing with procedural algorithms can be fun and profitable. Start with a loop that iterates over all tiles and chooses randomly whether or not the tile is occupied. Then, iterate over them again and choose whether it is occupied or its neighbour is.
Also, check out the source code for this: http://dustinfreeman.org/toys/wall7-dustin.html
I have some points on the edge(left image), and I want to construct a mesh(right), Is there any good algorithm to achieve it? many thanks!
image can see here http://ww3.sinaimg.cn/large/6a2c8e2bjw1dk8jr3t7eaj.jpg
To begin with, see Delauney triangulation. Look at this project: http://people.sc.fsu.edu/~jburkardt/c_src/triangulate/triangulate.html.
Edited because my original had too few details on edge-flipping, and when I tried to provided those details I found the TRIANGULATE project.
If the region is flat or quasi-flat look for Ear Clipping approach (http://www.geometrictools.com/Documentation/TriangulationByEarClipping.pdf). In the case of curved surface you need point inside the region and therefore you may need Constrained Delaunay Triangulation (otherwise some edges may not be included in the triangulation).
There is delaunayn function in geometry package for R language (see doc)
It takes an array of boundary points (as in your case) to create a Delaunay mesh on it.
You could also save your geometry into some well-known format, and use one of mesh generators.