I use this uml graphing doclet a lot and it is really cool. But it generates diagrams i don't fully understand.. In particular sometimes my packages have thick arrows between them, sometimes dependencies are represented by thinner arrows..
like in this example >
External link for larger view:
i have not figured out the difference in the types of dependencies that causes the doclet to choose one representation vs. the other. anyone else figure this out ?
thx in advance
cb
For package dependency diagrams, yDoc keeps count of how many individual dependencies exist between two packages. For every five dependencies, the thickness of the corresponding connection is increased by one pixel (up to a seven pixel maximum).
In short: The thicker the line, the "stronger" the dependency.
Related
I am developing a prototype and so making UML Diagrams, for my USE CASE, I need to show the data being sent and received from a smart watch, I was wondering if there is a standard symbol for it or I should just draw one myself?
I have been using the attached.
UML gives you the freedom to attach any shape to a stereotype. You can show it pure or as adornment in a corner of the rectangular element representation.
There is no standard other than rectangles (most UML elements), ovals (Use Cases), stickmen (Actors), rounded rects (Activities, Actions) and circles (mostly for state elements). (If there are more, they are quite uncommon and slipped my mind.)
For your watch you can take whatever you want. This one looks okay (although to me it looks more like a satellite).
Definitely not, UML is not that much specific, "portable computing device" is as specific as you'll get. So pick something here
Good day, I was wondering on how can I implement an effect like the ones on the sweepstakes where you scratch the grey part and reveal a number underneath it. I was wondering how can I implement that in unity, I don't have any clue where to start, thanks in advance.
the idea is, I have 2 overlapping objects, A and B, whereas when I click on a part of B it will be removed and will show a part of A, both A and B are sprite images though
This is not really related to Unity as such. This relates more to a general technical solution for a visual representation you would like to do.
So, let's skip the Unity part.
But even then the question is very general and hard to respond to. There are many ways to achieve this, depending on the result you want.
You could apply a quad object, with a grey texture on top of whatever number box you have and then either use shaders to show the number as you "scratch it". Or you could remove the grey square when clicking it (different behaviour). Or you could do the old school approach and replace pixels, as you "scratch" the box.
Only to mention a few ideas.
But still, the question is very general and hard to answer as it pertains to a general idea, and not so much a concrete question.
Look into how to build Fog of war shader. I would achieve this by rendering A and B with two separate cameras then as you scratch it off it would reveal B in the scratched area.
I am scouring the web for tools, programs, utilities, supporting libraries and code primitives that help optimize SVGs for simplicity, space and elegance recently, to link to from the Kilobyte SVG Challenge's tools section, but have yet to find good primitives focusing on how to reduce the number of coordinates of a path, without losing much – or ideally any – precision.
Take this marker-augmented version of the Coca Cola logo, for instance (~7kb, essentially all path data) – which very clearly shows lots of promise for reducing its number of bèziers, given some tooling to do the math to come up with a path using fewer nodes, while producing essentially the same curve.
For the much simpler problem of polygons and polylines (read "all-line paths"), you can use the Douglas–Peucker or Visvalingam’s algorithm (see Mike Bostock's excellent d3 implementation of the latter) to simply remove the coordinates least affecting the path's shape until you're happy with a size-to-precision fit suiting your needs.
I am looking for the equivalent that notices where larger curve (or even arc) segments could replace lots of these redundant mid-curve coordinate stops, without lots of manual tweaking. I think some vector graphics packages (Adobe Illustrator, maybe even Inkscape?) may offer features like these (tips on how to access them welcome!) - though I would love to find scriptable tools we can recommend and offer HOWTOs of how to use from the command line, or even web apps, that squeeze out excess path filler material for people.
For reference, the Kilobyte SVG Challenge is a for-fun SVG education and advocacy stunt I have set up, recently. All non-question-topic discussion about it are best held there, and/or on its github repository linked above. Stay awesome! :)
You can use Ramer–Douglas–Peucker algorithm to simplify polylines or polygons path.
I've seen antialiasing on Windows using GDI+, Java and also that provided by Photoshop and Gimp. Are there any other libraries out there which provide antialiasing facility without depending on support from the host OS?
Antigrain Geometry provides anti-aliased graphics in software.
As simon pointed out, the term anti-aliasing is misused/abused quite regularly so it's always helpful to know exactly what you're trying to do.
Since you mention GDI, I'll assume you're talking about maintaining nice crisp edges when you resize them - so something like a character in a font looks clean and not pixelated when you resize it 2x or 3x it's original size. For these sorts of things I've used a technique in the past called alpha-tested magnification - you can read the whitepaper here:
http://www.valvesoftware.com/publications/2007/SIGGRAPH2007_AlphaTestedMagnification.pdf
When I implemented it, I used more than one plane so I could get better edges on all types of objects, but it covers that briefly towards the end. Of all the approaches (that I've used) to maintain quality when scaling vector images, this was the easiest and highest quality. This also has the advantage of being easily implemented in hardware. From an existing API standpoint, your best bet is to use either OpenGL or Direct3D - that being said, it really only requires bilinear filtered and texture mapped to accomplish what it does, so you could roll your own (I have in the past). If you are always dealing with rectangles and only need to do scaling it's pretty trivial, and adding rotation doesn't add that much complexity. If you do roll your own, make sure to pay particular attention to subpixel positioning (how you resolve pixel positions that do not fall on a full pixel, as this is critical to the quality and sometimes overlooked.
Hope that helps!
There are (often misnamed, btw, but that's a dead horse) many anti-aliasing approaches that can be used. Depending on what you know about the original signal and what the intended use is, different things are most likely to give you the desired result.
"Support from the host OS" is probably most sensible if the output is through the OS display facilities, since they have the most information about what is being done to the image.
I suppose that's a long way of asking what are you actually trying to do? Many graphics libraries will provide some form of antialiasing, whether or not they'll be appropriate depends a lot on what you're trying to achieve.
I am looking for an algorithm or library (better) to break down a polygon into triangles. I will be using these triangles in a Direct3D application. What are the best available options?
Here is what I have found so far:
Ben Discoe's notes
FIST: Fast Industrial-Strength Triangulation of Polygons
I know that CGAL provides triangulation but am not sure if it supports holes.
I would really appreciate some opinions from people with prior experience in this area.
Edit: This is a 2D polygon.
To give you some more choices of libraries out there:
Polyboolean. I never tried this one, but it looks promising: http://www.complex-a5.ru/polyboolean/index.html
General Polygon Clipper. This one works very well in practice and does triangulation as well as clipping and holes holes: http://www.cs.man.ac.uk/~toby/alan/software/
My personal recommendation: Use the tesselation from the GLU (OpenGL Utility Library). The code is rock solid, faster than GPC and generates less triangles. You don't need an initialized OpenGL-Handle or anything like this to use the lib.
If you don't like the idea to include OpenGL system libs in a DirectX application there is a solution as well: Just download the SGI OpenGL reference implementation code and lift the triangulator from it. It just uses the OpenGL-Typedef names and a hand full of enums. That's it. You can extract the code and make a stand alone lib in an hour or two.
In general my advice would be to use something that alreay works and don't start to write your own triangulation.
It is tempting to roll your own if you have read about the ear-clipping or sweep-line algorithm, but fact is that computational geometry algorithms are incredible hard to write in a way that they work stable, never crash and always return a meaningful result. Numerical roundoff errors will accumulate and kill you in the end.
I wrote a triangulation algorithm in C for the company I work with. Getting the core algorithm working took two days. Getting it working with all kinds of degenerated inputs took another two years (I wasn't working fulltime on it, but trust me - I spent more time on it than I should have).
Jonathan Shewchuk's Triangle library is phenomenal; I've used it for automating triangulation in the past. You can ask it to attempt to avoid small/narrow triangles, etc., so you come up with "good" triangulations instead of just any triangulation.
CGAL has the tool you need:
Constrained Triangulations
You can simply provide boundaries of your polygon (incuding the boundaries of the holes) as constraints (the best would be that you insert all vertices, and then specify the constraints as pairs of Vertex_handles).
You can then tag the triangles of the triangulation by any traversal algorithm: start with a triangle incident to the infinite vertex and tag it as being outside, and each time you cross a constraint, switch to the opposite tag (inside if you were previously tagging the triangles as outsider, outside if you were tagging triangles as insider before).
I have found the poly2tri library to be exactly what I needed for triangulation. It produces a much cleaner mesh than other libraries I've tried (including libtess), and it does support holes as well. It's been converted to a bunch of languages. The license is New BSD, so you can use it in any project.
Poly2tri library on Google Code
try libtess2
https://code.google.com/p/libtess2/downloads/list
based on the original SGI GLU tesselator (with liberal licensing). Solves some memory management issues around lots of small mallocs.
You can add the holes relatively easily yourself. Basically triangulate to the convex hull of the input points, as per CGAL, and then delete any triangle whose incentre lies inside any of the hole polygons (or outside any of the external boundaries). When dealing with lots of holes in a large dataset, masking techniques may be used to significantly speed this process up.
edit: A common extension to this technique is to weed weak triangles on the hull, where the longest edge or smallest internal angle exceeds a given value. This will form a better concave hull.
I have implemented a 3D polygon triangulator in C# using the ear clipping method. It is easy to use, supports holes, is numerically robust, and supports aribtrary (not self-intersecting) convex/non-convex polygons.
This is a common problem in finite element analysis. It's called "automatic mesh generation". Google found this site with links to commercial and open source software. They usually presume some kind of CAD representation of the geometry to start.
Another option (with a very flexible license) is to port the algorithm from VTK:
vtkDelaunay2D
This algorithm works fairly well. Using it directly is possible, but requires links to VTK, which may have more overhead than you want (although it has many other nice features, as well).
It supports constraints (holes/boundaries/etc), as well as triangulating a surface that isn't necessarily in the XY plane. It also supports some features I haven't seen elsewhere (see the notes on Alpha values).