|
Yeah, I know FF and Chrome for sure support float textures on all the hardware that I own, including some lovely lovely laptops with linux. edit: yeah, scroll down to "WebGL Extensions" here
|
#
?
Jul 1, 2016 18:49
|
|
|
|
| # ? Jun 4, 2024 01:41 |
|
|
I actually did try using the OES_texture_float extension but it was broken on both Chrome and Firefox for me. I can't be certain that it wasn't partly my fault but there are definitely issues with the implementation on at least some OS/driver/GPU combinations, some of them severe. Now I'm just trying to stick to the spec as much as possible.
|
|
#
?
Jul 2, 2016 05:29
|
|
|
I found this again in my new emails, and I'd completely forgotten I'd actually signed up to get digests (I kept thinking it was cubebrush and marking emails as read I think?) and there's not much here but the tutorials that are here are pretty good, so I thought I'd share https://flippednormals.com There's some in the free section but it looks like they just need a ton more users in general, I haven't really heard it mentioned anywhere though 
|
|
#
?
Jul 2, 2016 15:07
|
|
|
Are there any good resources to get a good basic understanding of how modern GPUs (and GPUs in general) operate at a hardware level? So far all I've done is practical OpenGL, but I want to get a better understanding of how the underlying hardware works. I have a fairly decent (although basic) understanding of Von Neumann architecture and standard CPU instruction sets/memory, so preferably I'd like something that assumes some understanding of computer architecture.
|
|
#
?
Jul 3, 2016 23:19
|
|
|
Ryg has some excellent posts on this. https://fgiesen.wordpress.com/2011/07/09/a-trip-through-the-graphics-pipeline-2011-index/ https://fgiesen.wordpress.com/2013/02/17/optimizing-sw-occlusion-culling-index/ I also know quite a bit of both architecture and history, so I can help answer questions if you have any.
|
|
#
?
Jul 3, 2016 23:39
|
|
|
That looks perfect. Thanks!
|
|
#
?
Jul 4, 2016 01:04
|
|
|
https://developer.nvidia.com/content/life-triangle-nvidias-logical-pipeline
|
|
#
?
Jul 4, 2016 03:04
|
|
|
Here's a cube:  It's rendering triangles that should be invisible (the top of the cube) and maxing out their light intensity to white no matter the viewing angle. I'm not sure what's going on with this. I did put the code up on Github if anyone wants to peek. Here's the relevant function in framebuffer.cpp: Any thoughts? e: I'm a moron, you transform the normal by multiplying it with the inverse of the transposed ModelView matrix, not the transformation matrix. Luigi Thirty fucked around with this message at 01:19 on Jul 5, 2016 |
|
#
?
Jul 4, 2016 23:38
|
|
|
Luigi Thirty posted:Any thoughts? You're transforming normals into screen space which is probably some of it. Angles are not necessarily preserved after projection and I wouldn't expect transformedNormal to be normalized after the viewport transform either, so the shading will be screwy. You probably want to use ModelView.inverse().transpose() to compute world space normals when shading. That said, checking the sign of z in the screen space normal should work for checking triangle orientation. Have you checked that the winding is consistent? E: Well, I'm late.
|
|
#
?
Jul 5, 2016 01:36
|
|
|
Xerophyte posted:You're transforming normals into screen space which is probably some of it. Angles are not necessarily preserved after projection and I wouldn't expect transformedNormal to be normalized after the viewport transform either, so the shading will be screwy. You probably want to use ModelView.inverse().transpose() to compute world space normals when shading. Thanks anyway. Now if I can just figure out why my view turns into this mess if eye is at the same Z coordinate as an object, even if the object isn't visible, I'll be set! 
|
|
#
?
Jul 5, 2016 04:47
|
|
|
Oh boy. Today I got pointed to the slides for tri-Ace's R&D for Star Ocean 4. From 2009. The amount of stuff done (lens simulation! accurate bokeh shader) is insane. I want to figure out how to do this all eventually. Not to mention the rest of the R&D they've done more recently. I have a lot to learn...
|
|
#
?
Jul 5, 2016 05:25
|
|
|
Wow, that stuff is totally my kind of thing. Thanks for linking that!
|
|
#
?
Jul 5, 2016 06:57
|
|
|
Luigi Thirty posted:Thanks anyway. Now if I can just figure out why my view turns into this mess if eye is at the same Z coordinate as an object, even if the object isn't visible, I'll be set! Guessing divide by zero in your "screen_pos.xyz = screen_pos.xyz / screen_pos.w" equivalent. Perspective projection is singular in the plane of the camera, it's one of the reasons we have clip planes.
|
|
#
?
Jul 5, 2016 07:26
|
|
|
Xerophyte posted:Guessing divide by zero in your "screen_pos.xyz = screen_pos.xyz / screen_pos.w" equivalent. Perspective projection is singular in the plane of the camera, it's one of the reasons we have clip planes. Ooooh, when I redid/stole the matrix inversion function I took out the assert that bombed out if the matrix was singular to confirm that my projection was working right. I'll pop it back in to confirm that's what's going on and figure out why my clip planes aren't working properly after work!
|
|
#
?
Jul 5, 2016 14:46
|
|
|
Singular might not be the best word. With a perspective projection matrix  you get out.w = -in.z, regardless of your choice of n and f. So any vertex in the plane of the camera gets borked on projection if not already culled.
|
|
#
?
Jul 5, 2016 17:12
|
|
|
Suspicious Dish posted:Oh boy. Today I got pointed to the slides for tri-Ace's R&D for Star Ocean 4. From 2009. The amount of stuff done (lens simulation! accurate bokeh shader) is insane. I want to figure out how to do this all eventually. this is the good poo poo: http://research.tri-ace.com/s2015.html finally someone in graphics discovers the airy disc
|
|
#
?
Jul 5, 2016 20:04
|
|
|
https://www.youtube.com/watch?v=9YXhCK2tLCU how do i make it work
|
|
#
?
Jul 5, 2016 21:46
|
|
|
Xerophyte posted:Singular might not be the best word. With a perspective projection matrix Hmm... that doesn't look like the matrix I have which I got from here. I don't think this is doing what I think it does. I'm not sure what it's doing, actually, but messing with zNear and zFar doesn't do any polygon clipping when my cubes get too close or too many units away. code:Luigi Thirty fucked around with this message at 01:08 on Jul 6, 2016 |
|
#
?
Jul 6, 2016 01:05
|
|
|
Luigi Thirty posted:Hmm... that doesn't look like the matrix I have which I got from here. I don't think this is doing what I think it does. I'm not sure what it's doing, actually, but messing with zNear and zFar doesn't do any polygon clipping when my cubes get too close or too many units away. Sorry, I should be explaining this better. That matrix is the same thing as what I posted, just reparametrized on the FOV angles instead of the top-bottom and left-right planes used in the GL spec and with a different clip space orientation. It's good, don't worry about it. Point is that while the projection matrix isn't singular, it (by intent and necessity) projects all vertices in the plane of the camera to have a w-coordinate of 0. In your matrix specifically the w-coordinate is determined by code:A simple hack is to not raster any triangle where vertex.w <= 0.0 for any vertex, since actually clipping triangles is a pain. Xerophyte fucked around with this message at 09:52 on Jul 6, 2016 |
|
#
?
Jul 6, 2016 09:50
|
|
|
Oooooooh, I thought zNear and zFar represented clipping planes, not scaling for Z. I'll play with it some more, that should help me make it not explode.
|
|
#
?
Jul 6, 2016 12:48
|
|
|
Luigi Thirty posted:Oooooooh, I thought zNear and zFar represented clipping planes, not scaling for Z. I'll play with it some more, that should help me make it not explode. It does both. The projection maps the world-space coordinates (or actually view-space, since you've applied both the world and view transforms) into "clip space", which is bounded over [(-1, -1, 0), (1, 1, 1)]. This maps to the edges of the view frustum. Triangles are clipped to that volume.
|
|
#
?
Jul 6, 2016 13:13
|
|
|
Hubis posted:[(-1, -1, 0), (1, 1, 1)] We're talking gl so it's a unit cube isn't it?
|
|
#
?
Jul 6, 2016 18:07
|
|
|
Luigi Thirty posted:Oooooooh, I thought zNear and zFar represented clipping planes, not scaling for Z. My friend, I can't recommend enough that you enter Jim Blinn's corner and take a  trip with him down the graphics pipeline. Table of Contents: https://www.microsoft.com/en-us/research/publication/jim-blinns-corner-a-trip-down-the-graphics-pipeline/ Vintage hair aside, it's highly readable, comprehensive, implementable and era-appropriate to your 3D DOS adventures. It certainly helped me understand where I was putting all the bugs in various 3D engine prototypes back in the day, far more than any of the weightier reference tomes. (It's current pricing online seems steep to me, though.)
|
|
#
?
Jul 6, 2016 18:18
|
|
|
I also recommend that you do not use matrices for anything in your first engine. The project matrix is a notorious beast which does depth remapping, perspective projection, and focal zooming, all in one package, which means it's more difficult to understand than it should be. Do all that math by hand.
|
|
#
?
Jul 6, 2016 18:26
|
|
|
Suspicious Dish posted:I also recommend that you do not use matrices for anything in your first engine. The project matrix is a notorious beast which does depth remapping, perspective projection, and focal zooming, all in one package, which means it's more difficult to understand than it should be. Whoa whoa what? Just use some default math package, call CreateMatrixPerspective or something some other nerd wrote, and when poo poo doesn't look right try flipping the order you're multiplying your matrices in. This has been my professional strategy for a decade. At one point in my life I could derive all types of projection matrices, and it never came in useful.
|
|
#
?
Jul 6, 2016 19:45
|
|
|
Sex Bumbo posted:We're talking gl so it's a unit cube isn't it? Isn't the default gl depth range [0;1]?
|
|
#
?
Jul 6, 2016 19:51
|
|
|
In this case its a custom software rasterizer which seems to use (-1 -1 -1) to (1 1 1), at least if it follows that tutorial. It doesn't really matter what space you map to as long as you're consistent, but since there are so many ways to do this it can be frustrating to get to the right form by guessing. It could mean a lot of transposing things, multiplying some rows by 2 and generally changing the order of operations until the right answer happens to pop out, especially if new and not sure where to look. I'm not sure it's a good idea to do the projection step by step rather than drill down and try to figure out the matrix math though, but then again my normal approach is gently caress projection, shoot more rays. 
|
|
#
?
Jul 6, 2016 20:23
|
|
|
Yeah, the post was referring to matrices which don't compute the depth range though.Xerophyte posted:In this case its a custom software rasterizer which seems to use (-1 -1 -1) to (1 1 1), at least if it follows that tutorial. It doesn't really matter what space you map to as long as you're consistent, but since there are so many ways to do this it can be frustrating to get to the right form by guessing. It could mean a lot of transposing things, multiplying some rows by 2 and generally changing the order of operations until the right answer happens to pop out, especially if new and not sure where to look. Try test cases where you transform what you believe to be the world space extents of your camera frustum. They should ultimately map to the extents of your ndc-volume.
|
|
#
?
Jul 6, 2016 20:23
|
|
|
Xerophyte posted:In this case its a custom software rasterizer which seems to use (-1 -1 -1) to (1 1 1), at least if it follows that tutorial. It doesn't really matter what space you map to as long as you're consistent, but since there are so many ways to do this it can be frustrating to get to the right form by guessing. It could mean a lot of transposing things, multiplying some rows by 2 and generally changing the order of operations until the right answer happens to pop out, especially if new and not sure where to look. There are no matrices in this: http://magcius.github.io/sw3dv/sw_rast.html http://magcius.github.io/sw3dv/sw_rast.js And any math for this is extremely straightforward. You really don't need matrices -- they're just complicated, obscuring forms of basic adds and multiplies. Not to mention that the projection matrix pulls an awful hack with the depth remap. The depth remap is conceptually simple. You want [zNear, zFar] mapped to [0, 1]. Using basic linear interpolation, you get: remappedZ = (z - zNear) / (zFar - zNear). But of course you can't do that in a matrix, since it only has adds and multiplies. You can multiply by the inverse, so you get: remappedZ = (z - zNear) * (1 / (zFar - zNear)). A bit more math magic can turn that into add-multiply form: remappedZ = z*(zFar / (zFar - zNear)) + 1*((zFar * zNear) / (zFar - zNear)). There's still one problem. We don't have a constant 1 -- all we can do is pull from our input vector. So, uh, let's cheat. We have a w coordinate, which is always going to be 1, since our input coordinates are homogenous. We don't actually care about what w means, in this context, we're just using it to pull a 1 from. I still think remappedZ = (z - zNear) / (zFar - zNear) is easier to read.
|
|
#
?
Jul 6, 2016 22:20
|
|
|
Hubis posted:It does both. The projection maps the world-space coordinates (or actually view-space, since you've applied both the world and view transforms) into "clip space", which is bounded over [(-1, -1, 0), (1, 1, 1)]. This maps to the edges of the view frustum. Triangles are clipped to that volume. I did it! My camera can be coplanar on the Z axis with my pyramid of cubes!  I'm doing this because I've wanted to since I was a babby who played games on our sick 486SX/2 for the first time. I got a book on Rend386 that I couldn't understand out of a bargain bin when I was 12. It's a hacked-together pile of garbage combining a 2D DOS graphic library I wrote and a synthesis of as much info on 3D I could get from various places and as much geometry as I could teach myself in the past few weeks. It's slow but it's mine and I can spin flat-shaded models loaded from .OBJ files, dammit.
|
|
#
?
Jul 7, 2016 00:17
|
|
|
Suspicious Dish posted:I also recommend that you do not use matrices for anything in your first engine. The project matrix is a notorious beast which does depth remapping, perspective projection, and focal zooming, all in one package, which means it's more difficult to understand than it should be. IMO understanding projective geometry makes the entire process basically trivial. it's much easier to understand whats going on when u don't have magic formulas littered about
|
|
#
?
Jul 7, 2016 00:25
|
|
|
Don't worry, I have plenty of time to figure out two-dimensional rotations of the camera target point around the camera location point based on half-remembered 11th grade Euclidean geometry without matrices.
|
|
#
?
Jul 7, 2016 03:13
|
|
|
If you meant that sarcastically, that kind of exactly proves my point. A camera isn't a geometric construct. Moving the camera to the right 50 pixels is the same as moving everything in the scene to the left 50 pixels. So, all a camera does is be an inverse of those sorts of local transformations, for every object in the scene. If you ignore cameras, matrices, etc., then you can easily figure out how the projective geometry works. If you're implementing a software rasterizer, that's kind of a core requirement to understand.
|
|
#
?
Jul 7, 2016 04:10
|
|
|
I know that  and I understand how you make an orthographic projection from a set of vertices. I don't really understand the math behind perspective projection yet and I will continue to work on that. I kind of failed this stuff in college thanks to a learning disorder (dyslexia but for numbers  ) so it's pretty tough for me to comprehend.
Luigi Thirty fucked around with this message at 04:41 on Jul 7, 2016 |
|
#
?
Jul 7, 2016 04:39
|
|
|
This might just be me, but I find perspective projections much more intuitive than orthographic projections. If you disregard screen width, fov and local coordinate systems, you essentially just want to trace a line from the origin through an arbitrarily large plane which is a known distance from the origin (let's say 1) and oriented in the view direction. All this really boils down to is a problem where for each coordinate of X and Y, you have two similar triangles, you know the Z-value of the plane and all three values of the vertex, so you can use the fact that all sides scale by the same factor to find X and Y. For example, to find the X-value: Considering only the X-Z plane, the triangle made by the vector from the origin to the vertex and from the origin to the plane intersection point are similar (that is to say corresponding angles are equal.) This means that we know that the sides have to maintain their relationships, and the following must be true: Plane X/Vertex X = Plane Z / Vertex Z. Isolating the unknown (the plane intersection's X-coordinate) we get Plane X = Vertex X * (Plane Z/Vertex Z). Like I said this leaves out FOV and accomodation for the particular coordinate system needed to actually rasterise the triangles, but those things are a question of 1)determining the size of your effective plane based on FOV and 2) dividing/adding/subtracting from your plane coordinates to get it into whatever range you're working in. E: Ok, writing it out it's not that simple, but I still find orthographic projections harder 
Joda fucked around with this message at 05:18 on Jul 7, 2016 |
|
#
?
Jul 7, 2016 05:10
|
|
|
Luigi Thirty posted:I know that Watch this very introductory video I made for a bunch of people at work: https://www.youtube.com/watch?v=v8jUNC5WdYE Did it help?
|
|
#
?
Jul 7, 2016 05:18
|
|
|
Joda posted:This might just be me, but I find perspective projections much more intuitive than orthographic projections. Poking around at work I found a copy of some lecture slides from a computer vision class with helpful diagrams too and I don't think this really is as complex as I thought. I'll look through everything plus that video and play with doing just straight projection math on model vertices.
|
|
#
?
Jul 7, 2016 18:51
|
|
|
Suspicious Dish posted:Watch this very introductory video I made for a bunch of people at work: https://www.youtube.com/watch?v=v8jUNC5WdYE Yes, that helped a lot and it's not really that complicated!
|
|
#
?
Jul 8, 2016 17:11
|
|
|
I'm glad! And yeah, one of my major choices for that talk was to not talk about a matrix the whole time, so I'm glad it paid off... Good luck with your project! Let us know if you have any more questions or need any more help...
|
|
#
?
Jul 8, 2016 20:59
|
|
|
|
| # ? Jun 4, 2024 01:41 |
|
|
Suspicious Dish posted:I'm glad! And yeah, one of my major choices for that talk was to not talk about a matrix the whole time, so I'm glad it paid off... I managed to get controls hooked up so I can rotate and translate a (wireframe for the moment) world. What I'm stuck on now is figuring out the proper scaling setup so the FOV isn't super tight in my 320x200 world!  
|
|
#
?
Jul 11, 2016 00:37
|
|