for an interactive project I have created a Cesium viewer instance with two TileMapServiceImageryProvider intances which get their content from a fast local ssd.
Howerver, the display performance when zooming in or out is not very smooth.
It sometimes takes more then a second to display the new content.
I already turned the requestRenderMode on to increase performance of the whole project but I could ot find any way to speed up tile loading / rendering.
Is there a way to optimize Cesiums tile-handling? Is caching an issue maybe?
Thanks so much.
You could increase tileCaheSize value
viewer.scene.globe.tileCacheSize = 1000; // default 100
Also increasing value of maximumScreenSpaceError could help (but with increasing value image tile quality is decreased)
viewer.scene.globe.maximumScreenSpaceError = 5;
Related
I am trying to add a pixel buffer around a WMS query in MapServer. I noticed in MapServer/mapwms.cpp there is an option to set 'tiled=true' which should check for "tile_map_edge_buffer" "100" value in the map config file. However, when I check the spatial query, it doesn't seem to extend at all. Even altering SQL query to include extra data using ST_Expand(!BOX!, 0.01) doesn't help - the query does return extra data but it is not drawn.
I need this as I am generating point data through WMS EPSG:4326. The point data is displayed as large squares (changes with zoom level) but the data from the next tile near the border don't get generated in the tile of interest.
For example if the point on the main tile (lets say 100x100) is on (50,1), square size 20 pixels, the main tile generates a rectangle approx: (40,1 40,11 60,11 60,1) (20x10) which is correct. If I try to generate left side tile, I would expect to see the remainder of the square but I don't.
Anyway, if anyone had luck setting up pixel buffer for WMS, I would appreciate their input.
We recently updated one of our projects to use the latest version of the Autodesk Forge Viewer (v7.x).
In general, the migration went fine, however we noticed that for some models we have issues with the far cutting planes of the camera. I have figured out that this happens because the model contains some elements that are very far from the rest of the model and thus the bounding box of the entire model is magnitudes larger than it should be. This results in camera near = 1 and far = 10000. It seems that far should be higher in order to not hide parts of the model when zooming out.
For now, we have been able to workaround the issue be specifying a the "nearRadius" when loading the model, but since we have to set it to a value like 50 or 100 in order to not have far plane issues, we still have some near plane clipping issues.
I was wondering if there is any possibility to fix the model once it is loaded, so that the viewer uses a more realistic bounding box for the model. I have found out so far that during the load it already sets the variable verylargebbox to true and therefore is not using the nearRadius = 0 but either the passed value in the load options or 1. I was able to set nearRadius to a negative value to have the same behaviour as with nearRadius = 0, but due to the large bounding box of the model, we still experience clipping issues.
In order to fix the model I have already tried:
Excluding the ids of the elements that are far away with ids = [...] in the load options
Setting the visibility of these elements to off using setNodeOff()
Use NOP_VIEWER.navigation.fitBounds() to set the bounding box (as suggested in near and far calculation in Autodesk Forge Viewer)
However, getVisibleBounds() still returns the huge bounding box.
We would like to find a solution in which we don't need to modify the source model file before translating it to .svf.
The engineering team has confirmed that there are pathological cases where due to the bounding box of the model being extremely large, the computation of the near/far camera planes causes clipping artifacts. While this is being addressed, the suggested workaround is to set the near plane to 1:
viewer.impl.setNearRadius(1);
I wrote a tool which draws model curves on a view and adds dimensions to it. The tool when run locally on my computer it works fine, lines are drawn and dimension are added and visible.
But, when I upload the code to Forge Design Automation, the lines are drawn and dimensions added. However the dimensions are not visible. After I downloaded the rvt file I can see the dimension through Revit Lookup, but not directly on the view.
Any suggestions where I might be going wrong?
Here is my code...
mCurve.LineStyle = buildingLineStyle;
//Adding dimension
ReferenceArray references = new ReferenceArray();
references.Append(mCurve.GeometryCurve.GetEndPointReference(0));
references.Append(mCurve.GeometryCurve.GetEndPointReference(1));
Dimension dim = doc.Create.NewDimension(groundFloor, line, references);
//Moving dimension to a suitable position
ElementTransformUtils.MoveElement(doc, dim.Id, 2 * XYZ.BasisY);
Thanks for your time in looking into this issue.
Thank you for your query and sorry to hear you are encountering this obscure problem.
I have no complete and guaranteed solution for you, but similar issues have been discussed in the past in the pure desktop Revit API, and two workarounds were suggested that might help in your case as well:
Newly created dimensioning not displayed
Dimension leader remains visible after removal
One workaround consists in creating a new dimension using the Reference objects obtained from the non-visible one.
The other one, in moving the dimension up and down within the same transaction to regenerate it.
I'm building a simple eBook for tablets in Flash Pro. All the pages are images (Bitmaps in library) and there's about 80 of them. To maintain good quality for large tablets, bitmaps are quite big (3999x2999).
This eBook has vertical and horizontal scrolling and these are working fine, but; due to huge amount and size of these images, I can't add all of them to stage when app starts, so I ended up adding only the closest pages to current page always after scrolling tween.
This works ok, but causes always a delay after page scroll (even several seconds with older tablet, and with new iMac it's almost 1s, so it's notable). This is basicly what I do per image/page:
var bitmapdata:BitmapData = new bitmapArray[i](); //linkage name
var hRatio:Number = stage.stageHeight / bitmapdata.height;
var bitmap:Bitmap = BitmapScaled(bitmapdata, bitmapdata.width * hRatio, bitmapData.height * hRatio);
target.addChild(bitmap); //target is a MovieClip (I have one Mc for each vertical pile of pages)
And BitmapScaled function:
function BitmapScaled(source0:BitmapData, width0:Number, height0:Number):Bitmap{
var mat:Matrix = new Matrix();
mat.scale(width0/source0.width, height0/source0.height);
var bmpd_draw:BitmapData = new BitmapData(width0,height0,false);
bmpd_draw.drawWithQuality(source0,mat,null,null,null,true,StageQuality.BEST);
return new Bitmap(bmpd_draw);
}
Also, after scrolling I clean up the ones that aren't next to new current page:
function clear(targetArray:Array):void{
for(var i:int = 0; i<targetArray.length; i++){
targetArray[i].bitmapData.dispose();
targetArray[i].bitmapData = null;
targetArray[i].parent.removeChild(targetArray[i]);
targetArray[i] = null;
}
if(targetArrays[targetArrays.indexOf(targetArray)] = new Array();
}
How often:
After horizontal scroll I add one new horizontal page and one new vertical page, and remove one horizontal and at least one vertical page.
After vertical scroll I add only one new vertical page (if next vertical page is one that I already haven't added), so vertical pages I keep in stage untill next horizontal scroll happens. This takes a smaller delay, but also notable.
I know Flash/AIR is not the best way for this, but it's all I have now. How could I get rid of the addChild-delay? Yeah you can't, so any better ways to do all this?
I'm pretty sure I'm using the hard way with something here, but just can't figure out what and how I should do it.
BitmapData drawing on mobile device is too slow to be used on the fly, if you must use it do your drawing on app start (still slow though). BitmapData blitting is a little bit faster but still too slow to be used on mobile device.
With large amount of assets like in your case, Stage3D frameworks like Starling might not be the best solution either as texture uploading is also slow and limited in memory amount (when limit is reached the app crashes).
Best might just be to copy what typical Android/Ios development use: Few different resolutions for all assets with a minimum of 1x and 2x.
I personally use 0.5x, 1x, 2x, 3x and developed a framework that switches resolution according to different settings (very much like XCode does). But still you can keep things simple without a framework and just set at app start the asset resolution you'll use for the app. I would also make sure to remove and add those assets on screen as they are needed.
don't use that "new BitmapData" in conjunction with the "dispose". when you load your bytes load it directly into the already existing bitmaps on the stage. try to have as little modification of the allocated memory as possible through your load-resize-display pipe.
removing and dumping pixels onto the renderer is far slower than changing already existing ones.
I am making a game in Libgdx, in which I want to show and hide a texture for specific interval of time and repeat this process. can I use Timer class for this.
Please give me some example also.
I'm not sure what your trying to do here. You could just have a flag in your rendering loop
Texture texture;
long lastFlip = 0;
long flipTime = 1000;
boolean display = false;
//..In your rendering loop
if(lastFlip+flipTime > System.currentTimeMillis()){
display = !display;
lastFlip = System.currentTimeMillis();
}
if(display){
spriteBatch.draw(texture,0,0);
}
If you want to use the inbuilt actions system in scene2d have a at the following tutorial. Tutorial. The blog is very good and gives you a good idea of how to use a lot of scene2d features. It might be a little bit out of data beacuse of the changes to scene2d but it will give you the idea you need.
I am sure you got the solution now but instead of using System specific time you should use the Gdx graphics delta time which you already have in the render method. Then compare it with the amount of time for which you want to show the textures.
You should definitely use libGDX wrapper function to read time to avoid eventual incompatibility on different platforms. But code it self can be really simple:
if (TimeUtils.millis()%(SHOW_TIME+HIDE_TIME) < SHOW_TIME){
// render it
}
Where SHOW_TIME is number of milliseconds you want your texture displayed and HIDE_TIME is number of milliseconds you want it hidden. No need for extra variables and making it more complicated than this.