I am overlaying a transparent image on my VEMap control by rendering it as a single VEShape. The shape changes sizes dynamically depeding on the zoom level of my map and can be as large as 4000*4000px. In older browsers such as IE6 and early versions of Firefox 2.x, map control performance degrades rapidly when my shape gets larger than 1500*1500px. The mouse pointer moves slowly and the map responds very slowly to events. I don't see this issue at all in newer browsers (IE7+).
Are there any workarounds to boost performance of rendering a large shape for IE6 users?
The solution you're probably looking for is to actually use "Map Cruncher" to create map tile images from your image. Then these map tile images can be overlaid on the VEMap using a Custom Tile Layer, and will be rendered exactly the same way as the Map Images themselves.
http://www.microsoft.com/maps/product/mapcruncher.aspx
Related
I have a building model with 6K faces and I want to texture with some pretty high detail 512x512 tilable textures (which represent about 32cm x 32cm), and I'd like to be as mobile-friendly as possible, but not necessarily with old phones but for like GearVR capable phones.
The model happens to have mostly long horizontal quads eg
|-----------|---|----------------|
|-----------|---|----------------|
|-----------| |----------------|
|-----------| |----------------|
|-----------|---|----------------|
|-----------|---|----------------|
So the uv's of each of those horizontal sections can be stacked on one tileable texture, to achieve both horizontal and vertical tiling.
Further, if the tiles were 512x512 textures, I could stack 8 of them in a 512x4096 non-square (but power of two) texture.
That way I could texture the main mesh with a single texture or one extra for metalic.
Is this reasonable, or should I keep them as separate 512x512 textures? Wouldn't separate textures mean like 8x the draw calls which would be far worse than a non-square 512x4096 texture?
After some research, I found the technique of stacking textures and tiling horizontally is called using a trim sheet, and is very much valid, and used extensively game development to be able to re-use high-detail textures on many different objects.
https://www.youtube.com/watch?v=IziIY674NAw
The trim sheet info I found though did not cover 'non square' which is the main question. But from several sources I found that some devices do not support non-quare and some do, and some do but don't do compression well on non-square, so it's a 'check your target devices' issue.
Assuming a device does support non-square, it should in fact save memory to have a strip of textures, and should save draw calls, but your engine may just 'repeat them horizontally until square' for you when importing the texture to 'be safe' (so again, check target devices and engines). It would perhaps be wise to limit to 4 rather than 16 stacked textures, to avoid 'worst case scenarios'.
Hopefully, the issue will be addressed by either having video cards able to do several materials in 1 draw call, or by more universal handling the texture strips well, but it seems state of the art has not focused on that yet.
Another solution is more custom, but some people have created custom shaders that use vertex color information on a mesh to choose which part of a texture to use, and then tile from there. Apparently the overhead turned out to be quite low, and it was a success, so it's good to have an idea about 'backup plans'. This however would be an engine/environment/device specific kind of optimization, not a general modeling practice.
http://www.gamasutra.com/blogs/MarkHogan/20140721/221458/Unity_Optimizing_For_Mobile_Using_SubTile_Meshes.php
I'm using Leaflet + CartoDB; I've also used Leaflet + Mapbox; and there may also be some Leaflet + GoogleMaps in my future.
My customer asked me this question: where do the Leaflet layers get painted onto the tiles? Is that done by Leaflet? Or by the Tile engine?
Does this change if I'm using a "regular" map engine (such as Mapbox) or if I'm using something like the KML-rendering plugin?
where do the Leaflet layers get painted onto the tiles? Is that done by Leaflet?
By default (unless you're doing something weird), that happens in your web browser, which is compositing DOM elements on top of each other. You can check this by using the developer tools in your browser and inspecting the DOM elements for the tiles, and the <canvas> or <svg> with your vector geometries. They are separate DOM elements, thus your browser is doing the compositing.
Does this change if I'm using a "regular" map engine (such as Mapbox) or if I'm using something like the KML-rendering plugin?
Not really. Mapbox-gl-js uses insane amounts of WebGL, so that means that the brunt of the workload moves from the browser's compositor to a WebGL stack. It still happens in the web browser, albeit in a different part of the browser.
There is no "KML rendering plugin" for leaflet, just KML loading plugins. Vector geometries are still rendered in a <canvas> or <svg> separate from the image tiles for the basemap, then composited.
You can, of course, run your own tile server (with software such as Geoserver, Mapserver, Mapproxy, mapnik+mod_tile, tirex, tilestream, or dozens of others). In that case, you obviously know you are rasterizing your data into tiles.
When I zoom in far enough on my map, the TileLayer disappears and I see a bunch of tiles that say "Map data not yet available". I believe these tiles may be coming from the provider, but I am not sure (I am using ESRI WorldImagery dataset).
Is there any way to, at a certain zoom level, just force the tiles to stretch, instead of requesting the tiles for that zoom level? I am ok with some blur, but I do need to zoom in further.
I tried playing around with the zoomOffset option, but whenever I put something there other than 0, my tiles just never load (all grey).
Thanks!
This can be solved by using two of the options of L.TileLayer.
First, set maxNativeZoom to the highest zoom level your tiles provide (the last zoom level before the "Map data not available" starts to appear - this tells Leaflet to stop requesting new tiles when zooming in beyond this level; stretched tiles will be used instead.
Second, set maxZoom to whatever zoom is appropriate; you might not want this to be more than a couple of levels higher than maxNativeZoom, since the stretched tiles will start to look pretty horrible.
You can find out more about the details by checking under "Options" in the documentation for L.TileLayer: http://leafletjs.com/reference.html#tilelayer
I'm just getting things going in my game and I'm using CCTMXLayer for my tiled background. Everything is going fine when my map is 30x30 tiles, but my world is about 500x500 tiles. I would just use a map that size, but it lags terribly during animation. Any ideas as to handle a really large, tiled map without having lag?
Being biased here: check out Koboldtouch, specifically what features I added to make tilemaps more useful. Among them no limits on map size, tilesets, layers - as much as can fit in memory.
The only alternative is HKTMXTiledMap. I never actually used it, the forum thread is full of (unresolved?) issues.
The CCTMXTiledMap is not only slow, you can only create 128x128 tiles tilemap with a single layer and all tiles set to non-empty. 500x500 is only possible if you leave enough empty tiles so you never go above 16,384 tiles on the map. Unlikely. Restrictive.
I am working on a 2D scrolling game for iPhone. I have a large image background, say 480×6000 pixels, of only a part is visible (exactly one screen’s worth, 480×320 pixels). What is the best way to get such a background on the screen?
Currently I have the background split into several textures (to get around the maximum texture size limit) and draw the whole background in each frame as a textured triangle strip. The scrolling is done by translating the modelview matrix. The scissor box is set to the window size, 480×320 pixels. This is not meant to be fast, I just wanted a working code before I get to optimizing.
I thought that maybe the OpenGL implementation would be smart enough to discard the invisible portion of the background, but according to some measuring code I wrote it looks like background takes 7 ms to draw on average and 84 ms at maximum. (This is measured in the simulator.) This is about a half of the whole render loop, ie. quite slow for me.
Drawing the background should be as easy as copying some 480×320 pixels from one part of the VRAM to another, or, in other words, blazing fast. What is the best way to get closer to such performance?
That's the fast way of doing it. Things you can do to improve performance:
Try different texture-formats. Presumably the SDK docs have details on the preferred format, and presumably smaller is better.
Cull out entirely offscreen tiles yourself
Split the image into smaller textures
I'm assuming you're drawing at a 1:1 zoom-level; is that the case?
Edit: Oops. Having read your question more carefully, I have to offer another piece of advice: Timings made on the simulator are worthless.
The quick solution:
Create a geometry matrix of tiles (quads preferably) so that there is at least one row/column of off-screen tiles on all sides of the viewable area.
Map textures to all those tiles.
As soon as one tile is outside the viewable area you can release this texture and bind a new one.
Move the tiles using a modulo of the tile width and tile height as position (so that the tile will reposition itself at its starting pos when it have moved exactly one tile in length). Also remember to remap the textures during that operation. This allows you to have a very small grid/very little texture memory loaded at any given time. Which I guess is especially important in GL ES.
If you have memory to spare and are still plagued with slow load speed (although you shouldn't for that amount of textures). You could build a texture streaming engine that preloads textures into faster memory (whatever that may be on your target device) when you reach a new area. Mapping as textures will in that case go from that faster memory when needed. Just be sure that you are able to preload it without using up all memory and remember to release it dynamically when not needed.
Here is a link to a GL (not ES) tile engine. I haven't used it myself so I cannot vouch for its functionality but it might be able to help you: http://www.mesa3d.org/brianp/TR.html