I try to implement procedural 3d trees in OpenGL using Lsystem.
Up to now I can get these kind of results:
It looks like a tree, but I would like to improve the result, and get more realistic tree.
Somebody have any ideas to simply add thickness feature to the tree, because for now it's only some "sticks", or structure like leaves ...
I would like to use it in procedural terrain rendring.
Thank you in advance.
Related
I have been trying to find a algorithm to strongly solve the game Teeko. The game is played on a 5x5 board were each player has 4 pieces and attempts align them in any direction or create a square out of them. (assume there is no drop phase)
I have tried solving the game by using a negamax with alpha beta pruning and other optimizations like a transposition table but that has not seemed to have worked because the solver would usually get stuck in loops were neither player wants to deviate from there strategy as it would result in them loosing. From my research I have found stuff like Nash Equilibrium as a potential solution but I cant figure out how to implement it. Furthermore, I have found that the game has been solved and found that the with prefect play it result in a draw previously: https://pcarrier.com/teeko/text/teeko.results.txt
Are there any algorithms that might be able to give the same result as minimax and hanlde repeating positions and how could I implement it and are there any other algorithms that give the same result as minimax?
Minimax (or Negamax) is well capable of handling repeating positions using transposition tables, as you mention in your question. Transposition tables are complicated to implement though so maybe you have a bug?
The problem with minimax is that you either:
NEed to solve it until the game is completed to get a score. This is possible for simple games like tic-tac-toe, but not for more complicated games like chess.
Score each node using some heuristic function, which is the case for e.g. chess.
I am not sure about Teeko, is it possible to get to all leaf nodes with minimax and alpha beta pruning? Could you do other things to reduce the search tree, like transpotision tables or other cut offs? If so then minimax is a great option.
Is it possible to create some kind of evaluation function for this game? It seems hard to me, but maybe that is because I know too little about the game. Is it better to have central squares? Better to get 2 in a row than to spread out pieces? Evaluation function is something you could have a look at if you are a good player of the game, or find good sources online.
I've developed a little program that let me load an image then make some angle measurements onto it. Here is a screenshot (there is no image loaded in this screenshot).
When all the measurements are done I have a list of x, y and angle values. What I'd like to do is interpolate them to generate some kind of graph.
I would prefer to directly implement this functionality and not rely on any other library (as long as it's possible and not to complicated).
So basically I see two steps, first interpolating the data, second, generating a graph from it.
At first I was going to implement some bicubic interpolation but this kind of interpolation needs a regular grid, which I can't ensure.
For the moment I think I have to main options:
Convert my data to a regular grid and then do a bicubic interpolation.
Find an other kind of interpolation that doesn't require a regular grid.
What way do you think I should go and do you have any idea of which grid-redefining/interpolation I should use? I don't have any opinion on both methods but I think this is going to take me a lot of time and I wouldn't like to realize in the end that I am in a dead-end.
If this is of any relevance I'm working with Qt and on windows.
Edit: Basically I want something like that in the end:
What you are looking for is a 2D Least squares fitting function, and generating a heat map or a 3D surface.
QWT is nice library that can help with graphing it, but it is doable without it.
Google Least Squares 2D Calculation
I'm working on a relatively small 2D (top-view) game demo, using OpenGL for my graphics. It's going for a basic stealth-based angle, and as such with all my enemies I'm drawing a sight arc so the player knows where they are looking.
One of my problems so far is that when I draw this sight arc (as a filled polygon) it naturally shows through any walls on the screen since there's nothing stopping it:
http://tinyurl.com/43y4o5z
I'm curious how I might best be able to prevent something like this. I do already have code in place that will let me detect line-intersections with walls and so on (for the enemy sight detection), and I could theoretically use this to detect such a case and draw the polygon accordingly, but this would likely be quite fiddly and/or inefficient, so I figure if there's any built-in OpenGL systems that can do this for me it would probably do it much better.
I've tried looking for questions on topics like clipping/occlusion but I'm not even sure if these are exactly what I should be looking for; my OpenGL skills are limited. It seems that anything using, say, glClipPlanes or glScissor wouldn't be suited to this due to the large amount of individual walls and so on.
Lastly, this is just a demo I'm making in my spare time, so graphics aren't exactly my main worry. If there's a (reasonably) painless way to do this then I'd hope someone can point me in the right direction; if there's no simple way then I can just leave the problem for now or find other workarounds.
This is essentially a shadowing problem. Here's how I'd go about it:
For each point around the edge of your arc, trace a (2D) ray from the enemy towards the point, looking for intersections with the green boxes. If the green boxes are always going to be axis-aligned, the math will be a lot easier (look for Ray-AABB intersection). Rendering the intersection points as a triangle fan will give you your arc.
As you mention that you already have the line-wall intersection code going, then as long as that will tell you the distance from the enemy to the wall, then you'll be able to use it for the sight arc. Don't automatically assume it'll be too slow - we're not running on 486s any more. You can always reduce the number of points around the edge of your arc to speed things up.
OpenGL's built-in occlusion handling is designed for 3D tasks and I can't think of a simple way to rig it to achieve the effect you are after. If it were me, the way I would solve this is to use a fragment shader program, but be forewarned that this definitely does not fall under "a (reasonably) painless way to do this". Briefly, you first render a binary "occlusion map" which is black where there are walls and white otherwise. Then you render the "viewing arc" like you are currently doing with a fragment program that is designed to search from the viewer towards the target location, searching for an occluder (black pixel). If it finds an occluder, then it renders that pixel of the "viewing arc" as 100% transparent. Overall though, while this is a "correct" solution I would definitely say that this is a complex feature and you seem okay without implementing it.
I figure if there's any built-in OpenGL systems that can do this for me it would probably do it much better.
OpenGL is a drawing API, not a geometry processing library.
Actually your intersection test method is the right way to do it. However to speed it up you should use a spatial subdivision structure. In your case you have something that's cries for a Binary Space Partitioning tree. BSP trees have the nice property, that the complexity for finding intersections of a line with walls is in average about O(log n) and worst case is O(n log n), or in other words, BSP tress are very efficient. See the BSP FAQ for details http://www.opengl.org//resources/code/samples/bspfaq/index.html
I'm trying to draw a 2D silhouette of an island/land of sort in C++ with OpenGL. It is just a simple island that looks something like the one here
I tried ways like drawing polygons, fill the colour black and then hard-code tons of vertex points to get the shape of the island and also to keep the edges look rough like the one in the example. But I feel that this really isn't the best way to do this because the number of vertices is just too many. It is also very difficult to tweak because it's not like I'm in Photoshop where I could just pull/add/change the points visually.
Are there any better and more clever way to draw a 2D island silhouette to get the mountain-like edges? As for the overall shape of the island, is my naive way to plant tons of points to form the polygon shape the only way?
I have just started on OpenGL and will be grateful for any suggestions. Thanks!
There are many ways to go about this here are two simple ones;
Easy way: As said in the comments, create the island in an image editor (with alpha) and draw as a quad/tris with blending enabled.
Harder way: Import a vector graphic (vector meaning points making a shape) and draw as polygons. This could get complicated for a newbie if using an existing format. Also, not as efficient as method 1, but can have a much nicer visual effect especially if you plan on zooming/scaling.
In the end it is entirely up to you how you want to implement it, but the first method is straight-forward and easy, I recommend that for a newbie (be sure to come back to it later and try method 2 though ;) ).
I've got some convex polygons stored as an STL vector of points (more or less). I want to tessellate them really quickly, preferably into fairly evenly sized pieces, and with no "slivers".
I'm going to use it to explode some objects into little pieces. Does anyone know of a nice library to tessellate polygons (partition them into a mesh of smaller convex polygons or triangles)?
I've looked at a few I've found online already, but I can't even get them to compile. These academic type don't give much regard for ease of use.
CGAL has packages to solve this problem. The best would be probably to use the 2D Polygon Partitioning package. For example you could generate y-monotone partition of a polygon (works for non-convex polygons, as well) and you would get something like this:
The runnning time is O(n log n).
In terms of ease of use this is a small example code generating a random polygon and partitioning it (based on this manual example):
typedef CGAL::Exact_predicates_inexact_constructions_kernel K;
typedef CGAL::Partition_traits_2<K> Traits;
typedef Traits::Point_2 Point_2;
typedef Traits::Polygon_2 Polygon_2;
typedef std::list<Polygon_2> Polygon_list;
typedef CGAL::Creator_uniform_2<int, Point_2> Creator;
typedef CGAL::Random_points_in_square_2<Point_2, Creator> Point_generator;
int main( )
{
Polygon_2 polygon;
Polygon_list partition_polys;
CGAL::random_polygon_2(50, std::back_inserter(polygon),
Point_generator(100));
CGAL::y_monotone_partition_2(polygon.vertices_begin(),
polygon.vertices_end(),
std::back_inserter(partition_polys));
// at this point partition_polys contains the partition of the input polygons
return 0;
}
To install cgal, if you are on windows you can use the installer to get the precompiled library, and there are installations guides for every platform on this page. It might not be the simplest to install but you get the most used and robust computational geometry library there is out there, and the cgal mailing list is very helpful to answer questions...
poly2tri looks like a really nice lightweight C++ library for 2D Delaunay triangulation.
As balint.miklos mentioned in a comment above, the Shewchuk's triangle package is quite good. I have used it myself many times; it integrates nicely into projects and there is the triangle++ C++ interface. If you want to avoid slivers, then allow triangle to add (interior) Steiner points, so that you generate a quality mesh (usually a constrained conforming delaunay triangulation).
If you don't want to build the whole of GCAL into your app - this is probably simpler to implement.
http://www.flipcode.com/archives/Efficient_Polygon_Triangulation.shtml
I've just begun looking into this same problem and I'm considering voronoi tessellation. The original polygon will get a scattering of semi random points that will be the centers of the voronoi cells, the more evenly distributed they are the more regularly sized the cells will be, but they shouldn't be in a perfect grid otherwise the interior polygons will all look the same. So the first thing is to be able to generate those cell center points- generating them over the bounding box of the source polygon and a interior/exterior test shouldn't be too hard.
The voronoi edges are the dotted lines in this picture, and are sort of the complement of the delaunay triangulation. All the sharp triangle points become blunted:
Boost has some voronoi functionality:
http://www.boost.org/doc/libs/1_55_0/libs/polygon/doc/voronoi_basic_tutorial.htm
The next step is creating the voronoi polygons. Voro++ http://math.lbl.gov/voro++/ is 3D oriented but it is suggested elsewhere that approximately 2d structure will work, but be much slower than software oriented towards 2D voronoi. The other package that looks to be a lot better than a random academic homepage orphan project is https://github.com/aewallin/openvoronoi.
It looks like OpenCV used to support do something along these lines, but it has been deprecated (but the c-api still works?). cv::distTransform is still maintained but operates on pixels and generates pixel output, not vertices and edge polygon data structures, but may be sufficient for my needs if not yours.
I'll update this once I've learned more.
A bit more detail on your desired input and output might be helpful.
For example, if you're just trying to get the polygons into triangles, a triangle fan would probably work. If you're trying to cut a polygon into little pieces, you could implement some kind of marching squares.
Okay, I made a bad assumption - I assumed that marching squares would be more similar to marching cubes. Turns out it's quite different, and not what I meant at all.. :|
In any case, to directly answer your question, I don't know of any simple library that does what you're looking for. I agree about the usability of CGAL.
The algorithm I was thinking of was basically splitting polygons with lines, where the lines are a grid, so you mostly get quads. If you had a polygon-line intersection, the implementation would be simple. Another way to pose this problem is treating the 2d polygon like a function, and overlaying a grid of points. Then you just do something similar to marching cubes.. if all 4 points are in the polygon, make a quad, if 3 are in make a triangle, 2 are in make a rectangle, etc. Probably overkill. If you wanted slightly irregular-looking polygons you could randomize the locations of the grid points.
On the other hand, you could do a catmull-clark style subdivision, but omit the smoothing. The algorithm is basically you add a point at the centroid and at the midpoint of each edge. Then for each corner of the original polygon you make a new smaller polygon that connects the edge midpoint previous to the corner, the corner, the next edge midpoint, and the centroid. This tiles the space, and will have angles similar to your input polygon.
So, lots of options, and I like brainstorming solutions, but I still have no idea what you're planning on using this for. Is this to create destructible meshes? Are you doing some kind of mesh processing that requires smaller elements? Trying to avoid Gouraud shading artifacts? Is this something that runs as a pre-process or realtime? How important is exactness? More information would result in better suggestions.
If you have convex polygons, and you're not too hung up on quality, then this is really simple - just do ear clipping. Don't worry, it's not O(n^2) for convex polygons. If you do this naively (i.e., you clip the ears as you find them), then you'll get a triangle fan, which is a bit of a drag if you're trying to avoid slivers. Two trivial heuristics that can improve the triangulation are to
Sort the ears, or if that's too slow
Choose an ear at random.
If you want a more robust triangulator based on ear clipping, check out FIST.