I need to draw a polygon with thick lines. Now I have two possibilities:
Draw them with the library SPriG, which provides line thickness.
Split up the polygon in all it lines and draw them as polygons with a modified thickness (like explained in this tutorial (1 tutorial on the page).) with the SDL_gfx library.
I'm not sure about the performance of SPriG. SDL_gfx will be the fastest I guess.
Did you ever tried this, or simply "do you know the quality of SPrig"?
Thanks
It looks like SPriG just draws a circle at each pixel along a line to give it thickness. For wide lines you're looking at quite a bit of overdraw.
I'd do it a bit differently. It may or may not be faster depending on how triangle rasterization compares to per-pixel circle overdraw.
Don't use one of them. Just make use use of OpenGL and call: glLineWidth(3.6f);
Related
I am trying to understand the whole 2D accelerated rendering process using SDL 2.0.
So my question is which would be the most efficient way to draw circles in the screen and why?
Some ways would be:
First to create a software surface and then draw the necessary pixels on that surface then create a texture out of that surface and lastly copy that texture to the rendering target.
Also another implementation would be to draw a circle using multiple times SDL_RenderDrawLine.And I think this is the way it is being implemented in SDL 2.0 gfx
Or there is a more efficient way to do all of this?
Take this question more generally in means of if I would wanted to draw other shapes manually, which probably, couldn't be rendered easily with the 2D rendering API that SDL provides(using draw line or rectangle).
With the example of circles this is a fairly complicated question, it is more based on the visual quality you wish to achieve which will drive performance. Drawing lots of short lines will vary vastly based on how close to a circle you wish to get, if you are happy to use say, 60 lines, which will work on small shapes nearly seamlessly but if scaled up will begin to appear not to be a circle, the performance will likely be better (depending on the user's hardware). Note also SDL_RenderDrawLines will be much much faster for many lines as it avoids lots of context switches for rendering calls.
However if you need a very accurate circle with thousands of lines to get a good approximation it will be faster to simply use a bitmap and scale and blit it. This will also give you a 'smoother' feel to the circle.
In my personal opinion I do not think the hardware accelerated render API has much use outside of some special uses such as graph rendering and perhaps very simple GUI drawing. For anything more complex I would usually use bitmap based drawing.
With regards to the second part, it again depends on the accuracy of any arcs you need to draw. If you can easily approximate the shape into a few tens of lines it will be fast, otherwise the pixel method is better.
I am in the process of learning how to create a lens flare application. I've got most of the basic components figured out and now I'm moving on to the more complicated ones such as the glimmers / glints / spikeball as seen here: http://wiki.nuaj.net/images/e/e1/OpticalFlaresLensObjects.png
Or these: http://ak3.picdn.net/shutterstock/videos/1996229/preview/stock-footage-blue-flare-rotate.jpg
Some have suggested creating particles that emanate outwards from the center while fading out and either increasing or decreasing in size but I've tried this and there are just too many nested loops which makes performance awful.
Someone else suggested drawing a circular gradient from center white to radius black and using some algorithms to lighten and darken areas thus producing rays.
Does anyone have any ideas? I'm really stuck on this one.
I am using a limited compiler that is similar to C but I don't have any access to antialiasing, predefined shapes, etc. Everything has to be hand-coded.
Any help would be greatly appreciated!
I would create large circle selections, then use a radial gradient. Each side of the gradient is white, but one side has 100% alpha and the other 0%. Once you have used the gradient tool to draw that gradient inside the circle. Deselect it and use the transform tool to Skew or in a sense smash it. Then duplicate it several times and turn each one creating a spiral or circle holding Ctrl to constrain when needed. Then once those several layers are in the rotation or design that you want. Group them in a folder and then you can further effect them all at once with another transform or skew. WHen you use these real smal, they are like little stars. But you can do many different things when creating each one to make them different. Like making each one lower in opacity than the last etc...
I found a few examples of how to do lens-flare 'via code'. Ideally you'd want to do this as a post-process - meaning after you're done with your regular render, you process the image further.
Fragment shaders are apt for this step. The easiest version I found is this one. The basic idea is to
Identify really bright spots in your image and potentially down sample it.
Shoot rays from the fragment to the center of the image and sample some pixels along the way.
Accumalate the samples and apply further processing - chromatic distortion etc - on it.
And you get a whole range of options to play with.
Another more common alternative seems to be
Have a set of basic images (circles, hexes) and render them as a bunch of bright objects, along the path from the camera to the light(s).
Composite this image on top of the regular render of you scene.
The problem is in determining when to turn on lens flare, since it is dependant on whether a light is visible/occluded from a camera. GPU Gems comes to rescue, with better options.
A more serious, physically based implementation is listed in this paper. This is a real-time version of making lens-flares, but you need a hardware that can support both vertex and geometry shaders.
It is necessary to have a matrix representation of a set of geometric primitives (i.e., line, curve, circle, rectangle, also their filled forms). For simplicity you may suppose we are dealing only with lines, so the answer is already on [SO]. Rectangles therefore could be easily pixelated. For the rest of primitives however two questions appear to me:
1) How to pixelate a curve including circle (~closed curve)?
2) How to pixelate a filled simple / complex shape (rectangle, multi-patch)?
The simplest way (currently in use) may be utilizing a visualizing library (such a MatPlotLib for Python) to save the result (a map of geometric primitives) as a pixelated image on disk (or RAM) and then reuse it for the purpose of interest. Apparently, this method can handle any complexity since in background whatever it (the visualizer) does the output is a 2D image, i.e., 2D matrix. Some serious problems however emerge in this application:
1) the procedure is very slow!
2) the procedure is not standard but heavily dependent to the setting of the visualizer, that is often the low-level configuration is impossible or difficult to be set for visualizer. In other words, the black box being used lacks controlling on the procedure as required.
What you are doing is called "scan conversion" of geometric primitives.
For line segments, you already know about the Bresenham algorithm.
There is a similar one for circles, a bit trickier (as regards handling of the endpoints).
General curves is a broader topic. You can think of conics, splines or hand-drawn. One approach is to approximate them with a polyline.
To fill polygons, there is a scanline algorithm available (consider a sweeping horizontal line and fill between the intersections with the polygon outline).
To fill arbitrary shapes, an option is to draw the outline and use seed filling (from a given internal point).
You will find relevant material at http://www.cse.ohio-state.edu/~gurari/course/cis681/cis681Ch5.html
To give you some background as to what I'm doing: I'm trying to quantitatively record variations in flow of a compressible fluid via image analysis. One way to do this is to exploit the fact that the index of refraction of the fluid is directly related to its density. If you set up some kind of image behind the flow, the distortion in the image due to refractive index changes throughout the fluid field leads you to a density gradient, which helps to characterize the flow pattern.
I have a set of routines that do this successfully with a regular 2D pattern of dots. The dot pattern is slightly distorted, and by comparing the position of the dots in the distorted image with that in the non-distorted image, I get a displacement field, which is exactly what I need. The problem with this method is resolution. The resolution is limited to the number of dots in the field, and I'm exploring methods that give me more data.
One idea I've had is to use a regular grid of horizontal and vertical lines. This image will distort the same way, but instead of getting only the displacement of a dot, I'll have the continuous distortion of a grid. It seems like there must be some standard algorithm or procedure to compare one geometric grid to another and infer some kind of displacement field. Nonetheless, I haven't found anything like this in my research.
Does anyone have some ideas that might point me in the right direction? FYI, I am not a computer scientist -- I'm an engineer. I say that only because there may be some obvious approach I'm neglecting due to coming from a different field. But I can program. I'm using MATLAB, but I can read Python, C/C++, etc.
Here are examples of the type of images I'm working with:
Regular: Distorted:
--------
I think you are looking for the Digital Image Correlation algorithm.
Here you can see a demo.
Here is a Matlab Implementation.
From Wikipedia:
Digital Image Correlation and Tracking (DIC/DDIT) is an optical method that employs tracking & image registration techniques for accurate 2D and 3D measurements of changes in images. This is often used to measure deformation (engineering), displacement, and strain, but it is widely applied in many areas of science and engineering.
Edit
Here I applied the DIC algorithm to your distorted image using Mathematica, showing the relative displacements.
Edit
You may also easily identify the maximum displacement zone:
Edit
After some work (quite a bit, frankly) you can come up to something like this, representing the "displacement field", showing clearly that you are dealing with a vortex:
(Darker and bigger arrows means more displacement (velocity))
Post me a comment if you are interested in the Mathematica code for this one. I think my code is not going to help anybody else, so I omit posting it.
I would also suggest a line tracking algorithm would work well.
Simply start at the first pixel line of the image and start following each of the vertical lines downwards (You just need to start this at the first line to get the starting points. This can be done by a simple pattern that moves orthogonally to the gradient of that line, ergo follows a line. When you reach a crossing of a horizontal line you can measure that point (in x,y coordinates) and compare it to the corresponding crossing point in your distorted image.
Since your grid is regular you know that the n'th measured crossing point on the m'th vertical black line are corresponding in both images. Then you simply compare both points by computing their distance. Do this for each line on your grid and you will get, by how far each crossing point of the grid is distorted.
This following a line algorithm is also used in basic Edge linking algorithms or the Canny Edge detector.
(All this are just theoretic ideas and I cannot provide you with an algorithm to it. But I guess it should work easily on distorted images like you have there... but maybe it is helpful for you)
I have a need to do some drawing using win32/GDI (Native, not .NET), and I've run into the following problem:
I need to draw lines that are "styled." For example, in the attached image, the line marked "A" is a straight line as far as my application data is concerned, it just needs to be drawn with the additional zigzag as a style. Of course, this is easy to do programatically, but it gets more complicated when the line can be at any angle ("B") or even a bezier curve ("C").
Now, I could do this all programatically, painstakingly doing the math to put a zigzag around each line possibility, but that will take a lot of time and, more importantly, be rather error prone.
Is it possible to just give windows/GDI a "style" to apply to the line, perhaps a bitmap like the one marked "D", and have it use that as a pen to draw the lines? If not, is there a more flexible and less error-prone way of doing this than writing a bunch of specific drawing code for each of the "styled" lines?
*Apparently first timers can't post images. Examples can be found at http://i.imgur.com/IC0T2.png
This is not possible in Win32 GDI. You will need to do the math yourself.
It should be noted however, that you can obtain the points used to make up the line or curve which should make it substantially easier.
See this "Hit-Testing" tutorial for an example.
http://msdn.microsoft.com/en-us/library/ms969920.aspx
For a bezier curve you would use Path Functions:
BeginPath
PolyBezier
EndPath
FlattenPath
For straight lines you could use:
LineDDA
As far as I know there's nothing in GDI or even GDI+ that would support this. The only line options you have are dash-patterns, compound-pens, dash caps, end caps, and fill brushes.
You might be able to trick one of those functions into drawing something vaguely akin to your wiggles for straight splines, but it definitely won't work for curved splines.
It shouldn't be too hard to do this however. Sure, it will take a day or so, but all you have to do is write a line and bezier interpolator, divide the curves into equal segments, find the tangents at all those segments and alternate left and right. You'll end up with an array of points which can be drawn very quickly as a polyline.
There's nothing that'll do this automatically. You'll have to write some code. You might want to look at the LineDDA API in GDI. It might simplify the math your code will need.
ExtCreatePen(), maybe? I don't know for a fact if it supports zigzagging...