I have one question about performance thing.
I have some animated Views, that have internally many layers (8 layers), but only 4 are visible at once, other have opacity of 0.
I am just wondering, if the surface has opacity of 0, is it rendered or is it culled down?
And if it is rendered, where/how do I disable it (mark non-renderable) with if-check?
Thanks!
Elements with opacity 0 don't render, and in famous, surfaces use perspective-3d which usually results in the browser compositing the contents as a gpu texture of sorts. This results in a huge performance increase.
Opacity 0 elements will still receive events however, which makes it different from, say, visibility hidden, which will ignore all events.
Related
Let's say I have a single Tilemap 6400 x 6400, I fill whole layer0 with some cell then I draw objects on top, and then even some more objects on top.
When rendering godot goes through it layer by layer? And objects on layer0 affect the performance while drawing for nothing? Even if they can't be seen?
Should I be careful about objects that can be seen and delete them on the TileMap to achieve the best performance?
I have a mapbox project in production where the street map the user customizes (location, zoom, and text) will ultimately be printed on a surface which has rather small dimensions (3.5" x 2.25" at 600dpi. keeping in mind that the zoom level affects the visibility of the different street types, The problem I am running into is this:
Since the canvas element renders at 72dpi, this means that in order to get an accurate representation of how the map will print, I actually have to make the map's div container real size # 72dpi (252px x 162px) which is of course quite small and far less detailed than the map will look when it's printed at 600dpi
In order to allow people to interact with the map at a reasonable size on the screen, the cheap solution is of course to scale up the canvas using css transforms: i.e. #mapContainer {transform: scale(2.5)}. However this results in a very pixelated map since, unlike svg vector graphics (as seen in the text and graphics overlays in the images below), the browser does not re-render the canvas when it scales up.
Unscaled canvas
Scaled Canvas
I have spent a lot of time searching for a solution to this problem, and at best it looks like I may have to utilize a method where I pull in mapbox data into tiling services like nextzen with data visualization libraries like D3.js but id like to make this one last ditch effort to see if there is any way to trick the browser into rendering this element in a higher size dpi without changing the map bounds or zoom.
I suspect the answer to this lies in a similar vein to this stack overflow question Higher DPI graphics with HTML5 canvas However when I attempt it, I get a null value for var ctx = canvas.getContext('2d') since the mapbox canvas is "webgl" not "2d"... looking into the "webgl" method of resizing a canvas for higher dpi here: https://www.khronos.org/webgl/wiki/HandlingHighDPI but I really am having a hard time understanding how exactly to redraw the canvas after the resize.
Is there a way to universally multiply physics2D calculations on the canvas?
I'm trying to make a set of canvas UI elements with 2D physic properties. The objects contain images and text, but need to respond to gravity, impacts, and overlapping collision boxes with other GUI elements.
I've added 2D RigidBody and boxCollider components to my objects. However, they move very slowly. If given a gravity, they fall slowly. If overlapped, they push each other apart slowly.
I've figured out that this is due to the canvas having a very large scale. My objects are effectively 'very big and very far away'.
I can't modify the canvas scale. It needs to be huge or I get render artifacts.
I can't just modify gravity because it doesn't provide a universal fix. Things fall faster, but they don't push apart or spring right.
I can't modify the timestep because it affects the whole world, not just the canvas.
My canvas objects have widths akin to 80, where unity physics expects widths akin to 1. How can I get them to behave like they have a width of 1?
Is there some universal scaling factor for canvas based physics, or am I simply mis-using the canvas for something it is not intended for?
if you are still having this problem, the answer to fixing the movement rates of your scaled-up objects is to scale up your movement forces as well as your gravity. If you can't get certain elements to work right, use a forcepush that you can set to any strength.
For example I have 2 layers: background and image. In my case I must show or hide an image on zoom value changed (simply float variable).
The only solution I know is to keep 2 various frame buffers for both background and image and not to draw the image when it is not necessary.
But is it possible to do this in an easier way?
Just don't pass the geometry to glDrawArrays() for the layer you want to hide when the zoom occurs. OpenGL ES completely re-renders everything every frame. You should have a glClear() call at the start of your frame render loop. So, removing something is done by just not sending its triangles. You might need to divide your geometry into separate lists for each layer.
Here is my test application inthree.js- http://zheden.elitno.net/
There are 2 cubes - green is the upper one. If you uncheck "Cube 2" (yellow inner cube), it becomes invisible. And when you rotate then camera and after rotating check back "Cube 2", it becomes outer. It reproduces not with all angles of rotation.
Adding "renderer.sortObjects = false" fixed the problem. But could you please explain me the reason of this behavior? Renderer sort objects based on their positions. Why order of rendering is changed when some object is transparent? It's position is not changed.
Is this related to Transparent textures behaviour in WebGL ?
Thanks,
Zhenya
There are no transparent objects in your demo, only opaque ones. You are changing the visibility.
WebGLRenderer sorts objects based on their distance from the camera, and renders objects in the sorted order. It renders opaque objects from front to back.
The rendering order can change due to how the sorting algorithm breaks ties when two objects are the same distance from the camera.
However, the render order is not necessarily changing when you toggle the visibility off and then on again. What can be changing is the distance to the depth buffer in the least significant digits due to roundoff when you move the camera. Hence, sometimes the second object renders, and sometimes it does not.
You have two cubes of exactly the same size and orientation in exactly the same location. Do not do that. It can cause you all sorts of rendering problems -- the most common of which, is flickering.
three.js r.58