WebGL with Viewer - Can't use multiple render targets. Falling back to two passes - autodesk-forge

How it is reproduced:
I go to the page where the viewer is used. Let's say, while waiting for it to fully load (it doesn't matter), there is no error in the console. Next, I go to another page on the site where the viewer is used.
When I load the page, an error appears in the console(attach a screenshot). After that, if I try to draw the model in the viewer, the viewer does not draw the model completely. And the viewer does not allow you to work with elements (for example, selection).
As a result of what could this error appear?
I didn't do anything special with the initialization of the viewer
Viewer verssion - 7.65

It is definitely possible to run the viewer in multiple browsers/tabs at the same time. Each tab should be using its own GPU context. I just tried loading the following URLs in different browsers at the same time, and all the viewers are rendering the models correctly:
https://forge-basic-app.herokuapp.com/#dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Zm9yZ2UtYmFzaWMtYXBwLWJ1Y2tldC9yYWNfYWR2YW5jZWRfc2FtcGxlX3Byb2plY3QucnZ0
https://forge-basic-app.herokuapp.com/#dXJuOmFkc2sub2JqZWN0czpvcy5vYmplY3Q6Zm9yZ2UtYmFzaWMtYXBwLWJ1Y2tldC9TcG9ydHMlMjBDYXIuZHdmeA
Are you seeing this issue with any Forge app (like the one I linked to), or just with your own one? And have you tried other browsers and other devices? It could also be hardware-related. Perhaps your hardware has fewer resources, and when one of the browser tabs loses context, the viewer cannot recover from that?

Related

Models created with `SceneBuilder` in `AggregatedView` disappear/reappear on rotate/zoom when loaded in combination with larger models

Custom objects disappear on every orbit zoom or rotation for about one second, then reappear again when added to a aggregated view in combination with a large model. While the objects are hidden, I can see that there is some reloading/rerendering of the other unrelated model going on.
Overlays (meshes rendered directly into threejs) obviously don't show this behavior.
I'm using viewer version 7.85 and the sample code from here: https://aps.autodesk.com/blog/custom-models-forge-viewer
modelBuilder.addFragment(sphereGeometry, sphereMaterial, sphereTransform);
Is there any way I can prioritize rendering of my custom model or disconnect the rendering from other loaded models?

Phenomenon in ForgeViewer 7.68

We are using ForgeViewer.
I tried using ForgeViewer 7.68, which was recently released to the public,
and experienced the following phenomenon.
When loading a file with a large number of parts with memory limit The loading process stops at the viewer loading screen and does not finish.
The memory Limited are configuration as follows.
loaderExtensions: {svf: "Autodesk.MemoryLimited",},
memory: {
limit: 256,
},
We checked with nwd files with 100,000 members.
Then it continues to load as shown in the image below,
No matter how long I wait, the model does not appear.
loading image
Previous versions would have displayed the model correctly.
Do you have a solution?
When selecting parts with memory limit applied, some of the parts that are not selected disappear.
Grant memory limits in the same way as the above item.
If you select a component in this state, some of the unselected components will be hidden.
This happens on both PC and iOS.
before select   after select
We have confirmed that this happens with any 3D files
This phenomenon will not be fixed until you select a location without a component.
This phenomenon was present in the previous version, but was the same in the latest version.
With ifc files, they are displayed at an unintended angle after loading.
When the ifc file is loaded, it is no longer displayed in the correct orientation as shown in the image below
normal     current
If the screen is moved even slightly in this state, it will suddenly change to the normal orientation.
Also, as it is now, the upper right cube and the model are not oriented in the same way, so it is in a strange state.
Do you know the cause of this?

How to restore viewer state directly from MarkupEdit or MarkupView mode?

