Imagine you are drawing a map of county borders. You are given a set of polygons, one for each boundary, and you draw each polygon.
In places where two counties share a border you just end up drawing the border twice. In the absence of partial transparency effects, and with a solid pen, this is no problem.
But, on maps, borders of this kind are customarily shown by dash-dotted lines. In this case, situations like the one depicted below can happen:
Notice how the dash pattern, which normally is dash-dot-dot, gets screwed up where the two areas share a border. In this case, it happened to become a longdash-dot pattern, but in general it could do anything from coincidentally looking normal to creating a solid line.
How does/should map rendering software prevent artifacts of this kind from occuring?
The artifact is due the fact that the piece of border is drawn twice. Instead of trying to supress such artifacts, you could try to not draw border sections twice, by keeping a list of segments already drawn in memory, and if you encounter a stretch that's already drawn, you don't draw it again.
Your brush pattern colors some pixels black and leaves some pixels alone. Instead of leaving the pixel alone, can you set up your brush pattern to color those pixels white (or whatever your background color is)?
Another possibility is to always draw your county borders twice -- once with a solid white pattern, and again with the brush pattern of your choice.
I suppose they break their border lines into segments, then remove the overlaps.
This is mostly a geometric problem, not a drawing problem.
Instead of going with a dashed line, you could do it Zip-a-tone style, like this:
Zip-a-tone was this graphic art stuff that was basically a sticky sheet of plastic with a regular (printable) pattern of dots on it. To use it, you would lay a big sheet of it over your drawing and cut it around the areas on your drawing that you wanted zip-a-toned, and then peel off the parts you didn't want.
For this image, I just went with an alternating checkerboard pattern, with the lines two pixels wide. Because all the lines are drawn from one big (virtual) block of this checkerboard pattern, you never have to worry about weird artifacts at the joints or any overlap effects.
Angled lines are a bit tricky, but basically you imagine the edges of the line sort of cutting through pixels, and thus you draw them at the appropriate shade of grade instead of full black (in the case of the 45 degree line here, the pixels are drawn with RGB(170, 170, 170), but any angle could be rendered with appropriate shades).
I'm not sure if GDI+ could do this easily using the textured brushes, but maybe. Otherwise you'd have to custom-code it. The advantage of this method over just solid gray lines would be that this would allow some of the background to show through.
This is an interesting question that I never really thought about. I think the only real solution is to render the entire complex figure as a series of lines or paths that do not overlap anywhere. I'm not surprised that GDI+ doesn't handle this situation in any automatic way.
Related
I am currently trying to label lines that I draw in my Map (in my iOS app, but I guess it applies to all maps).
So what I currently am doing, I simplify my path so that I get rid of most small curves and then just draw my glyphs along that line. Currently that looks like this:
On some parts of the line that's already ok. If the line is quite straight and the corners aren't too spiky.
But in some parts you can just not read anything... So what are strategies to make that look nicer?
Does anybody know an algorithm or a strategy on how to make my path look like the red line here:
I am happy about any ideas on how to improve my drawing :)
I do it, in my commercial map rendering system, by finding a portion of the line without sharp corners. There is no way to make the label look good if it turns corners of a right angle or greater. If there's no section long enough I abbreviate the label (e.g., Link Road becomes Link Rd), or split it on to two lines. If there's still nowhere to draw the label I don't draw it.
Another thing that's important is to adjust the spacing so that ascenders and descenders don't clash, so you need to look at the bounding box of each adjacent pair of letters as you draw the text and add small amounts of space as necessary.
I don't bother to smooth my lines, as you suggest with your red line. It really doesn't seem to matter, at least with street labelling.
Say you have an array of points and an array of rects, and you want to do the following:
Draw a line that connects all the points in the point array, such that the parts of the line that are contained in at least one of the rects are not visible.
What is the best practice way to accomplish such a task in cocos2d ios?
This may sound like a hack, but if you are drawing the rectangles as well then you can draw them with a higher zOrder with respect to the line and the rectangles would could cover the parts of the lines they contain making those parts invisible.
Hope it helps!
For example, I have a transparent png file, the shape is a car.
In the png file, I only draw the white border shape.
Outside and inside the border are all transparent.
I want to use actionscript3 code to show the car object with different color, it means only fill color inside the border, and for the outside of the border, keep transparent.
How to do that?
So far, the simplest workaround is to prepare many images with PhotoShop, but it's not good enough for me. When I have many shapes and use many colors, I've to prepare many many images.
Add more details:
(Because I'm using white border, you may not see the basic png file if your background of browser is white)
Change my boarder of shape to black, hope this is helpful to understand my question.
Since you're working with loaded images/pixels you can make use of BitmapData's floodFill() which pretty much does what you need. There's an example in bellow the method description as well.
It does pretty much what you need, although in some cases it might not be perfect. It's worth having a look at Jan's optimizing the floodFill() method article which goes more in depth.
A simple solution is to use multiple layers. The top layer would contain just the border. The lower layer would contain just the car with no border. You can adjust the colour of the car layer using a ColorTransform or ColorMatrixFilter.
I'm drawing some cars. They're Bitmap's, loaded from PNG's in the library. I need to be able to color the cars-- red ones and green ones and blue ones, whatever. However, when you paint the car green, the tires should stay black, and the windows stay window-color.
I know of two ways to handle this, neither one of which makes me happy. First, I could have two bitmaps for each car; one underneath for the body color, and one on top for detail bits. The underneath bitmap gets its transform.colorTransform set to turn the white car-body into whatever color I need. Not great, because I end up with twice as many Bitmap's running around on screen at runtime.
Second, I could programmatically search-and-replace "white" with "car-body" color when I load the bitmap for each car. Not great either, because the amount of memory I take up multiplies by however many colors I need.
What I would LIKE would be a way to say "draw this Bitmap with JUST THE WHITE PARTS turned into this other color" at runtime. Is there anything like this available? I will be less than surprised if the answer is "no," but I figure it's worth asking.
You might have answered the question yourself.
I think your first approach would need only two transparent images: one with pixels of the parts that need to change colour, one with the rest of the image. You will use colorTransform or ColorMatrix filter by case. It might even work with having the pixels the need the colour change covered with Sprite with a flat colour set on overlay ?
The downside would be that you will need to create a 'colour map'/set of pixels to replace for each different item that will need colour replacement.
For the second approach:
You might isolate the areas using something like threshold().
For speed, you might want either to store the indices of the pixels you need to replace in an Vector.<int> object that could be used in conjuction with BitmapData's getVector() method. (You would loop once to fetch the pixel indices that need to be replaced)
Since you will use the same image(same dimensions) to fill the same content with a different colour, you'll always loop through the same pixels. Also keep in mind that you will gain a bit of speed by using lock() before your loop to setPixel() and unlock() after the loop.
Alternatively you could use Pixel Bender and try some green screen/background subtraction techniques. It should be fast and wouldn't delay the execution of the rest of your as3 code as Pixel Bender code runs in it's own thread.
Also check out Lee's Pixel Bender subtraction technique too.
Although it's a bit old now, you can use some knowledge from #Quasimondo's article too.
HTH
I'm a little confused where you see the difference between your second approach and the one you would like to have. You can go over your loaded bitmap pixel by pixel and read out the color. If it turns out to be white replace it with another color. I do not see occurence of multiplied memory consumption.
You might want to try my selective color transform: http://www.quasimondo.com/archives/000614.php - it's from 2006, so some parts of it could probably be replaced by a pixel bender filter now.
Why not just load the pieces separately, perform the color transform on the one you want to change, then do a BitmapData.copyPixels() with the result? The blit routine runs in machine code, so is wicked fast. Doing it pixel by pixel in ActionScript would be glacially slow in comparison.
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/display/BitmapData.html#copyPixels()
Can anyone share a sample code to draw a non-rectangular part of a picture in delphi canvas?
You're looking for GDI paths. Start here, which explains what paths are in this context, and provides links on the left to explain the functionality available with them.
Google can turn up lots of examples of using paths in Delphi. If you can't find them, post a comment back here and I'll see what I can turn up for you.
Your question is pretty vague. But I suspect what you are looking for is clipping regions. Read up on them. Set the clipping region on the target device to the shape you want, and then draw the image onto the device. Only the part of the image that would be within the clipping region will be drawn.
Canvas.Ellipse(0, 0, 10, 20); // not a rectangle
I use so called runlists for this feature (generalized shapes and blitting them). I've seen them called warplists too. A shape is encoded as a runlist by defining it as a set of horizontal lines, and each line is two integer values (skip n pixels,copy n pixels).
This means you can draw entire lines, leaving you with only "height" draw operations.
So a rectangle is defined (the first "skip" pixels from top level corner to the left corner (xorg,yorg). The rectangle is width_rect wide, and width_pixels goes a line further. width_pixels can be wider than the width of the picture (alignment bytes)
(yorg*width_pixels+xorg , width_rect),
(width_pixels-width_rect , width_rect),
(width_pixels-width_rect , width_rect),
(width_pixels-width_rect , width_rect),
..
..
This way you can make your drawing routines pretty generic, and for simple, regular shapes (rects, circles) it takes only minor math to precalculate these lists. It simplified my shape handling enormously.
However I draw directly to bitmaps, not to canvasses, so I can't help with that part. A primitive that efficiently draws a row, and a way to extract a row from a graphic should be enough.