{"action":"created","issue":{"url":"https://api.github.com/repos/mrdoob/three.js/issues/7037","labels_url":"https://api.github.com/repos/mrdoob/three.js/issues/7037/labels{/name}","comments_url":"https://api.github.com/repos/mrdoob/three.js/issues/7037/comments","events_url":"https://api.github.com/repos/mrdoob/three.js/issues/7037/events","html_url":"https://github.com/mrdoob/three.js/issues/7037","id":102613351,"number":7037,"title":"Halve uniforms used by PointLights","user":{"login":"benaadams","id":1142958,"avatar_url":"https://avatars.githubusercontent.com/u/1142958?v=3","gravatar_id":"","url":"https://api.github.com/users/benaadams","html_url":"https://github.com/benaadams","followers_url":"https://api.github.com/users/benaadams/followers","following_url":"https://api.github.com/users/benaadams/following{/other_user}","gists_url":"https://api.github.com/users/benaadams/gists{/gist_id}","starred_url":"https://api.github.com/users/benaadams/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/benaadams/subscriptions","organizations_url":"https://api.github.com/users/benaadams/orgs","repos_url":"https://api.github.com/users/benaadams/repos","events_url":"https://api.github.com/users/benaadams/events{/privacy}","received_events_url":"https://api.github.com/users/benaadams/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":2,"created_at":"2015-08-23T12:15:59Z","updated_at":"2015-08-24T07:20:18Z","closed_at":null,"body":"The uniforms used by point lights could be halved by combining parts:\r\n\r\n````javascript\r\n\"uniform vec3 pointLightColor[ MAX_POINT_LIGHTS ];\",\r\n\"uniform vec3 pointLightPosition[ MAX_POINT_LIGHTS ];\",\r\n\"uniform float pointLightDistance[ MAX_POINT_LIGHTS ];\",\r\n\"uniform float pointLightDecay[ MAX_POINT_LIGHTS ];\",\r\n````\r\n\r\nIf color and position were changed to ```vec4``` the distance and decay floats could be moved into the ```w``` component which would halve the number of uniforms used by it (at a cost of making the code less readable)\r\n\r\nContinuing from  #7028\r\n\r\n> This is unrelated, but another issue we run into constantly on Clara.io is blowing out the space for the light uniforms."},"comment":{"url":"https://api.github.com/repos/mrdoob/three.js/issues/comments/134070627","html_url":"https://github.com/mrdoob/three.js/issues/7037#issuecomment-134070627","issue_url":"https://api.github.com/repos/mrdoob/three.js/issues/7037","id":134070627,"user":{"login":"gero3","id":155535,"avatar_url":"https://avatars.githubusercontent.com/u/155535?v=3","gravatar_id":"","url":"https://api.github.com/users/gero3","html_url":"https://github.com/gero3","followers_url":"https://api.github.com/users/gero3/followers","following_url":"https://api.github.com/users/gero3/following{/other_user}","gists_url":"https://api.github.com/users/gero3/gists{/gist_id}","starred_url":"https://api.github.com/users/gero3/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/gero3/subscriptions","organizations_url":"https://api.github.com/users/gero3/orgs","repos_url":"https://api.github.com/users/gero3/repos","events_url":"https://api.github.com/users/gero3/events{/privacy}","received_events_url":"https://api.github.com/users/gero3/received_events","type":"User","site_admin":false},"created_at":"2015-08-24T07:20:18Z","updated_at":"2015-08-24T07:20:18Z","body":"Do we really need this??\r\nAs far as I can tell from the webgl specification, we shouldn't need to provide this as there is a section about uniform packing in the spec. I do not know tough if all implementation follow this.\r\n\r\nhttps://www.khronos.org/registry/webgl/specs/latest/1.0/#6.24 states:\r\n\r\n>The OpenGL ES Shading Language, Version 1.00 [GLES20GLSL], Appendix A, Section 7 \"Counting of Varyings and Uniforms\" defines a conservative algorithm for computing the storage required for all of the uniform and varying variables in a shader. The GLSL ES specification requires that if the packing algorithm defined in Appendix A succeeds, then the shader must succeed compilation on the target platform. The WebGL API further requires that if the packing algorithm fails either for the uniform variables of a shader or for the varying variables of a program, compilation or linking must fail.\r\n\r\n>Instead of using a fixed size grid of registers, the number of rows in the target architecture is determined in the following ways:\r\n\r\n> - when counting uniform variables in a vertex shader:\r\n>    getParameter(MAX_VERTEX_UNIFORM_VECTORS)\r\n\r\n> - when counting uniform variables in a fragment shader: \r\n>     getParameter(MAX_FRAGMENT_UNIFORM_VECTORS)\r\n\r\n> - when counting varying variables: \r\n>    getParameter(MAX_VARYING_VECTORS)\r\n\r\nhttps://www.khronos.org/registry/gles/specs/2.0/GLSL_ES_Specification_1.0.17.pdf Appendix A section 7 states:\r\n\r\n> The resource allocation of variables must succeed for all cases where the following packing algorithm succeeds:\r\n• The target architecture consists of a grid of registers, 8 rows by 4 columns for varying variables\r\nand 128 rows by 4 columns for uniform variables. Each register can contain a float value.\r\n• Variables are packed into the registers one at a time so that they each occupy a contiguous subrectangle. No splitting of variables is permitted.\r\n• The orientation of variables is fixed. Vectors always occupy registers in a single row. Elements\r\nof an array must be in different rows. E.g. vec4 will always occupy one row; float[8] will occupy\r\none column. Since it is not permitted to split a variable, large arrays e.g.. for varyings, float[16]\r\nwill always fail with this algorithm.\r\n• Variables consume only the minimum space required with the exception that mat2 occupies 2\r\ncomplete rows. This is to allow implementations more flexibility in how variables are stored.\r\n• Arrays of size N are assumed to take N times the size of the base type.\r\n• Variables are packed in the following order:\r\n1. Arrays of mat4 and mat4\r\n2. Arrays of mat2 and mat2 (since they occupy full rows)\r\n3. Arrays of vec4 and vec4\r\n4. Arrays of mat3 and mat3\r\n5. Arrays of vec3 and vec3\r\n6. Arrays of vec2 and vec2\r\n7. Arrays of float and float\r\n• For each of the above types, the arrays are processed in order of size, largest first. Arrays of size\r\n1 and the base type are considered equivalent. In the case of varyings, the first type to be packed\r\n(successfully) is mat4[2] followed by mat4, mat2[2], mat2, vec4[8], ve4[7],...vec4[1], vec4,\r\nmat3[2], mat3 and so on. The last variables to be packed will be float (and float[1]).\r\n• For 2,3 and 4 component variables packing is started using the 1st column of the 1st row.\r\nVariables are then allocated to successive rows, aligning them to the 1st column.\r\n• For 2 component variables, when there are no spare rows, the strategy is switched to using the\r\nhighest numbered row and the lowest numbered column where the variable will fit. (In practice,\r\nthis means they will be aligned to the x or z component.) Packing of any further 3 or 4\r\ncomponent variables will fail at this point.\r\n• 1 component variables (i.e. floats and arrays of floats) have their own packing rule. They are\r\npacked in order of size, largest first. Each variable is placed in the column that leaves the least\r\namount of space in the column and aligned to the lowest available rows within that column.\r\nDuring this phase of packing, space will be available in up to 4 columns. The space within each column is always contiguous.\r\n• If at any time the packing of a variable fails, the compiler or linker must report an error.\r\n\r\n\r\n\r\n"}}