I have created a three.js based web application for showcasing 3d tiles. You can find the showcase following this link: https://www.karak.at/workbench/dd6228117c6faec166b208710b5a52d5
How it works: an OBJ file is loaded and cloned multiple times using InstancedMesh to create a wall of tiles. Next one point- and one spotlight are added to the scene. The light’s positions react on the current mouse position. The scene is rerendered on mousemove.
Rendering works super smooth in all browsers on M1 based Macs and on all browsers excpet Chrome on Intel based Macs. Using Chrome version 98 on an Intel based Macs the computer is under heavy workload, fans go up, framerate drops and in worst case scenarios the app crashes.
Here are my renderer settings:
this.renderer = new THREE.WebGLRenderer({
antialias: AA,
powerPreference: "high-performance",
depth: true,
alpha: false,
stencil: false
});
Here is a Pen for showcasing the issue in an isolated environment: https://codepen.io/Huangart/pen/VwrVjpj
Is there something wrong on the implementation side of my app? Is this a known issue? Any ideas on how to overcome this Chrome issue?
I was having this same issue on the same hardware.
I think that's related to this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=1245448
Changing the ANGLE graphics backend flag on about:flags to Metal improved the performance a lot on my machine.
Related
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.
Im trying to open this link http://3dhd.co.il/mobile/170 in my chrome browser in samsung galaxy s6, and after about 2 minutes the browser crushes and im getting the message "Rats Web GL hit a snag".
I've tried following the chrome instruction (clear cookies etc), tried enabling the flags in chrome://flags.
How can i debug this problem and understand why is it happening,
i developed that scene, and i cant understand what i have done wrong.
Thanks.
Here's Suggestion .
Overlap vertices example :
It means that 3d mesh object is complex . Try to use blender ( free software ) open 3d object (import) click to enter edit mode . Then you can see numbers of vertex point. Best optimization for this example is to make convex optimise .
Also check materials !
See this answer :
Three.js project crashes mobile
Look at :
https://blender.stackexchange.com/questions/6253/how-to-convert-from-high-poly-to-low-poly
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.
I developed a mobile app inside Adobe Flex (4.6) and it includes using pinch-to-zoom functionality to zoom in on pictures to make it easier to read words in the pictures. In previous android versions (2.1 to 2.3.3 and 2.3.4 if you're running cyanogenmod) the pinch-to-zoom works fine. But if the app is run on an ICS (Android 4.x) device, the axes seem to handle the enlargement of the picture individually. i.e. when you move your fingers apart horizontally, the image gets very wide, but stays the same vertical size, and vice versa.
First, does anyone know why this is happening?
And second, does anyone know of a way to fix it to work as it did before?
I will update to include screenshots.
Update: I have confirmed this is also an issue with Honeycomb. i.e., 3.x OS acts the same as 4.x ICS.
Sense, running the latest HTC update:
ICS, on AOKP, but verified this is an issue with standard ICS distros as well:
Solved this. Code was previously:
protected function onZoom(e:TransformGestureEvent, img:Image):void
{
DynamicRegistration.scale(img, new Point(e.localX, e.localY), img.scaleX*e.scaleX, img.scaleY*e.scaleY);
}
change the final e.scaleY to e.scaleX. This makes it scale based on only one portion of the zoom (in the x direction) and scales both X and Y accordingly. Not exactly perfect, but it works very well in practice.
Final code is this:
protected function onZoom(e:TransformGestureEvent, img:Image):void
{
DynamicRegistration.scale(img, new Point(e.localX, e.localY), img.scaleX*e.scaleX, img.scaleY*e.scaleX);
}
I'm working in a quite uncomfortable setup and I'm trying to figure out how I can fix it.
I'm developing an AIR app that is receiving TUIO events from a Framework for a fiducial marker based multitouch table. Until yesterday I was faking the events by mouse to work faster, but then I connected everything to a TUIO simulator and the problems appeared.
The TUIO Simulator is a java app. By dragging markers on the simulator you can send OSC messages that I'm forwarding to my AIR app. The problem is that I'm noticing that when I drag something on the simulator, my AIR app lose the focus, and the AIR framerate suddendly drops. If I drag something on my simulator and I switch super fast to the AIR window, everything goes smooth, so it seems the problem is that if my AIR app is not the active app it's redrawn at a lower framerate (I remember reading something about this, not sure).
So my questions are: am I right about the fact that inactive windows in AIR are redrawn at lower framerate? do you have any suggestion/workaround to fix it and to allow me to interactive with the java app without my AIR framerate drops?
Sorry guys, I figured out the solution by writing the question :)
I just added:
this.stage.addEventListener ( Event.DEACTIVATE, onDeactivate );
private function onDeactivate (evt:Event):void {
stage.frameRate = 60;
}
In my main class, and everything is fixed.
I post the answer for people that could have the same problem in the future