I try to draw a field of circles. The density of the circles (ratio area circle to interstitial space) should increase continuously (gradient). Has anyone an idea how to do that, maybe using other programs scripts etc. The result should look like the picture, just with continuous changing space between circles.
If creating a *.scr file is not a problem, make it like this
CIRCLE
0,0
20
0,100
0,200
100,300
That is - after each coordinate make 2 blank lines (first line is for diameter, second to execute command "circle" again)
It would be the same if you were writing
CIRCLE
0,0
20
CIRCLE
0,100
20
CIRCLE
0,200
20
CIRCLE
100,300
20
Related
I have a scene where the user can rotate an object around the surface of the sphere, keeping its local Z axis normal to the surface. Heres a JS fiddle, with sliders at the top to rotate around the sphere.
https://jsfiddle.net/dftroy58/14/
This works fine, but now I want to be able to apply a heading to the object, essentially rotating it along its Z axis. At 0 degree heading, the Y axis should point up towards the north pole of the sphere.
I tried to set therotation.z of the object which works when the latitude is 0 degrees, but moving around the sphere, it then rotates where X becomes up at 90 degrees, -Y at 180 and -X at 270.
marker.rotation.z = THREE.Math.degToRad(Number.parseFloat(heading.value, 10));
With that line commented out, the Y axis always points up. How do I get it so I can set the local Z rotation such that it points to the north pole at 0 degrees, but is rotatable by the user?
I could solve this by instead of rotating the marker, change it to axesHelper.rotation.z. This ends up working, but I'd like to remove the axes helper and want to just understand these kind of transformations more.
// Works but I want to avoid this
axesHelper.rotation.z = THREE.Math.degToRad(Number.parseFloat(heading.value, 10));
How would I, without nesting another object, calculate the correct the Z rotation to keep the heading the same as you change latitude?
I am working on a multi-line animated chart based on [Edit: not Bostock's] example:
http://bl.ocks.org/atmccann/8966400
I want the lines to appear synchronized by the date value on the x axis. If I slow down the graph (say to duration=15000) I can clearly see that in the very early part of the graph the green line is ahead of the black line. Then the black line moves ahead of the green line. Both start and end together.
The issue is accentuated in my chart where I am plotting 20 lines. Some are clearly ahead of the others when plotting. Lines with initial y values of zero shoot way ahead of those that climb to higher y values at the start.
How can I adjust the display so both lines paint for the same date at the same time?
The technique in the bl.ocks.org example (which, btw, is not Bostock's) is animating based on the length of the line, not it's position on the y-axis. If you want to animate based on the y-axis position, you'll have to use a different technique. Especially with 20 lines, I wouldn't recommend trying to dynamically update each line if they have a lot of points. You could do that if there aren't many points, though.
A simple approach would be to add a solid (white) rectangle to the chart that covers all the graph lines. Then animate the left position and width of that rectangle to reveal the lines over time.
I would like to create a vector object that can be drawn with a pen tablet and will honor the pressure information from the pen (by increasing/decreasing line width appropriately). Now I know how to get the pressure info out of the NSEvent, but of course NSBezierPath doesn't support varying line widths.
So I'm trying to generate a Bezier path that is the outline of my line, by calculating the perpendicular lines at the ends of the curve and connecting those with the very same curve. It nearly works in my little test project for a single curve segment:
https://github.com/uliwitness/WideningBezierPathTest
but this has one big issue: The line thins to barely 2 pixels in the middle (it should only go from 32 to 8). Does anyone know how I'd adjust the control points so the two edges of the line in the curved part are at roughly the same distance ?
Anyone have ideas? Suggestions? Useful articles?
Thanks to suggestions from others I've managed to cobble something together that works. I've committed the changes to the repository, but you can go back a few revisions if you want to see the older code. Here's what I do now:
I flatten the path using bezierPathByFlatteningPath. This gives me straight line segments.
I then calculate the start and end points of the perpendicular lines at the start and end of each line segment (these lines are as long as the line size should be at this point).
I create a bezier path containing a parallelogram consisting of the two perpendicular lines plus lines connecting them. This gives a smooth transition in line widths for each segment.
Once I have the segments, I draw the ending perpendicular lines of the path, plus the sides of each segment (but not the perpendicular lines between segments) into a new bezier path, which I can then fill to draw the stroke with the desired line width variations.
If you want to use this for printing or under HiDPI, you might have to muck with the "flatness" of the bezier path, but for 1x screen display it looks fine.
I've a tube geometry with 174 points, 12 radius segment, 100 radius and 174 segments.
When I double click at any part of a tube, the scaled portion of a tube with +/- 8 points will be displayed.
Now the issue is when I click at bending part of a tube, the scaled portion does not look as good as I click on a straight part of a tube.
Please find below the 2 images.
Please find jsfiddle here.
Please find below the code of scaling.
tube = new THREE.TubeGeometry(extrudePath, segments, 100, radiusSegments, closed, debug);
tube.dynamic = true;
tube.computeBoundingBox();
console.log(tube);
tube.scale.x = tube.boundingBox.max.x;
tube.scale.z = tube.boundingBox.max.z;
Is there anyway to scale it properly or transform that bending portion into cylinder so that it looks like the straight portion of a tube ?
I think the scaling you are doing is improper. Since the section you are trying to scale may not have its axis along the y axis, scaling the x and z parameters only will result in distortion. Is it possible to know the axis of the section? Then there are 2 ways -
1) Rotate the section so the axis is aligned with y axis, scale x and z coordinates and rotate the section back.
2) Come up with a formula to scale a cylinder with axis in arbitrary direction.
Since this is a very old question you probably have the answer already. Please let me know if I am wrong and what worked for you.
I'm developing a custom control. One of the requirements is to draw lines. Although this works, I noticed that my 1 pixel wide lines do not really look like 1 pixel wide lines - I know, they're not really pixels but you know what I mean. They look more like two or three pixels wide. This becomes very apparent when I draw a dashed line with a 1 pixel dash and a 2 pixel gap. The 1 pixel dashes actually look like tiny lines in stead of dots.
I've read the Cocoa Drawing documentation and although Apple mentions the setLineWidth method, changing the line width to values smaller than 1.0 will only make the line look more vague and not thinner.
So, I suspect there's something else influencing the way my lines look.
Any ideas?
Bezier paths are drawn centered on their path, so if you draw a 1 pixel wide path along the X-coordinate, the line actually draws along Y-coordinates { -0.5, 0.5 } The solution is usually to offset the coordinate by 0.5 so that the line is not drawn in the sub pixel boundaries. You should be able to shift your bounding box by 0.5 to get sharper drawing behavior.
Francis McGrew already gave the right answer, but since I did a presentation on this once, I thought I'd add some pictures.
The problem here is that coordinates in Quartz lie at the intersections between pixels. This is fine when filling a rectangle, because every pixel that lies inside the coordinates gets filled. But lines are technically (mathematically!) invisible. To draw them, Quartz has to actually draw a rectangle with the given line width. This rectangle is centered over the coordinates:
So when you ask Quartz to stroke a rectangle with integral coordinates, it has the problem that it can only draw whole pixels. But here you see that we have half pixels. So what it does is it averages the color. For a 50% black (the line color) and 50% white (the background) line, it simply draws each pixel in grey:
This is where your washed-out drawings come from. The fix is now obvious: Don't draw between pixels, and you achieve that by moving your points by half a pixel, so your coordinate is centered over the desired pixel:
Now of course just offsetting may not be what you wanted. Because if you compare the filled variant to the stroked one, the stroke is one pixel larger towards the lower right. If you're e.g. clipping to the rectangle, this will cut off the lower right:
Since people usually expect the rectangle to stroke inside the specified rectangle, what you usually do is that you offset by 0.5 towards the center, so the lower right effectively moves up one pixel. Alternately, many drawing apps offset by 0.5 away from the center, to avoid overlap between the border and the fill (which can look odd when you're drawing with transparency).
Note that this only holds true for 1x screens. 2x Retina screens actually exhibit this problem differently, because each of the pixels below is actually drawn by 4 Retina pixels, which means they can actually draw the half-pixels. However, you still have the same problem if you want a sharp 0.5pt line. Also, since Apple may in the future introduce other Retina screens where e.g. every pixel is made up of 9 Retina pixels (3x), or whatever, you should really not rely on this. Instead, there are now API calls to convert rectangles to "backing aligned", which does this for you, no matter whether you're running 1x, 2x, or a fictitious 3x.
PS - Since I went to the hassle of writing this all up, I've put this up on my web site: http://orangejuiceliberationfront.com/are-your-rectangles-blurry-pale-and-have-rounded-corners/ where I'll update and revise this description and add more images.
The answer is (buried) in the Apple Docs:
"To avoid antialiasing when you draw a one-point-wide horizontal or vertical line, if the line is an odd number of pixels in width, you must offset the position by 0.5 points to either side of a whole-numbered position"
Hidden in Drawing and Printing Guide for iOS: iOS Drawing Concepts, though nothing that specific to be found in the current, standard (OS X) Cocoa Drawing Guide..
As for the effects of invoking setDefaultLineWidth: the docs also state that:
"A width of 0 is interpreted as the thinnest line that can be rendered on a particular device. The actual rendered line width may vary from the specified width by as much as 2 device pixels, depending on the position of the line with respect to the pixel grid and the current anti-aliasing settings. The width of the line may also be affected by scaling factors specified in the current transformation matrix of the active graphics context."
I found some info suggesting that this is caused by anti aliasing. Turning anti aliasing off temporarily is easy:
[[NSGraphicsContext currentContext] setShouldAntialias: NO];
This gives a crisp, 1 pixel line. After drawing just switch it on again.
I tried the solution suggested by Francis McGrew by offsetting the x coordinate with 0.5, however that did not make any difference to the appearance of my line.
EDIT:
To be more specific, I changed x and y coordinates individually and together with an offset of 0.5.
EDIT 2:
I must have done something wrong, as changing the coordinates with an offset of 0.5 actually does work. The end result is better than the one obtained by switching off the anti aliasing so I'll make Francis MsGrew's answer the accepted answer.