I'm displaying many overlapping icons in a Google Earth tour. I'd like to control (or at least understand) the order in which the icons are drawn (which one shows on "top"). Thanks!
PS. Non solutions attempted: Using gx:drawOrder (it applies to overlays, but not icons). Using AnimatedUpdate to establish the order chronologically. Using the order in which you introduce the placemarks to establish their drawing order.
Apparently Google Earth draws the features in groups by type: polygons, then ground overlays, followed by lines and point data where drawOrder is applied only within a group. ScreenOverlays are drawn last so they are always on top.
If you define gx:drawOrder or drawOrder on a collection of features, it only applies to the features of the same type (polygon and other polygons) not between different types.
That is the behavior if the features are clamped to ground. If features are at different altitudes then lower altitude layers are drawn first.
Note that the tilt angle affects the size of the icon and as the tilt approaches 90 degrees, the size of the icon gets smaller. The icon is at largest size when viewed straight-down with 0 degree tilt angle.
Related
Glyphs in typefaces for screens often use hinting to align the shapes with the screen pixels so the result has sharp edges. Could I do something similar with arbitrary vector graphics on a webpage?
I know that I can align lines with pixels in a vector graphic, but that works at only the default size and its integer multiples. My idea is that the graphic would have hinting similar to what is used in typefaces to have sharp edges at all sizes.
This could be used for icons, text decorations or list item markers and for prerendered math formulae. In the case of a formula, the hinting would be automatically derived from the hinting of glyphs in the typeface used to render the formula.
SVG supports two CSS properties for pixel alignment optimization:
shape-rendering handles edges of grafic primitives and the anti-aliasing applied.
text-rendering handles the positioning of glyphs and the way font-internal rendering hints are applied.
Both are presentation attributes that can be used either in CSS styles or as XML attributes.
Both act under the caveat that the values of the properties are treated as hints, with the browser free to interpret them the optimal way.
There is not one solution that will work out in every situation. A prominent case is text rendered at an angle to a horizontal line, or text along a curved path. If you choose to optimizeLegibility, the individual glyphs will often be slightly rotated and moved away from their precise position and may not remain in a straight line. If you choose geometricPrecision, especially small fonts may suffer from degrading legibility.
For grafic primitives, the most pronounced effects show up for narrow (curved) strokes and for multiple grafical primitives that have a common edge (think two rectangles next to each other). There, hinting (to turn antialiasing on - geometricPrecision or off - crispEdges) may help in some situations, but in others you still have to resort to wider strokes or overlapping areas.
Another fallback technique may include restricting the scaling of a grafic to only some multiples or fractions of integers, so that you still have control over pixel alignment.
I am trying my hand at writing a 3d graphics engine, but I am having some trouble with drawing the shapes in the correct order.
When I translate the points of triangles into window space, i.e. the 2-dimensional space that directly correlates to position on the screen, in addition to an x and y position of each point, I also assign them a depth variable that stores how far away from the viewer that point was in 3d space.
At the moment, the only shapes I am rendering are triangles. My current render order algorithm sorts the triangles by the average depth of their 3 points. I knew when I started it that it would not be perfect, but I wanted a placeholder for testing.
For testing purposes, I constructed a square box with an open top, each side being a different color and made from 2 triangles, as shown below:
As you can see from the image above, the algorithm I am using works most of the time. However, at certain angles and positions, the triangles will be rendered in the wrong order, as show below:
As you can see, one of the cyan triangles on the bottom of the box is being drawn before one of the yellow triangles on the side. Clearly, sorting the triangles by the average depth of their points is not satisfactory.
Is there a better method of ordering shapes so that they are rendered in the correct order?
The standard method to draw 3D in correct depth order is to use a Z-buffer.
Basically, the idea is that for each pixel you set in the color buffer, you also set it's interpolated depth in the z (depth..) buffer. Whenever you're about to paint the next pixel, you first check that z-buffer to validate the new pixel if in front of the already painted pixel.
On top of that you can add various sorts of optimizations, such as sorting triangles in order to minimize the number of times you actually paint the color buffer.
On the other hand, it's sometimes required to do the exact opposite in order to properly handle transparency or other "advanced" effects.
I am trying to create an application similar in UI to Sketchup. As a first step, I need to display the ground surface stretching out in all directions. What is the best way to do this?
Options:
Create a sufficiently large regular polygon stretching out in all directions from the origin. Here there is a possibility of the user hitting the edges and falling off the surface of the earth.
Model the surface of the earth as a sphere/spheroid. Here I will be limiting my vertex co-ordinates to very large values prone to rounding off errors. (Radius of earth is 6371000000 millimeter).
Same as 1 but dynamically extend the ends of the earth as the user gets close to them.
What is the usual practice?
I guess you would do neither of these, but instead use a virtual ground.
So you just find out, what portion of the ground is visible in the viewport and then create a plane large enough to fill that. With some reasonable maxiumum, which simulates the end of the line of sight aka horizon as we know it.
There is polygon inside a bigger polygon in Google Earth. Smaller polygon also has descriptive balloon, that shows info when i click on it.. But, if I add balloon to bigger polygon, the smaller polygon just isn't accessible, i.e, no balloon shows up in there??
Is there a way to set the zoom scaling to fix that a smaller polygon is visible afterward this scale. And when clicked, the smaller polygon's balloon is showed. Any references to kick start this approach?
Is is possible alone in Google earth?
Yes, you can achieve this by nesting Kml regions. Basically you would wrap each polygon in a region. Each region would have a set of LOD (Level of detail) limit to specify the required size (zoom/range) for the associated Region to be active. This way the large polygon would be visible and active at a certain distance, then at a closer distance, the smaller polygon would be visible and active.
This is possible to do directly in Google Earth by manipulating/creating the Kml as desired. Alliteratively you could write the kml in any text editor and simply load it into the application.
For more information see - Nesting Regions
http://code.google.com/apis/kml/documentation/regions.html#nestingregions
My graphics are looking blurry unless I add or subtract a half pixel to the Y coordinate.
I know this is a symptom that usually happens when the coordinates are set to sub-pixel values. Which leads me to believe one of my views must be off or something.
But I inspected the window, view controller and subviews, and I don't see any origins or centers with sub-pixel values.
I am stumped, any ideas?
See if somewhere you are using the center property of a view. If you assign that to other subviews, depending on their sizes they may position themselves in half pixel values.
Also, if you are using code to generate the UI I would suggest using https://github.com/domesticcatsoftware/DCIntrospect. This tools allows you in the simulator to look at all the geometry of visible widgets. Half pixel views are highlighted in red vs blue for integer coordinates. It helps a lot.