With reference of https://forge.autodesk.com/cloud_and_mobile/2016/02/playing-with-the-new-view-data-markup-api.html, I am implementing 2D markup feature in forge viewer.
I'm using Autodesk.Viewing.MarkupsCore library to draw annotations over model in forge viewer. For that I'm loading Autodesk.Viewing.MarkupsCore extension as _markupsExtension .
I tried drawing some markup annotation and saved viewer state. When I tried loading these previously drawn annotations, It failed to restore viewer state, but it was loading annotations data properly.
// To draw and save markup
viewer.loadExtension("Autodesk.Viewing.MarkupsCore").then(function(markupExt) {
_markupsExtension = markupExt;
_state = _markupsExtension.viewer.getState();
_markupsExtension.hide();
_markupsExtension.enterEditMode();
//From now on, while in EditMode, the user will be drawing text boxes
_data = _markupsExtension.generateData(); //Annotations data can be generated
_state = _markupsExtension.viewer.getState(); //to store viewer state information
_markupsExtension.leaveEditMode();
viewer.unloadExtension("Autodesk.Viewing.MarkupsCore"); //User can navigate within model
});
// To load previously drawn markup
viewer.loadExtension("Autodesk.Viewing.MarkupsCore").then(function(markupExt) {
_markupsExtension = markupExt;
_markupsExtension.leaveEditMode();
_markupsExtension.show();
_markupsExtension.viewer.restoreState(_state); //it fails to restore state
_markupsExtension.viewer.impl.invalidate(true);
_markupsExtension.loadMarkups(_data, 'aaa'); //loads markup data while keeping viewerstate unchanged.
});
Why does it fail to restore state while being in markup viewing mode?
What is difference between _markupsExtension.viewer.restoreState(_state) and viewer.restoreState(_state)
================================ EDITED =============================
Is there any way where I could stay within editing mode/viewing mode and change viewer's state?
I am saving all markups in a list view in different sessions or file per session (referring https://forge.autodesk.com/cloud_and_mobile/2016/02/playing-with-the-new-view-data-markup-api.html ).
e.g. 1) I moved model to the top and drawn arrow pointing to particular object and I saved it with name "MarkupA.json".
2) I moved model to front and zoomed it out so that it went far from camera. Then I drawn Square markup and stored it with name "MarkupB.json".
3) Then again I kept model to default iso (home) mode and drawn text annotation and saved it with name "MarkupC.json".
All these markups are listed in the UI panel like a tree. So when am clicking on any particular name, that markup and its model viewer state has to get restored without change in any markup mode.
I have checked this similar functionality in bim360. When I stored different markups in BIM360, it stored all markups in its database and small thumbnail screenshot appeared for its relevant markup card. I viewed all markups in markup panel or comment panel.
When I clicked on specific thumbnail, every markup appeared with appropriate stored viewer state.
I am trying to get similar functionality in forge viewer using new Markups core extension and customised its markup code to store states with markups. When I tried to load each markup, it seems like markup is getting loaded but its viewer state is not able to get restored neither in edit mode nor in viewing mode. I understood that restoring state is not possible if we are in markups mode. But what if I want to show the previously stored drawn markup on particular view?
The workaround which I tried to switch between markup is as follow,
On click of another markup -
a) leave viewing mode
b) restore model with stored state
c) enter viewing mode.
d) load its markup svg.
The issue with this is it is taking too much time taking too much time to reload markup with restored state.
Can you please tell me if we have any other workaround or approach to achieve loading and restoring markup and its viewer state synchronously?
Why does it fail to restore state while being in markup viewing mode?
When in markup mode the camera is locked so you will need to drop out of edit mode before restoring Viewer states and then go back.
What is difference between _markupsExtension.viewer.restoreState(_state) and viewer.restoreState(_state)
No difference as _markupsExtension.viewer is just a reference of the plugin to the master Viewer object

NPAPI plugin refresh issue in Google Chrome

