When you use Graphics object to draw very large shape(that does not fit in 10000x10000 pixels) stroke width may become much wider than value specified in lineStyle function.
What are the workarounds to overcome this?
For now I have only two options:
1. When drawing line you can split it into several lines. However this trick does work only for drawing lines, polylines and polygons. There is no way to apply this to drawing circles and ellipses. Well, we can approximate circles via bezier curves, but this approach seems to be very inefficient.
2. Perform manual cliping. But this require manual implementation of different cliping techiniques, and I think ActionScript does not suit well for this sort of task. And again there is need to approximate visible parts of large circles.
Out of interest are you using the scrollRect as this will prevent anything not in the view port from being drawn and will hopefully help you solve this.
Andrew
Related
I was following the guide at https://kateto.net/network-visualization, and was wondering if there is a way to set the curvature of the polygons produced by the mark.groups option to zero, and so that their borders are straight lines (ideally they would still "loop around" the different sized nodes).
If possible, I would like the polygons to wrap exactly around each node (without any space inbetween), but if that is not possible, I can work with setting the size of the nodes to zero.
Any help is appreaciated. I can also work with other software if necessary.
I couldn't find the docs before, but found them now. The additional options are mark.expand=0 and mark.shape=0: https://igraph.org/r/doc/plot.igraph.html
I am playing around with rgl and I have created a 3D rendering of the mouse brain, in which structures can be isolated and coloured separately.
The original data is a 3D array containing evenly spaced voxels.
Every voxel is coded with a structure ID.
Every structure is rendered separately as a mesh by marching cubes, and smoothed using Laplacian smoothing as implemented by Rvcg.
Some of these structures can be quite small, and it would make sense to look at them within the context of the whole brain structure.
One of the options is to create a low-threshold mesh of the whole set of voxels, so that only the outer surface of the brain is included in the mesh.
This surface can be smoothed and represented using a low alpha in rgl::shade3d colouring faces. This however seems to be quite taxing for the viewport as it slows down rotation etc especially when alpha levels are quite low.
I was wondering if there is any way to implement some sort of cel shading in rgl, e.g. outlining in solid colours the alpha hull of the 2D projection to the viewport in real time.
In case my description was not clear, here's a photoshopped example of what I'd need.
Ideally I would not render the gray transparent shell, only the outline.
Cel shading example
Does anybody know how to do that without getting deep into OpenGL?
Rendering transparent surfaces is slow because OpenGL requires the triangles making them up to be sorted from back to front. The sort order changes as you rotate, so you'll be doing a lot of sorting.
I can't think of any fast way to render the outline you want. One thing that might work given that you are starting from evenly spaced voxels is to render the outside surface using front="points", back="points", size = 1. Doing this with the ?surface3d example gives this fake transparency:
If that's not transparent enough, you might be able to improve it by getting rid of lighting (lit = FALSE), plotting in a colour close to the background (color = "gray90"), or some other thing like that. Doing both of those gives this:
You may also be able to cull your data so the surface has fewer vertices.
I'm looking into creating a web application trough witch the user could draw an arbitrary picture on a canvas (only lines involved, no fill and no different colors) and then obtain an equation witch graphs the same picture they've drawn. Does anybody has any idea on witch approach would be the most sensible one?
I thought about simply using Bézier curves to draw and then calculate it's equation, but I wanted to know if there's any other approach which might be more appropriate.
I have a graph like:
I would like to generate a set of (x,y) pairs that correspond to points of this graph.
Maybe one for each horizontal pixel.
How would I go about doing this?
If I had the image in uncompressed bitmap format, maybe cropped to the actual graph, I could examine each vertical strip for the blackest point...
I would prefer to work in Python, but I'm interested in any technique.
I answered a question like this a while back. It should be fairly easy to detect the grid, from there you can get the pixel's coordinates relatively to the grid. However, it wasn't clear how to extract the numbers, which you need to do in order to get the the scale of the grid. Although, it might be possible fairly easily if you can match the font and font size (which might be possible via scaling). Otherwise, you'd have to enter the numbers manually.
To extract the grid, you'd start from the top right and move diagonally until you find the start of the grid. From there you can follow the vertical and horizontal lines (of the grid) until they end. This should allow you to say with fairly high probability where the outer rectangle of the grid is and what the x and y intervals of the grid are in terms of pixels. The blackest parts within the grid should do for finding the curve, but it may require some interpolation depending on how many data points you need/want.
It also may be useful to look into techniques for reversing anti-aliasing effects. Although, the uncompressed bitmap image may not need it.
I'm having a graphics problem on drawing lines in Flash Player, where two lines drawn on top of each other with different thickness don't align properly if I use any other JointStyle than MITER. For pictures of the effect, and for the graphics oriented part of the question, see my post over on doctype.
However, there's also a second angle on this problem, which is: why should drawing the "mitered" joints be so much slower than others? This seems to be a problem since at least FP 8, but I couldn't find any detailed info on what the problem might be. Is this just an ordinary bug that didn't get fixed yet, or is there something inherently slower about drawing these joints? For example, they seem to have something to do with square roots, but I seriously lack understanding of what this joint style thing is all about, technically. It just looks like some minor detail a graphic designer might worry about.
I'm asking because I'm wondering if I can do something to mitergate, er, mitigate, the problem.
There are various ways to join two lines:
none: free
round: draw a circle of radius line width/2
cap: fill in the gap between the lines
miter: extrapolate the lines and fill that
Miter is the most expensive. If the lines are meeting at an outer angle that is greater than 90, they need to be extrapolated, intersected and filled.
From the screenshots at your linked post you shouldn't need any joints for drawing a graph. Joints are only important with large stroke widths and for drawing a graph, round or cap joints should be perfectly fine.
In flash rendering miters is quite fast - it's just the most complicated join to pick.