Related
I'm learned a lot of GLSL shaders through Three.js.
By this, I skipped learning the API of WebGL itself.
Along the way, I still gain a various understanding of WebGL concepts.
However, I'm curious if could gain more benefits from going deeper by learning WebGL API itself?
In other words, Is there any significant room for improvement or optimization if I moved from Three.js to pure WebGL?
To be more specific on what I needed to optimize.
I'm currently creating a simple raytracing from fragment shaders on Three.js, Multiple renders pass along the render pipeline.
But I also want to know the benefit of pure WebGL rather than Three.js in general use cases.
First, I never used Three.js, so I can't comment on how it is optimized or not. But, as a general consideration, libraries like Three.js are designed to be generalist and versatile, so, they are, per definition, not optimized. To be clear, They ARE optimized, probably as most as possible, but not optimized for every usages. They do compromises, and implements a lot of intermediary "invisible" mechanisms, routines and objects, to allow multiple scenarios to stay possible through easy way on the "user" side.
So, this depend on your usage of the library. Your shaders may be the real "bottleneck" of your "program", because they are really complexes, and in this case using Three.js or going directly via WebGL will change almost nothing except in the shader loading/compiling part, which is done once at start of the program. In contrary, if you are using a lot of library features, with many objects, many per-frame function calls for transformations, buffer loading, etc... It is possible to increase performances by creating your own optimized routines.
Anyway, learning WebGL stuff will allow you to understands how things work in the background, in certain level however. In my point of view, there is always a benefit to learn how to do without library, you learn the reality behind the library, and being able to create your own library. Once you know WebGL, tou can, for example, more easily jump to OpenGL, then maybe (if you are really brave) Vuklan.
I'm starting to learn ThreeJS. I have some very complex models to display.
These models come from Autocad files that my customer provides.
But sometimes the amount of details in the model is just way too much for the purpose of the website.
I would like to reduce the amount of vertexes in the model to simplify the display and enhance performance.
Is this possible from within ThreeJS? Or is there maybe an other solution for this?
There's a modifier called SimplifyModifier that works very well. You'll find it in the Three.js examples
https://threejs.org/examples/#webgl_modifier_simplifier
If you can import the model into Blender, you could try Decimate Modifier. In the latest version of Blender, it features three different methods with configurable "amount" parameters. Depending on your mesh topology, it might reduce the poly count drastically with virtually no visual changes, or it might completely break the model with even a slight reduction attempt. Other 3d packages should include a similar functionality, but I've never used those.
.
Another thing that came into mind: Sometimes when I've encountered a too high-poly Blender model, a good start has been checking if it has a Subdivision Modifier applied and removing that if so. While I do not know if there's something similar in Autocad, it might be worth investigating.
I updated SimplifyModifier function. it works with Textured models. Here is example:
https://rigmodels.com/3d_LOD.php?view=5OOOEWDBCBR630L4R438TGJCD
you can extract JS codes and use in your project.
I want to compare the performance of jQuery's animate function and pure CSS3 transitions. I've found out that there is a requestAnimationFrame API to measure the performance but it seems that it can only be used with the canvas element?
Is there a good way to test the performance of absolute positioning compared to CSS3 and canvas?
Is stats.js helpful and trustworthy? What are your experiences?
I built this jsPerf test. Unfortunately the jQuery.on method is not executed. :(
I would argue that transitions/animation rules should be in the CSS as they are a presentational element, and JavaScript is meant for behaviour. For this reason I would stick with CSS transitions and leave JavaScript to do form validation/ajax/etc. But that doesn't mean that JavaScript is a wrong technology to use for animation, the very nature of the web being that you can use technologies in a variety of ways, because there is a lot of overlap between them.
I have a few links for you that I think you might find useful; Paul Irish/Chris Coyier's discussion over translate, a video on animations in CSS transitions vs Javascript and this link showing the framerate comparison between jQuery and CSS. You can see in the third link that the CSS is definitely faster and smoother than the JavaScript; I'm guessing because it is hardware accelerated.
Couple of stackoverflow questions that conclude similarly: what's faster? CSS3 transitions or jQuery animations? :: Performance of CSS Transitions vs. JS animation packages
You're right in that the requestAnimationFrame function is only available for the canvas element. I would recommend using that if you are planning to sync CSS transitions with canvas output, as that is what it is built for, rather than going with setInterval.
I'm planning on writing a game, which will use a lot of sprites and images. At first I tried EaselJS but playing some other canvas-based games I realized it's not that fast. And when I saw BananaBread by Mozilla I thought "if WebGL can do 3D so fast, then it can do 2D even faster". So I moved to three.js (using planes and transparent textures, texture offset for sprites).
The question is: is it better? Faster? Most of the WebGL games are 3D so should I use canvas 2D context for 2D and WebGL for 3D? I've also noticed that there are no libraries for WebGL in 2D (except WebGL-2d, but it's quite low level).
Please note that compatibility is not my greatest concern as I'm not planning on releasing anything anytime soon :) .
The short answer is yes. WebGL can be quite a bit more efficient if you use it well. A naive implementation will either yield no benefit or perform worse, so if you're not already familiar with the OpenGL API you may want to stick to canvas for the time being.
A few more detailed notes: WebGL can draw textured quads (sprites) very very fast, but if you need more advanced 2D drawing features such as path tracing you'll want to stick to a 2D canvas as implementing those types of algorithms in WebGL is non-trivial. The nature of your game also makes a difference in your choice. If you only have a few moving items on screen at a time Canvas will be fairly fast and reasonably simple. If you're redrawing the entire scene every frame, however, WebGL is better suited to that type of render loop.
My recommendation? If you're just learning both, start with Canvas2D and make your game work with that. Abstract your drawing in a simple manner, such as having a DrawPlayer function rather than ctx.drawImage(playerSprite, ....), and when you reach a point where the game is either functioning and you want it to run faster or the game design dictates that you MUST use a faster drawing method, create an alterate rendering backend for all those abstract functions with WebGL. This gives you the advantages of not getting hung up on rendering tech earlier on (which is ALWAYS a mistake!), let's you focus on gameplay, and if you end up implementing both methods you have a great fallback for non-WebGL browsers like Internet Explorer. Chances are you won't really need the increased speed for a while anyway.
WebGL can be much faster than canvas 2D. See http://blog.tojicode.com/2012/07/sprite-tile-maps-on-gpu.html as one example.
That said, I think you're mostly on your own right now. I don't know of any 2d libraries for WebGL except for maybe PlayN http://code.google.com/p/playn/ though that's in Java and uses the Google Web Toolkit to get converted to JavaScript. I'm also pretty sure it doesn't use the techniques mentioned in that blog post above, although if your game does not use tiles maybe that technique is not useful for you.
three.js is arguably not the library you want if you're planning on 2d.
I'm planning on writing a game using javascript / canvas and I just had 1 question: What kind of performance considerations should I think about in regards to loading images vs just drawing using canvas' methods. Because my game will be using very simple geometry for the art (circles, squares, lines), either method will be easy to use. I also plan to implement a simple particle engine in the game, so I want to be able to draw lots of small objects without much of a performance hit.
Thoughts?
If you're drawing simple shapes with solid fills then drawing them procedurally is the best method for you.
If you're drawing more detailed entities with strokes, gradient fills and other performance sensitive make-up you'd be better off using image sprites. Generating graphics procedurally is not always efficient.
It is possible to get away with a mix of both. Draw graphical entities procedurally on the canvas once as your application starts up. After that you can reuse the same sprites by painting copies of them instead of generating the same drop-shadow, gradient and strokes repeatedly.
If you do choose to draw sprites you should read some of the tips and optimization techniques on this thread.
My personal suggestion is to just draw shapes. I've learned that if you're going to use images instead, then the more you use the slower things get, and the more likely you'll end up needing to do off-screen rendering.
This article discusses the subject and has several tests to benchmark the differences.
Conculsions
In brief — Canvas likes small size of canvas and DOM likes working with few elements (although DOM in Firefox is so slow that it's not always true).
And if you are planing to use particles I thought that you might want to take a look to Doodle-js.
Image loading out of the cache is faster than generating it / loading it from the original resource. But then you have to preload the images, so they get into the cache.
It really depends on the type of graphics you'll use, so I suggest you implement the easiest solution and solve the performance problems as they appear.
Generally I would expect copying a bitmap (drawing an image) to get faster compared to recreating it from primitives, as the complexity of the image gets higher.
That is drawing a couple of squares per scene should need about the same time using either method, but a complex image will be faster to copy from a bitmap.
As with most gaming considerations, you may want to look at what you need to do, and use a mixture of both.
For example, if you are using a background image, then loading the bitmap makes sense, especially if you will crop it to fit in the canvas, but if you are making something that is dynamic then you will need to using the drawing API.
If you target IE9 and FF4, for example, then on Windows you should get some good performance from drawing as they are taking advantage of the graphics card, but, for more general browsers you will want to perhaps look at using sprites, which will either be images you draw as part of the initialization and move, or load bitmapped images.
It would help to know what type of game you are looking at, how dynamic the graphics will need to be, how large the bitmapped images would be, what type of framerate you are hoping for.
The landscape is changing with each browser release. I suggest following the HTML5 Games initiative that Facebook has started, and the jsGameBench test suite. They cover a wide range of approaches from Canvas to DOM to CSS transforms, and their performance pros and cons.
http://developers.facebook.com/blog/post/454
http://developers.facebook.com/blog/archive
https://github.com/facebook/jsgamebench
If you are just drawing simple geometry objects you can also use divs. They can be circles, squares and lines in a few CSS lines, you can position them wherever you want and almost all browser support the styles (you may have some problems with mobile devices using Opera Mini or old Android Browser versions and, of course with IE7-) but there wouldn't be almost any performance hit.