I'm using the DrawLine function on the render target and would like to always draw a line that is one (device independent) pixel thick.
My problem is that I have a transform which has wildly different horizontal and vertical dimensions, and it appears that I can only scale the strokeWidth for one of these dimensions.
I can just set the transform to the Identity, and use the matrix transform point to translate each point to my device independent coordinates which achieves the correct result, but the work isn't being offloaded to the GPU.
Is there a way to do this so that I can let the transform on the render target do the work?
I'm using SharpDX from C#, but I'm happy to translate any c++ answer.
You should be able to take advantage of the fact that the transform on ID2D1RenderTarget is absolute. There is no push/pop system, and you can always just set the transform to the identity matrix. With this knowledge, you should be able to 1) create the geometry that you want, 2) transform it by the matrix on the render target (ID2D1Factory::CreateTransformedGeometry(), although you're correct that this is not hardware accelerated), 3) set the render target's transform to the identity matrix, 4) draw the geometry w/ a 1px stroke width, 5) restore the original transform onto the render target.
Also, the version of Direct2D that comes with Win8 has some features to let you always draw with a 1px wide line, regardless of the transform. You create a stroke style and specify D2D1_STROKE_TRANSFORM_TYPE_HAIRLINE for the transformType.
Related
I know there's a function to fill rectangles surface.FillRect(&Rect, uint32), but is there a way to draw a line in the surface, like a function for renderer renderer.DrawLine(x1, y1, x2, y2)?
In SDL2 Surface is just a structure that represents a bitmap (2D matrix of pixels) in driver agnostic format. In terms of drawing Surface API is limited to setting pixels or easily defined groups of them (rectangles) or blitting (copying) rectangles of one surface to the other. With that API you technically can draw a line by calculating coordinates of each pixel on that line between coords x1,y1 and x2,y2 and setting each pixel to the desired color. In SDL2 library itself there is no such utility function.
Renderer is much more advanced API that takes care of many underlying aspects of accelerated rendering. On top of single pixels and rectangles it offers also line primitives. Instead of Surface it uses Texture which stores pixels in an optimized format for underlying graphics driver (and thus provides higher performance when drawing). If you are working on something new you should stick with Renderer. If you need to plug code based on Surface to Renderer code, you can create Texture from Surface data using the Renderer.CreateTextureFromSurface() method.
Is there any way to render a different set of screen coordinates than the standard equidistant grid between -1,-1 to 1,1?
I am not talking about a transformation that can be accomplished by transformations in the vertex shader.
Specifically ES2 would be nice, but any version is fine.
Is this even directly OpenGl related or is the standard grid typically provided by plumbing libraries?
No, there isn't any other way. The values you write to gl_Position in the vertex (or tesselation or geometry) shader are clip space coordinates. The GPU will convert these to normalized device space (the "[-1,1] grid") by dividing by the w coordinate (after the actual primitive clipping, of course) and will finally use the viewport parameters to transform the results to window space.
There is no way to directly use window coordinates when you want to use the rendering pipeline. There are some operations which bypass large parts of that pipeline, like frambuffer blitting, which provides a limited way to draw some things directly to the framebuffer.
However, working with pixel coordinates isn't hard to achieve. You basically have to invert the transformations the GPU will be doing. While typically "ortho" matrices are used for this, the only required operations are a scale and a translation, which boils down to a fused multiply-add per component, so you can implement this extremely efficient in the vertex shader.
Could you please share some code (any language) on how draw textured line (that would be smooth or have a glowing like effect, blue line, four points) consisting of many points like on attached image using OpenGL ES 1.0.
What I was trying was texturing a GL_LINE_STRIP with texture 16x16 or 1x16 pixels, but without any success.
In ES 1.0 you can use render-to-texture creatively to achieve the effect that you want, but it's likely to be costly in terms of fill rate. Gamasutra has an (old) article on how glow was achieved in the Tron 2.0 game — you'll want to pay particular attention to the DirectX 7.0 comments since that was, like ES 1.0, a fixed pipeline. In your case you probably want just to display the Gaussian image rather than mixing it with an original since the glow is all you're interested in.
My summary of the article is:
render all lines to a texture as normal, solid hairline lines. Call this texture the source texture.
apply a linear horizontal blur to that by taking the source texture you just rendered and drawing it, say, five times to another texture, which I'll call the horizontal blur texture. Draw one copy at an offset of x = 0 with opacity 1.0, draw two further copies — one at x = +1 and one at x = -1 — with opacity 0.63 and a final two copies — one at x = +2 and one at x = -2 with an opacity of 0.17. Use additive blending.
apply a linear vertical blur to that by taking the horizontal blur texture and doing essentially the same steps but with y offsets instead of x offsets.
Those opacity numbers were derived from the 2d Gaussian kernel on this page. Play around with them to affect the fall off towards the outside of your lines.
Note the extra costs involved here: you're ostensibly adding ten full-screen textured draws plus some framebuffer swapping. You can probably get away with fewer draws by using multitexturing. A shader approach would likely do the horizontal and vertical steps in a single pass.
I've already got my ROI(CvBOX2D type) by series of contour processing, now I just want to focus on the image part within the ROI, e.g.: feed this part into another processing function, how can I do that? I know there is CvSetImageROI, but the type is CvRect, so I should convert CvBox2D to CvRect first? Or some way to apply a mask on it with the area outside the box set to 0?
Thanks in advance!
Only axis aligned ROIs are directly supported in OpenCV (CvRect or IplROI). This is because they allow direct access to the image memory buffer.
There are 2 ways to go about working on a non-axis aligned ROI in OpenCV. Neither of them is as efficient as using axis-aligned ROIs.
Rotate your image, or bounding box, so that your ROI is now axis aligned in the resulting rotated image.
Note: the rotation will slightly blur your image.
Use a mask: Draw your ROI as a white rectangle on a black BG the same size as the image, and give your processing functions this mask as the additional parameter.
Note: not all functions support masks.
I would recommend option 1 if you really must stay within the exact bounds of your ROI. Otherwise, just use the bounding rect.
Use c++ api of opencv. seriously. do it.
cv::Rect roi = cv::RotatedRect(box).boundingRect();
Mat_<type> working_area(original_mat, roi);
// now operate on working_area
Note: this will operate on the bounding rect. I didn't find information on how to create a mask out of rotatedrect. Probably you have to do it by hand in a scanline fashion.
I'm using GDI+ in my application, and I need to use a rotated LinearGradientBrush to paint several rects in the exact same way. However, although I'm calling the same code to fill each rect, the results aren't what I expect. Here's the code to create the gradient fill, where rcDraw is the rect containing the area to paint for each rect. These coordinates are in the parent window's coordinates, so they are not identical for the 2 rects.
g_hbrLinear = new LinearGradientBrush( Rect( 0, rcDraw.top, 0, rcDraw.bottom - rcDraw.top ),
clrStart, clrEnd, (REAL) 80, FALSE );
What I see on screen looks like this (http://www.nnanime.com/bugs/LinGradBrush-rotate10.png). You can see that it's as if the fill from the first rect continues into the second one. What I really want is to have the 2 rects look identical. I think I can do that if I paint each rect separately using its own client coordinates, but for the purposes of my app, I need to use the parent window's coordinates.
I guess what I'm asking is, how does GDI+ calculate the "origin" of a fill? Is it always based on 0,0 in the coordinate system you use? Is there a way to shift it? I tried TranslateTransform, but it doesn't seem to shift the fill in a way that I find predictable or understandable.
The rect passed to the linear gradient brush determines the where the left and right colors will sit, and the gradient will be painted within this rectangle.
So, I think you need to create a brush for each rectangle you are painting, where the rectangle you are painting is also passed to the constructor for the linear gradient brush.
My experience with the "transform" of linear gradient brushes matches yours; I haven't been able to understand what it's supposed to do.
You can think of a brush in GDI+ as a function mapping world co-ordinates to a color. What the brush looks like at a given point does not change based on the shape being filled.
It does change with the transform of the Graphics object you're drawing on. So, if you don't want to change the brush, you could temporarily change the transform of the Graphics object so that the rectangle you're drawing has a specific, known size and position in world coordinates. The BeginContainer and EndContainer methods should make this easy.
(There is also the RenderingOrigin property but it only affects hatch brushes, which oddly are unaffected by world transforms.)