• Content Count

  • Joined

  • Last visited

  • Days Won


Quant3D last won the day on August 14 2017

Quant3D had the most liked content!

About Quant3D

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I’ve experienced a strange problem in Firefox where a BabylonJS program works fine at ≈60fps until suddenly this drops to ≈30fps. The app itself isn’t lagging. It seems to me that Firefox just decides, for whatever reason, to serve up the program at 30fps instead of 60fps. A couple questions: Is there any way to obtain what the browser and BabylonJS are targeting as a frame rate? This would help to narrow the source of the problem. If an app is graphics intensive, as opposed to script intensive, could it be better to base scene optimizations off of getLastFrameDuration() or getRenderDuration()?
  2. A couple months ago I posted this topic about a neural network visualization I wrote (ann.miabellaAI.net). I've greatly expanded the interaction between BabylonJS and HTML/CSS. As long as your display elements are in front of your WebGL scene, CSS allows for a wide variety of dynamic effects. Here's a tip: there can be issues with rendering quality when zooming in on HTML text and canvas graphics. If an element is going to be zoomed in and out, one idea is to start by making it oversized and then shrinking accordingly. That is what I do here. To expand or shrink the node graphs, you press the "x" key or click the main mouse button.
  3. Following up on my last post, it is easy to see what I am talking about by using the BabylonJS playground. The attached image shows how the render quality becomes degraded after I select the “zoom” feature in a browser by pressing CTRL+. Both versions are the same size on the monitor. But the second picture is of lower quality because the browser zoom reduces the size of the WebGL drawing canvas from 1455x1080 to 485x360 pixels. This implies that the rendering quality of a BabylonJS program might depend on browser magnification settings that people use for other reasons (like making reading text larger).
  4. Okay I think I might have found the problem. It seems to me it relates to the internal screen magnification of each browser. Here's what you do to see this: Open a BabylonJS app in a browser. Start pressing the browser's command to zoom in (e.g., CTRL+). What you should see is that the BabylonJS graphics don't move on the screen, but the render quality keeps getting worse and worse. This is because the "zoom" command is decreasing the size of the WebGL render canvas. The graphics don't move on the screen because typically a BabylonJS program covers the entire browser window, regardless of the size of the WebGL render target. This also works in reverse! If you zoom out (e.g., CTRL-) you are making the render canvas larger and larger. This causes over-precision in the drawing, and eventually you will see the frame rate drop off dramatically. If this is indeed the issue, it might be helpful to have BabylonJS maintain a constant render canvas size irrespective of a browser's screen magnification. This would be similar to using "engine.resize();" when a user changes the size of the browser window.
  5. Hi Deltakosh and Dad72, I was able to determine that the Windows machine I am working on was set to magnify the screen by 125%. So many of the numbers I listed in previous posts were a function of the operating system settings. (When this happens, you are projecting a diminished WebGL render canvas onto a larger screen size, so there is a decrease in graphics quality.) Irrespective of the system settings, the issue with Chrome is still pertinent. Even at normal (100%) screen scaling, the WebGL drawing canvas can be 1/3 too small both vertically and horizontally. If this happens, it means that the render canvas in Chrome is only about 45% the size it should be, and therefore the graphics quality is poor. I am seeing the same thing happen in Microsoft's Edge browser, but not in Opera or Firefox. Dad72: I just tried engine.resize(). No effect, but thanks.
  6. Another update: I was able to do some testing on a Mac, and I was unable to reproduce the problem on Mac OS X. From any BabylonJS program, a line like this gives the size of the drawing canvas: console.log(engine.getRenderWidth() + "," + engine.getRenderHeight()); I tried this on Mac OS X using Safari, Firefox, and Chrome, and in all three cases the results were the expected 1920x1080 pixels (give or take a bit for menus, page tabs, etc.). On my Windows, the render target starts off smaller than the screen -- something like 1536x755 in Firefox and Opera. In Chrome the drawing canvas can be much smaller, like 1025x506, which leads to very poor quality graphics.
  7. I did some further checking, and here is what I found. On my 1920x1080 monitor, a full-quality WebGL drawing canvas would be about 942 pixels high (after accounting for the application task bar and the browser menu). Here is what my drawing area height is on three browsers with Windows 10: Firefox: 755 pixels Opera: 754 pixels Chrome: 506 pixels It seems to me that on all three browsers, there is some quality degradation as the smaller canvas gets expanded onto the larger screen, and it is worse on Chrome than the others. It should be said that this type of reduced-canvas optimization could be intentional in many circumstances to achieve a high frame rate. For instance, if I run the BabylonJS scene optimizer, the drawing canvas height on Chrome goes to 253 pixels. So I wonder whether there may be unwanted optimization at some level.
  8. I am also getting very low quality rendering in Chrome. To me, it doesn't look like an anti-aliasing issue. Rather, it seems to me that the WebGL drawing canvas is way too small and therefore loses resolution when expanded into a larger screen area. I checked the element dimensions while my program is running, and it seems to me they are about 1/2 too small both vertically and horizontally. This means that the WebGL drawing canvas is about 1/4 the size it should be. It appears to me that this sizing problem goes all the way up the DOM to the "body" element. For example, Chrome says that the body and canvas height are 506 pixels, when they both are actually about 1000 pixels high (1080 pixels minus the application task bar). I have width and height set at 100% on all the major elements -- including the HTML body and canvas -- so something is not sizing the body or the BabylonJS canvas correctly.
  9. @satguru: Thanks for mentioning TensorFire (tenso.rs). Definitely worth checking out. I've done some work with GPU-accelerated computing in the past. I think their claim of a possible 100x speed-up is about right, provided that a problem can be divided into pieces (i.e., the solution doesn't depend on sequential calculations or other dependencies between the data points).
  10. I wrote an interactive neural network visualization web program where people can explore the inner workings of neural networks. Here is the description page (where I mention and link to BabylonJS in the FAQ): miabellaAI.net This is the browser-based application: ann.miabellaAI.net
  11. My understanding is that every instance of a material requires a separate draw call. In a scene with many similar meshes, it would be nice to have them share one material but have basic differentiation by color or transparency. Is this possible without creating many materials or looping over lots of vertex data? In other words, does the standard material shader allow for color as an attribute that can be set per mesh?