Open Lukenickerson opened 6 months ago
Hi Luke, I hope you're going well!
Sorry for bothering you again with my damned hardcoded webgl library :D
The line you linked to is a golfed version of this pretty standard perspective matrix:
https://github.com/xem/webgl-guide/blob/gh-pages/lib/matrix.js#L1-L18
I don't understand the maths myself, just use it blindly.
I hope it can help you understand where the 999's and 1001's come from.
I'm currently working on a game for a game jam, but for now, feel free to fork W.js and use this code in replacement for the golfed one.
I'm sure we can figure out a way to add near and far parameters later without too much trouble, I just didn't encounter any use case for it so far. If your solar system is to scale, you should indeed increase these values... or scale down the system quite a lot!
Thanks so much! That example is very helpful.
I'm also working on a game jam game right now -- using W! Sadly I've run into so many roadblocks getting rotations to work correctly (especially a lookAt
function). I think it has something to do with (a) my inability to understand the underlying math, and (b) the DOMMatrix's rotateSelf
order of rotations. 😖
But as for this issue -- if I don't drop my project completely, I intend to expand the perspective, and then can consider how that might be parameterized for W.
Cool, are you doing that game for GameDevJS 2024? If it may help, there's also a lookAt function in my helper library: https://github.com/xem/webgl-guide/blob/gh-pages/lib/matrix.js#L92 And I also don't understand the math very well myself. I'm not sure rotateSelf has an order for the rotations... I thought it just puts the 3 angles in the matrix at once?
Yeah, I'm doing GameDevJS 2024. I was getting confused by trying to get AI to help, but they often use algorithms which infer different ordering or rotations. The MDN docs also say that DOMMatrix
uses ZYX, which is wrong. After some experimenting I found the order is XYZ, which in retrospect makes the most sense.
I made some changes to the W code in if(state.fov){ ... }
, and it seems to work well so far: https://github.com/morph-games/ring-rescue/blob/main/src/w.custom.esm.js#L151-L167
I might play around with it a bit more to see if there is anything else needed. The # of additional characters should be minimal.
The near and far values (the min and max values for the camera's frustrum?) are hard-coded to 1 and 1000. It would be useful to be able to adjust these. (Currently I'm working on a prototype of a solar system, and I'd like to use larger numbers for coordinates.)
I think this would involve adjusting the projection? https://github.com/xem/W/blob/gh-pages/w.js#L150 But I don't understand the math here. @xem I think this could be controlled via parameters on the
camera
method without adding too many bytes.