We upgraded from OL5.3 to OL6.1.1 recently and I noticed that OL handles the zoom level somehow differently.
Previously, the zoom level would always be a whole number, even after rotating the map or using the "zoom to layer" function; right after the interaction, OL would always round the zoom level down to the next lower whole number.
Based on the release notes for 6.0.0, I suspect it has something to do with constrainResolution. Can someone give me a hint? How can we restore the previous behaviour?
Related
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);
As for the current version, I have not found a proper way to detect the zoom start (without overriding the animation function). In my case both movestart and moveend events does not solve the problem.
The actual need for the zoom start is the TileWMS layer. I need to set it to invisible on certain zoom levels. This cannot be set on move end, because at move end the layer still loads tiles from geoserver although set to invisible. Enable / disable property is also not available on the layer itself.
Setting the layer invisible on movestart solves the problem with fetching but on drag already loaded the tiles are not visible :) this is annoying for the user experience.
Is there any other idea how to solve this?
Thanks
Using Surface pro touch screen to select element in viewer works sometimes other times it seems to translate to a rotate/zoom action. In this case the viewer rotates/moves and the element is NOT selected.
When logging the events there are plenty of mouse down/up events along with mouse moves when it doesnt work. When select does work a single click event occurs.
Double click seems to work ok.
Zoom/rotate etc using standard tools works ok.
Using the keyboard cover touch pad that you can get for the Surface pro to move and click works as expected and the element is selected.
Running same application on a GETAC Windows 10 ruggadised tablet the select element works correctly so it seems related to the Surface Pro.
Unable to change browsers as cordova apps use IE11 on windows and that is currently fixed.
The only solution i can think of for the moment is to remove the standard navigation tools completely (somehow) and recreate a select mode tool that would ignore any mouse moves and use button down event to select element.
Any suggestions on how to fix this?
Tech Details:
Windows 10 Pro,
Surface Pro,
Browser: IE11,
Viewer version 2.11,
Other: WINJS81 cordova application
Thanks for any help
We've had problems with touch events on the Surface Pro in the past. It sounds like the edges of the touch screen are overly sensitive and are triggering extra touch points.
Does the problem happen if you are holding the device up, gripping with one hand, and using your other hand to touch/select a 3D object ?
Could you try doing a selection again, but this time, make sure you other hand is not holding the edge of the screen? (Perhaps place the device on the surface of a desk, so you are not holding it up)
Found a fix to this issue. In viewer3D in the base toolcontroller there is line
var kClickThreshold = 2;
This value is used further down in code to determine if singleClick has occured. It does it by comparing XY on down and up events.
var deltaX = _downX - event.canvasX;
var deltaY = _downY - event.canvasY;
_downX = -1;
_downY = -1;
if( Math.abs(deltaX) <= kClickThreshold && Math.abs(deltaY) <= kClickThreshold )
_this.handleSingleClick( event );
If movement is above this threshold it does not trigger singleClick if below it does.
Did testing and increasing the value to around 5-7 means that the selection of elements worked consistently. (there is still a minor rotate or zoom at same time as select occurs but I assume that this would be another part of viewer that would need adjusting)
Unfortunately it does require edit of viewer code but easy enough. I added code to overwrite standard value if external variable existed.
Would be nice for future viewer dev if more of these types of properties be exposed so that direct edit of code is not required.
Still it is good to have the source code to be able to debug at this level.
At a guess the Surface Pro 4 must have a more sensitive touch system or it could just be related to IE11 as well.
I'm only using one scene object for my entire 2d sidescrolling platformer with two layers: There is a hudLayer for the controller, and the gameLayer for everything in the game.
When I control my character to walk into a door (sprite with a physicsBody that has a callback that takes me to the next level), the next level loads by these instructions:
remove all event listeners
stop all actions for both layers (the gameLayer typically has been doing a Follow action that follows the player, and is limited to the size of the backgroundSpriteNode)
remove all children from the gameLayer
set gameLayer position to Vec2(0,0)
load level 2 (a complete copy of what level 1 should look like... load the background sprite to gameLayer, playerSprite, add event listeners)
add event listeners back to the hudLayer
The only problem is that for whatever reason, the level only partially loads the way it should... For instance, coins appear in the spots they should, but platforms don't seem to. Neither that or the player, or other characters. Not sure really why these objects are specifically not loading in the correct positions, but maybe someone who has experienced this sort of problem before can help?
Most nodes (such as platforms) are appearing below the bottom of the screen when they should be fully shown at the bottom of the screen. Characters are appearing down there too when they should be appearing above the platforms.
P.S. After testing a bit more, I've come to realize that SOMETIMES some of the platforms are loading in the correct positions, but sometimes they aren't. Not sure why. A fix for this may be to load things one at a time with a delay between them. But I'd rather not have to put delays and just figure out what the deal is.
Figured it out: for whatever reason, I needed to add a delay in there. I think for whatever reason, by calling removeAllChildren(), something got messed up with the positions. It was my suspicion since SOME of the time, parts of the next level would load, but only some parts, and only sometimes.
Here's the code I added to run an action on the gameLayer once all children were removed, etc...
runAction(Sequence::createWithTwoActions(DelayTime::create(0.1), CallFunc::create( [&] ( ) {
loadLevel2(this);
})));
Before I go making major change in my ongoing game project, I just want to hear from others if anyone has found any issues with getObjectsUnderPoint() function of the DisplayObject?
Update:
Not just the performance issue but any other limitations of using it (like it doesn't detect certain type of UIelements (just as example))
I will have three layers in my application (which an Isometric game)
Background -- This is just a background which stays in the bottom, has nothing to do with game
Middle Layer -- This is the playable area, Here all my game elements will be placed on this layer
Top Layer -- This is one dummy transparent layer covers entire playable area which interrupts all the mouse events. This is where I want to use the getObjectsUnderPoint()
So, player wants to click on the element, the top layer will interrupt the mouseevent and then check if there is something placed or just a plain background and take appropriate action like, notify the underneath object.
This really doesn't require to be done this way because I could simply add moues events for all those items placed on the map directly but because I would be using getObjectsUnderPoint() anyway to check if there is anything beneath the item.
If anyone can explain how this function works then it would be little easy for me to make a decision.
There was one annoying problem though. I don't know if they fixed it or not. At least it was there in 10.1 times.
If you have a container and you scaled it container.getObjectsUnderPoint will return wrong result. All the time. So everywhere where I needed getObjectsUnderPoint I had to call it from stage to get proper result.
It's an incomplete function. It returns graphical objects under the mouse, NOT all potential mouse targets for event or interaction purposes. It actually requires complex logic to examine the array returned by getObjectsUnderPoint to determine the mouse target, because the appropriate target (the one Flash would choose if you actually clicked that point) may not be in the list.
First you'd have to examine the object array in reverse, since the items are ordered back to front. You'd have to examine each object's entire parent chain, looking for a parent with mouseChildren = false that would cause it to intercept the event and become the target. Whether or not such an object is found, this final object you arrive at must have its mouseEnabled property set to true, otherwise you must skip it and move on to the next object in the array, which would be, for example, the next sprite or shape behind the one you initially checked. While going through the list, you must notice when the parent changes, at which point you need to assume that all children of that common parent had their mouseEnabled property set to false, in which case the parent would become the next candidate. This is actually extremely complicated, because you're working backwards in a bottom-up approach with an incomplete set of objects that was generated from the top-down.
To get actual potential mouse event targets, consistent with the default dispatching logic... it is actually easier to start from the stage in a top-down manner and walk backwards through the display hierarchy in a depth-first search, checking mouseChildren to determine whether you need to step into children, and checking mouseEnabled if it's to be a target, otherwise stepping into the container's children and repeating the process from back to front again. This is much more accurate, complete, and staightforward. The only problem is you have to code it yourself.