This may be a bit of a naive question so please go easy on me. But I was looking at shaders at shadertoy.com and I'm amazed at how small the glsl code is for the 3d scenes. Digging deeper I noticed how most of the shaders use a technique called ray marching.
This technique makes it possible to avoid using vertices/triangles altogether and just employ the pixel shader and some math to create some pretty complex scenes.
So I was wondering why is it that 3d scenes often use triangle meshes with webgl instead of just using pixel shaders. Can't we just render the entire scene with glsl and pixel shaders (aka fragment shaders)?
The simple answer is because the techniques on shadertoy are probably 10,100,1000 times slower than using vertices and triangles.
Compare this shadertoy forest that runs at 1fps at best fullscreen on my laptop
https://www.shadertoy.com/view/4ttSWf
To this Skyrim forest which runs at 30 to 60fps
https://www.youtube.com/watch?v=PjqsYzBrP-M
Compare this Shadertoy city which runs at 5fps on my laptop
https://www.shadertoy.com/view/XtsSWs
To this Cities:Skylines city which runs at 60fps
https://www.youtube.com/watch?v=0gI2N10QyRA
Compare this Shadertoy Journey clone which runs 1fps fullscreen on my laptop
https://www.shadertoy.com/view/ldlcRf
to the actual Journey game on PS3, a machine with an arguably slower GPU than my laptop given the PS3 came out in 2006, and yet runs at 60fps
https://www.youtube.com/watch?v=61DZC-60x20#t=0m46s
There's plenty of other reasons. A typical 3D world uses gigabytes of data for textures, characters, animations, collisions etc, none of that is available in just GLSL. Another is often they use fractal techniques so there's no easy way to actually design anything. Instead they just search the math for something interesting. That would not be a good way to design game levels for example. In other words using data of vertices makes things far more flexible and editable.
Compare the Journey examples above. The Shadertoy example is a single scene vs the game which is a vast designed world with buildings and ruins and puzzles etc...
There's a reason it's called ShaderTOY. It's a meant as a fun challenge. Given a single function who's only input is which pixel is currently being drawn, write code to draw something. As such the images people have managed to draw given that limit are amazing!
But, they aren't generally the techniques used to write real apps. If you want your app to run fast and be flexible you use the more traditional techniques of vertices and triangles. The techniques used by GTA5, Red Dead Redemption 2, Call of Duty, Apex Legends, Fortnite, etc....
Related
I created a sketch which draws 100s of thousands of lines. As expected, it is quite slow. So, I tried the same sketch with WEBGL mode. But this turned out to be slower than the default mode.
My understanding was that WEBGL leverages GPU for fast rendering. Is it not true?
Thank you.
createCanvas(windowWidth, windowHeight, WEBGL)
Side note: I coded this sketch first in Processing (java), where the WEBGL mode was 100 times faster than the default mode. So, I expected the same with P5js.
Drawing numerous stroked shapes in p5.js with WEBGL is notoriously slow. See: Sketch runs slow in P5.js WEBGL on the processing.org Discourse forum. If you specifically want to draw lines and/or curves and you don't need 3d perspective then a 2d canvas will actually perform better (and in most browsers it will still utilize the GPU). If you are actually utilizing 3d perspective and other WEBGL rendering capabilities then the key thing is to reduce the number of drawing instructions, and if possible avoid relying on p5.js to draw strokes. In order to give you more specific advice on how to do that you are going to have to post a minimal reproducible example of what you are trying to do.
I am trying to use particle systems to speed up the rendering of a system of stars, but I've noticed that the display is really bad on weak graphic cards (for example on Intel HD, which are pretty widespread). The particles, which should have a specific texture, are replaced by ugly squares with strange colors and transparency. For instance, this system of particles renders to :
This can be reproduced with any instance of THREE.ParticleSystem or THREE.Points (the more modern version). All the other THREE objects (Sphere, Cubes, Planes, etc.) are rendering well on my GPU, only particles bug.
Is there a way to avoid this effect? Otherwise, is there another method than particle systems to display a large number of objects without slowing down?
I'm not sure about your specific case but I've found that drawing a 'Point' primitives may be problematic for some GPUs, drivers and/or API versions.
They are just a primitive type and should work the same as Triangles and Lines, but for some GPUs - especially the low-end ones - they just don't work. And if the drawing Points works by itself - it doesn't support point sizes, or texturing, or something else...
In such case you may replace them with regular textured quad and it should be fine. You'll probably lose some performance this way so you may keep both approaches and select one based on GPU.
I'm trying to implement a 2D version of the marching cubes algorithm (marching squares?), and one of the major roadblocks I've run into is the performance issues (using WebGL and three.js). I notice that there's a huge tradeoff between quality (voxel/square size) and performance, and I think that the culprit for this is the center (solid area) of the metaballs:
Obviously I don't care about the faces on the inside of the metaballs since that's a completely solid area anyways; but I'm not sure how to get around polyganizing the interior area without treating it the same as the rest of the surface. The problem becomes worse when I add more metaballs to the mix.
How can I get around this problem, to maintain a decent quality and be able to render many metaballs at a decent framerate?
If you are implementing the standard marching squares technique then the cases inside and outside the surface shouldn't be a problem. In fact they are the cheapest because you don't need to do any computation for them.
If you want to reduce the poly-count in areas where it is not needed (the central area of the circle), you need to look into using an adaptive sampling technique. In this case probably most adequate would be a quad-tree (2d octree).
The speed issue when decreasing the cell size would always be there because Marching Cubes is a O(n^3) algorithm (very slow), thus marching squares would be O(n^2) (still very slow). There is no way around that. (Using an adaptive sampling data-structure, as mentioned above, would speed things up.)
It seems to me you could improve on the quality at the lower resolution. The circle seems to be aliasing a lot (assuming this is not because it is actual low screen resolution). I would check again how you interpolate on the edges of the squares (i hope you don't just use the centres of the edges) - using a more appropriate interpolation will give you better approximation and you would get better results at lower resolution.
See Paul Bourke's article on marching cubes and checkout the interpolation if you are not doing it.
Here are some references for 3d isosurface extraction techniques, (mostly based on MC) but you could benefit from them, in your 2d case:
(Kazdan et al, 2007)
(Manson and Shaefer, 2010)
(Wilhelms and Gleder, 1992)
PS: also check out their references for many more similar and maybe foundation papers!
I'm making a top-down game with simple 3d graphics. (I'd be happy if it were like gta 2.) I've implemented affine texture mapping that I have found here but it is too CPU intensive.
So my question is: Is there a better solution? I don't understand WebGL, but maybe hardware-accelerated texture mapping would be better than this? I need a function, that will map a texture on a quadrangle.
You can try my game here. (press J to see a wireframe and K or L to improve fps or quality) As you can see it really needs some optimalization. :-)
First off, that's an awesome demo! Kudos for getting that much working on it.
For a usage like this WebGL will absolutely give you better performance, and given that all it looks like you need is some textured cubes, I don't think that it would be terribly difficult for you either. Yes, 3D has more of a learning curve than 2D canvas work, but considering that you're already doing a lot of the math to simulate 3D anyway you'll probably find "real" 3D to be easier!
A good place to start would be the lessons at LearningWebGL.com. They'll run you through the basics, and texture mapping (the bit you want) is only 5 lessons in.
Of course, you could also get a little bit crazy and get the effect that you're looking from with pure CSS! There's a pretty cool demo of somebody actually building a city scene with it, so it's certainly possible. That feels like a bit of a stretch, though, and you'll probably be much better of from a feature perspective with straight WebGL.
I'm currently reading up on the canvas, but I'm finding it hard to find practical benefits of using canvas, when a lot can be done using simple css overlays/JavaScript (+ jquery lib).
This is probably because I don't know the FULL practicalities of using canvas.
Looking at this game:
http://www.pirateslovedaisies.com/
Could someone help explain how and why canvas is being used as opposed to just css?
This is a 4k js/canvas demo I wrote to experiment with the 2d context (here is a video if your browser doesn't work). I tested it only on chrome, opera, firefox, safari and nexus one browser.
Note that no external resources are loaded (i.e. the texture and the raytraced envmap are built dynamically), so this is just a single self-contained 4096 bytes HTML file.
You can do something like that with DIVs?
But indeed I agree that the game you linked IMO could be done also with DIVs; apparently there are no transformations - not even in the falling daisy loading scene - and the action areas for the pirates are just circles. Not sure but could be that even shooting only happens at fixed angles.
Canvas could have been used instead for:
Drawing general sloped lines and polygons (the map could be created dinamically from a compact description or could have been generated randomly). Shooting could be done at any angle...
Procedural image creation (e.g. textures or special pixel effects)
Gradients, texture mapping
General 2d matrix transforms
Of course a game using an image+DIVs approach is probably way easier to make (a lot of photoshop and simple xy animation).
Creating tons of HTML elements is extremely slow and memory-hungry. The canvas object is made for graphics operations and thus optimized for it. Besides that.. how would you draw a curve with plain HTML/CSS? ;)
Using <canvas> you have a per-pixel control of what's shown on the screen. You don't have to deal with specific browser CSS or DOM compatibility.
Also, that's actually a pretty similar programming model to 2D non-browser games, like those created using SDL o DirectDraw.
Here's a game I wrote in a few hours using Canvas; note that the scaling of the tiles, the anti-aliasing of the lines, is perfect. This would not be the case with image tiles that were being resized by the browser.
Click the tiles to rotate them in an attempt to make all connections. Click the row of buttons at the top for a new board of a different size; click the row of buttons below that for a new board with different numbers of connections.
The game concept is not mine, only the implementation.