Hacker News new | past | comments | ask | show | jobs | submit login

yeah, this is not really true either.

you should be careful with bold claims, especially if you don't have a great depth of knowledge (everyone should believe this...)

i commented on the post.

(don't let me nay-say too much. you have done a really wonderful thing here. that is what matters most.)




Can you explain why it isn't true? He goes into explicit detail why he thinks it's so, yet you have only repeated "you're wrong" without providing any counter example.


because you can throw 3d data down the pipe naively and it 'just work', it comes out with the same problems as naive use of 2d data - that the transform from world to clip-space becomes the identity matrix, which results in aspect-ratio stretching.

also the idea that old desktop OpenGL is valid any more grates and encourages using it... its something we would like to have died its death 5-10 years ago when it was already out of date.

its also the case that all of the 'desired' functionality for 3d which is 'missing' is equally applicable to 2d and so equally missing from the API. there are no rotations 'out of the box', no aspect ratio correction, no texture mapping, no anything. this is what we expect from a low-level API, the minimum set of features required to make the hardware do the job - not an encyclopaedic library of derivative functionality (this is the place of a higher level library than the hardware interface).

i think the author has confused it being a low-level API with it being 2D. these are not the same. its just as devoid of features regardless as to what space you are rendering in... i can really understand it if coming from a web background where the stack is gigantic and "low-level" is an utterly foreign concept.

(also, in my defence, i didn't go into great detail, since i commented on the post itself to avoid polluting HN with a conversation thread)


OpenGL certainly is a 3D library, but WebGL is based on OpenGL ES (the ES part being important here) and basically just provides facilities to transfer data to/from the GPU and run vertex and pixel shaders.

It is completely up to the user whether the position data for the triangles is given in 2D coordinates from the start or in 3D coordinates and then transformed to 2D coordinates in the vertex shader.

The fact that it makes it fast to do the math for 3D, does not make it a 3D API.


my issue is more with the specific criteria the author uses being invalid. there is no special 2d functionality, e.g. aspect ratio correction or rotations. there is special 3d functionality, and contrary to the authors claim, you can just throw 3d data down the pipe and have it work. you just have a fixed, non-aspect-ratio-corrected view, the same as you get when you naively throw 2d data down the pipeline.

also, please don't confuse OpenGL circa 1999 with modern OpenGL. the features removed in ES were considered bad practice 10-15 years ago... i do disagree with removing default shaders (our beautiful flexibility is now relegated to mere boilerplate) but i'm sure the OpenGL ARB had a good reason behind that choice (reducing driver responsibility, reducing points of failure etc.).

also, what is never up to the user is the perspective divide. if a naive user is not aware of this particular, very 3D specific gem, of the hardware/API then he will end up with subtle bugs and maybe even struggle to fix them due to the incomplete knowledge...

its got nothing to do with performance.


For novices like me, this site seems very useful. If there are some genuine problems, I hope you can take the time to report those issues on github.

Also, what's the final verdict on Fast InvSqrt()? Is the optimal magic number Q3's 0x5f3759df, Chris's 0x5f375a86, or your 0x5F375A7F?


i think i came to the conclusion of 0x5f375a84 at the end of that article. at least by the criteria the test program used to measure error.

the differences are tiny though, and there are other measures that can be used (which will result in different constants)

in any case, on most modern hardware it is not relevant since there is some lookup based instruction that is more accurate, and faster.

the problems here aren't enormous, a smart programmer will work them out for himself, but they are misleading. i think there is some confusion just because this is a low-level API, essentially a hardware abstraction layer, but the user is expecting high level features like a complete maths library. (maybe?)


These days sqrt and rsqrt are so cheap that they aren't a worthwhile optimization target. You're much better off optimizing cache usage.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: