I want to develop a font engine so my GUIs look identical in all platforms. I've come to a pickle here as I want to make sure I approach it in the most productive angle, yet an angle that gives me the ability to implement as much as possible on my own (for learning purposes).
I just want an outline of how I should do it, maybe give some example paths that I can follow.
I was researching bezier curves but I don't think it was a good idea because I don't see how drawing only lines can scale up properly making the letters empty. I was also looking into implementing it with ttf font files but didn't see upscaling and downscaling being dependent on the image size as a practical thing, mainly because of memory consumption.
Also provide some advantages/disadvantages with your approach.
The curves define the boundary of the font glyph, from which you determine where to fill color. It is just like how a solid polygon is defined by line segments on its boundary.
Related
Working on a small side project related to Computer Vision, mostly to try playing around with OpenCV. It lead me to an interesting question:
Using feature detection to find known objects in an image isn't always easy- objects are hard to find, especially if the features of the target object aren't great.
But if I could choose ahead of time what it is I'm looking for, then in theory I could generate for myself an optimal image for detection. Any quality that makes feature detection hard would be absent, and all the qualities that make it easy would exist.
I suspect this sort of thought went into things like QR codes, but with the limitations that they wanted QR codes to be simple, and small.
So my question for you: How would you generate an optimal image for later recognition by a camera? What if you already know that certain problems like skew, or partial obscuring would occur?
Thanks very much
I think you need something like AR markers.
Take a look at ArToolkit, ArToolkitPlus or Aruco libraries, they have marker generators and detectors.
And papeer about marker generation: http://www.uco.es/investiga/grupos/ava/sites/default/files/GarridoJurado2014.pdf
If you plan to use feature detection, than marker should be specific to used feature detector. Common practice for detector design is good response to "corners" or regions with high x,y gradients. Also you should note the scaling of target.
The simplest detection can be performed with BLOBS. It can be faster and more robust than feature points. For example you can detect circular blobs or rectangular.
Depending on the distance you want to see your markers from and viewing conditions/backgrounds you typically use and camera resolution/noise you should choose different images/targets. Under moderate perspective from a longer distance a color target is pretty unique, see this:
https://surf-it.soe.ucsc.edu/sites/default/files/velado_report.pdf
at close distances various bar/QR codes may be a good choice. Other than that any flat textured object will be easy to track using homography as opposed to 3D objects.
http://docs.opencv.org/trunk/doc/py_tutorials/py_feature2d/py_feature_homography/py_feature_homography.html
Even different views of 3d objects can be quickly learned and tracked by such systems as Predator:
https://www.youtube.com/watch?v=1GhNXHCQGsM
then comes the whole field of hardware, structured light, synchronized markers, etc, etc. Kinect, for example, uses a predefined pattern projected on the surface to do stereo. This means it recognizes and matches million of micro patterns per second creating a depth map from the matched correspondences. Note that one camera sees the pattern and while another device - a projector generates it working as a virtual camera, see
http://article.wn.com/view/2013/11/17/Apple_to_buy_PrimeSense_technology_from_the_360s_Kinect/
The quickest way to demonstrate good tracking of a standard checkerboard pattern is to use pNp function of open cv:
http://www.juergenwiki.de/work/wiki/lib/exe/fetch.php?media=public:cameracalibration_detecting_fieldcorners_of_a_chessboard.gif
this literally can be done by calling just two functions
found = findChessboardCorners(src, chessboardSize, corners, camFlags);
drawChessCornersDots(dst, chessboardSize, corners, found);
To sum up, your question is very broad and there are multiple answers and solutions. Formulate your viewing condition, camera specs, backgrounds, distances, amount of motion and perspective you expect to have indoors vs outdoors, etc. There is no such a thing as a general average case in computer vision!
I have an SVG file.This file shows the outline of cartoon character(2D character).
My question is, can I make a program that It allows the user to interact with the outline and deform it.
An example is, to pull the outline of character's arm, with the mouse,and the arm gets bigger.
I suppose that Bezier Curves and Elliptical Arcs is a solution.I also wonder if i use OPENGL, I might be more flexible to do that.
The interaction aspect you'll need to deal with yourself. There is a recent OpenGL extension, NV_path_rendering which makes accurate, hardware-accelerated rendering of SVG and other vector formats pretty simple. The SDK includes at least one example where interaction with control points is shown, which might make a good starting place for you. Obviously, this would require you/the end user to have a GPU which supports the extension. Here's a video of the developer explaining the extension and what it can do.
I also wonder if i use OPENGL, I might be more flexible to do that.
OpenGL will not make things easier in any way. OpenGL is a drawing API, not some kind of magic scene and geometry manager. All it gives you are points, lines and triangles and methods to define how those are to be drawn to a framebuffer.
Interaction with the user lies completely outside the scope of OpenGL.
iscriptdesign allows you to create interactive graphics, but you need to program/script those yourself.
Does anyone know of an implementation of vector fonts in directx?
If not does anyone have a good starting place for this?
Or even any examples of a reader written in Directx with basic zoom support.
Direct vector fonts don't work to well in D3D, as it requires an intermediary texture to hold rasterized data(verts or pixels) and need to do a lot more extra work, thus you need a approach them a little differently to get them working easily and efficiently(if you are performance constrained/care about performance). You should use signed distances fields for this (they up-scale VERY well, but are horrid for down-scaling if your fonts are complex. Hard edges also don't store too well, but this can be fixed by using two channels to store data. Distance fields also allow easy smoothing, bolding, outlining, glowing and drop shadows), al la valve's improved alpha tested advanced vector texture rendering (which incidently references a paper on vector fonts, if you do want to go that way). It is heavily shader reliant (though it can be done in FFP via alpha testing, but using smoothstep in the pixel shader provides a far better result with minimal overhead), but one doesn't need anything beyond ps v1. see http://www.valvesoftware.com/publications.html for the paper, see the shaders in valves source sdk for a complete implementation reference. (I incidently just built a Dx11 based text renderer using this, works wonderfully, though I use a tool to brute force my sdf's so I don't need to create them at runtime).
I am learning opengl es and am planning to make a program which will have a shape which can be cut into a smaller shape by removing a part of the shape dynamicly. The constraint is I must be able to tell if an object is inside or outside the cut shape.
The option I thought of are:
1) use a stencil buffer made up of just a black and white mask. This way I can also use the same map for collision detection.
2) the other option is to dynamicly change my mind renderd primitive an then tesselating it. This sounds more complex and is currently my least favorite option. It would also make the collision detection more difficult.
PS
I would like the part of the shape removed to be fall of in animation, I am not sure how choosing any of these methods will affect the ease of doing so. Please express your opinion.
What are your thoughts on this?
Keep in mind that I am new to opengl an might be making mistakes without realizing it.
Thanks, Jason
It is generally considered a good idea to issue only write-commands to the graphics card. Basically that is "dont use glGet* commands at all", because the latency of those commands might be somewhat high.
That said option 1) is great if you just want to mask out stuff. As you are trying to make the cut part fall off this is really not an option, as you have to retrieve/reconstruct the vertices of that part.
I don't quite get the "tesselation" part of your second option, but if your primitive is a polygon and your cuts are straight lines, it is easy to calculate the 2 polygons after the cut. In fact the viewport clipping routine in OpenGL does that all the time and there is a lot of literatur, for example http://en.wikipedia.org/wiki/Sutherland-Hodgman
In the long term it is often way better to first build a (non-visual) model of what is going on in the application before visualizing.
I want to render font in a way that takes account of the current transforms and similar settings, especially the projection transform and viewport.
I'm thinking that the best way to do that is to have an off screen surface to render the text to, and then render that surface where I really want the text.
However I'm not certain on a number of aspects of this solution.
Is this the best way to go about it at all?
Are there far better free font renderers around that id be better off spending my time with that allow such things. I see alot of people complaining about the d3dx font interfaces for various reasons, but never a link to a better unicode capable renderer...?
Is there any advantage to useing certain surface formats and/or surface sizes (eg always using the smallest possible rather than some standard large one, which requires the extra step of trying to work the size out...)
Yeah, render to texture and then drawing a textured quad to orient and position the text is going to be the easiest way to realize this functionality.
As for D3DX text renderers, it really depends on which SDK you are using. DirectWrite (only for Windows 7 and Vista) will provide a higher quality text rendering approach for applications that need high quality text rendering in a manner that is interoperable with Direct3D.
You can of course do your own rasterization. There are font rasterization engines out there that are open source that could be repurposed for this need, but we're talking tons of coding here for a benefit that may not be distinguishable enough to warrant the development expense.
Having said that, there's a completely new alternative available to you with Direct3D and shaders, provided that you have access to the glyph outlines as curve data. The idea is to use the shader to rasterize the text and store the curve definitions in the vertex stream and associated textures. Try looking at this paper, which describes the technique.