Or ... "When to call pluginWindowMac::InvalidateWindow()"?
Apologies. It's hard to be brief here, it's a fairly specific test case.
I'm testing an NPAPI plugin (now adapted to Firebreath) under Firefox,Safari,Chrome and IE.
I'm testing the plugin under both Windows and OS X.
It's a video player using OpenGL for all rendering. So on OS X I'm using a CAOpenGLLayer
derived class, and supporting the Invalidating Core Animation model, which is used under
both Firefox and Chrome.
The plugin is running well in all cases and on both platforms, except for Chrome (v26.0.1410.65) on OS X, where I'm seeing a weird 'refresh' issue under both OS X 10.6
and 10.7.
It's as if Chrome is double-buffering the composited layer somewhere. It's always one
'frame' behind the one drawn via OpenGL. I've proved this by numbering each draw call
and drawing that number into the OpenGL render as well as logging it via NSLog. What's
on screen is always one behind the logged draw callback (I'm not rendering video at
this point - it's paused).
By using a specific keyboard event to trigger a extra call to pluginWindowMac::InvalidateWindow(),
I can force an external invalidate that will bring what's on screen into sync with
what was last rendered, but it will lose sync again on the next draw call (triggered
by the layer setNeedsDisplay).
I'm presently calling pluginWindowMac::InvalidateWindow() at the end of each draw
callback. In other words at the end of the layer 'drawInCGLContext()' call. This would
seem to be the only logical place to do it. But I'm beginning to suspect that under
Chrome this just isn't working? Clearly the call works - as proved by the keyboard
triggered InvalidateWindow, but maybe it doesn't work from inside drawInCGLContext?
The plugin is running fine under Firefox (the other browser that uses Invalidating
Core Animation). But maybe that simply doesn't rely on a working pluginWindowMac::InvalidateWindow()?
Has anyone else tripped over this issue with Chrome? Any workarounds discovered? About
all I can think of right now is some kind of timer driven event to trigger an extra
Invalidate.

Limitations of Web Workers

Please bear in mind that I have never used Web Workers before and I'm having some trouble wrapping my head around them.
Here's an explanation of a simplified version of what I'm doing.
My page has links to various files - some are text, some are images, etc. Each file has an image showing a generic file icon.
I want the script to replace each generic icon with a preview of the file's contents.
The script will request the file from the server (thereby adding it to the cache, like a preloader), then create a canvas and draw the preview onto it (a thumbnail for images, an excerpt of text for text files, a more specific icon for media files...) and finally replace the generic icon's source with the canvas using a data URL.
I can do this quite easily. However, I would prefer to have it in the background so that it doesn't interfere with the UI while it's working.
Before I dive right in to this, I need to know: can Workers work with a canvas, and if so how would I create one? I don't think document.createElement('canvas') would work because Workers can't access the DOM, or am I misunderstanding when all the references I've found say they "can't access the DOM"?
You cannot access the DOM from web workers. You cannot load images. You cannot create canvas elements and draw to them from web workers. For now, web workers are pretty much limited to doing ajax calls and doing compute intensive things. See this related question/answer on web workers and canvas objects: Web Workers and Canvas and this article about using webworkers to speed up image manipulation: http://blogs.msdn.com/b/eternalcoding/archive/2012/09/20/using-web-workers-to-improve-performance-of-image-manipulation.aspx
Your simplest bet is to chunk your work into small chunks (without web workers) and do a chunk at a time, do a setTimeout(), then process the next chunk of work. This will allow the UI to be responsive while still getting your work done. If there is any CPU consuming computation to be done (like doing image analysis), this can be farmed out to a web worker and the result can be sent via message back to the main thread to be put into the DOM, but if not, then just do your work in smaller chunks to keep the UI alive.
Parts of the tasks like loading images, fetching data from servers, etc... can also be done asynchronously so it won't interfere with the responsiveness of the UI anyway if done properly.
Here's the general idea of chunking:
function doMyWork() {
// state variables
// initialize state
var x, y, z;
function doChunk() {
// do a chunk of work
// updating state variables to represent how much you've done or what remains
if (more work to do) {
// schedule the next chunk
setTimeout(doChunk, 1);
}
}
// start the whole process
doChunk();
}
Another (frustrating) limitation of Web Workers is that it can't access geolocation on Chrome.
Just my two cents.
So as others have stated, you cannot access the DOM, or do any manipulations on the DOM from a web worker. However, you can outsource some of the more complete calculations on the web worker. Then once you get your return message from the web worker inside of your main JS thread, you can extract the values you need and use them on the DOM there.
This may be unrelated to your question, but you mentioned canvas so i'll share this with you.
if you need to improve the performance of drawling to canvas, I highly recommend having two canvas objects. One that's rendered to the UI, the other hidden. That way you can build everything on the hidden canvas, then draw the hidden canvas on the displayed one. It may not sound like it will do much if anything, but it will increase performance significantly.
See this link for more details about improving canvas performance.