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.
Related
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....
I'm just looking for someone to point me in the right direction. My Google-fu is failing me.
I'm working on a WebGL game, and I'm using raycasting for collision detection. I'm using Clara.io to create levels. I'm using THREE.ObjectLoader() to load the scenes. What I'd like to do is split the scenes I've made into smaller parts so as to not have to do raycasting on all vertices in the level. I'd like to not have to split the level mesh into tiny pieces inside of Clara for isolated raycasting, but instead do it within the game itself.
How do I go about only doing raycasting on a small section of a mesh? Is there a tutorial that anyone knows about or an example? I've chosen to not use heightmaps or any physics libraries.
Thank you in advance!
The problem of finding out which parts of mesh are relevant is usually solved using some sort of space partitioning algorithm. A relatively simple but effective approach for a static mesh is using an Octree.
A Three.js - specific implementation of an Octree (by Collin Hover) can be found here. You can either use it directly or take some inspiration from it to write your own.
Is it possible to "convert" a Three.js written script that uses a Three.js CanvasRenderer to a WebGLRenderer one and if so how?
The short answer is: yes.
And in general you'll get better performance, though you might have a different-looking result.
A very important difference is that you can't use the renderer .domElement as a Canvas-2D because the WebGL renderer is 3D. So if you've been using canvas commands to, say, draw text, you might have some work ahead to adapt them.
So... In the good old days of making games, when you were drawing sprites to the screen, you'd use ROPs to draw only the "non-transparent" part of your sprite. (Yes, I haven't done any game coding in a loooong time)
(In case you have no idea what I'm talking about, check this out. It was a beautiful hack)
I'm now trying to do some "HTML5 games", and I'm experimenting with different ways of doing things and measuring their performance, and I noticed that there seem to be no ROPs in Canvas. When you draw something, that "something" has a full alpha channel, and actually drawing semi-transparent things is exactly as fast as drawing "opaque" things.
Now, this is great if you're drawing semi-transparent stuff, but for 99.999% of what you're doing, this sounds incredibly wasteful, and it feels like if we did have ROPs, we could probably draw 10 times as fast using the old mask trick.
Am I missing something here?
Is there already a way with Canvas to "turn off alpha" to make it draw faster?
Am I completely crazy, and this doesn't matter because, really, I can actually already draw 1000 sprites in 3ms (300 FPS), plus the video card is probably doing it directly, or will soon, so what do I care?
What do you think?
Thank you!
Daniel
Am I missing something here?
Nay
Is there already a way with Canvas to "turn off alpha" to make it draw faster?
Nay, sorry. Alpha is simply in the element no matter what, as a fact of HTMLElement conventions to date I imagine. In fact the default state of canvas is 100% black pixels with full transparency.
I'm about to jump into some simple game development with Javascript. I would like to one day transition to 3D development but for now am only going to be doing 2D "top down" objects.
I know that this isn't ideal but I feel like it will help me get familiar with the 3D "environment".
I am using Three.js as it appears to be very well developed and I like that it can do Canvas, WebGL and SVG. However, my very first problem I've come across is, I don't know how to "move" an object. Using just Canvas I can easily take an object I have rendered and modify it's .x or .y property to "move" it. However, for Three.js objects so far all I've found is object.rotation.x, etc. I can move the camera, but this doesn't work because I need objects to move individually.
So I guess what I'm looking for is any resources into Three.js for 2D development, or developing a 2D top-down game in a 3D environment.
The Getting Started article is pretty good.
LearningThree.js got a series on "let's make a 3D Game".
There is a nice searchable reference available too.
Note that the project moves super fast so the API might change
here and there, so keep an eye out on github and when you
update always read the change log to see if you need to update your code.
Gooduck!.