Fast RectAreaLight implementation using Linearly Transformed Cosines #9234

Closed
wants to merge 3 commits into
from

Projects

None yet

9 participants

@abelnation
Contributor
abelnation commented Jun 27, 2016 edited

Addresses #8718

Working example:
http://groovemechanic.net/three.js.release/examples/webgl_lights_rectarealight.html

This PR presents a fast implementation of rectangular area lights. The implementation is heavily based on work from a recent ACM SIGGRAPH 2016 publication. Currently, the implementation is integrated into the BlinnPhong material model, however, I will be working to integrate the Standard/Physical material models as well while feedback is gathered.

This implementation does not include the following:

  • Shadow support for RectAreaLight
  • decay/distance params
  • widespread mobile support (due to reliance on float textures, though it appears to work on my new iPhone SE)

I am considering this PR a work in progress, but hope to integrate feedback to drive towards a merge-able implementation.

Work to be done as Follow-up PR's

  • support shadows for RectAreaLight
  • explore using HalfFloat textures instead of Float to increase mobile support
  • distance/decay parameters
  • integration with exporters/editor
  • compression of BRDF float data (see #9373)
  • optimization options for faster rendering

image

@bhouston
Contributor
bhouston commented Jun 28, 2016 edited

I favor acceptance and we can further improve it once it is in dev.

I do notice there is a weird artifact on the floor I see on my laptop (Windows 10, Chrome latest, NVIDIA 960M):

image

@bhouston
Contributor
bhouston commented Jun 28, 2016 edited

Here is another shot of the artifacts, may be caused by my extreme light shape:

image

I've upped the contrast a bit with a regular light shape and I can see this:
image

I think we can still accept this PR because it is the best area light we can get, and we should aim to improve its quality once it is accepted.

@abelnation
Contributor
abelnation commented Jun 28, 2016 edited

@bhouston very interesting. will see if i can repro, and investigate. perhaps it has to do with interpolation of the matrix values

@abelnation
Contributor
abelnation commented Jun 28, 2016 edited

@bhouston I re-introduced a tweak to how the texture coords are calculated. i'm having trouble reproducing on my mac. i see a small amount of banding, but nothing like the artifacts you have in your screenshot

Does this link exhibit the same artifacts at the one in the PR description?

@abelnation
Contributor

@bhouston it could also be useful to know if you can repro the same artifacts on the original webgl demo:
http://blog.selfshadow.com/sandbox/ltc.html

@bhouston
Contributor

The "With tweak" has the pattern:
image

Here is a screenshot of the original from blog.selfshadow.com with an extreme light and the contrast enhanced, it is actually quite smooth and artifact free (there will always be some banding because the screen has limited bit depth):
image

@bhouston
Contributor

I found out that I was actually using an " Intel® HD Graphics 530" GPU that has the artifacts, not the NVIDIA 960M -- my laptop was using the integrated GPU for Chrome. I tested the same examples on my desktop with an NVIDIA GPU and it works without any artifacts.

@mrdoob mrdoob commented on the diff Jun 28, 2016
src/renderers/WebGLRenderer.js
_lights.point.length = pointLength;
_lights.hemi.length = hemiLength;
- _lights.hash = directionalLength + ',' + pointLength + ',' + spotLength + ',' + hemiLength + ',' + _lights.shadows.length;
+ _lights.hash = [
+ directionalLength,
+ pointLength,
+ spotLength,
+ rectAreaLength,
+ hemiLength,
+ _lights.shadows.length
+ ].join(',');
@mrdoob
mrdoob Jun 28, 2016 Owner

Not sure if this is something closure compiler cleans up, but the original intention of the code was to avoid the array allocation.

@abelnation
abelnation Jun 28, 2016 Contributor

Ah, yeah, I made that change primarily for readability. Happy to switch it back. In general, I'd try to promote the practice of adding comments around code choices made for non-intuitive optimization purposes.

@mrdoob
Owner
mrdoob commented Jun 28, 2016

Minor thing but... How about AreaLight instead of RectAreaLight?

@abelnation
Contributor
abelnation commented Jun 28, 2016 edited

@mrdoob, the name was a suggestion from @bhouston, and I think it makes sense given that a few other types of AreaLights might be worth pursuing, e.g. Disk/CircleAreaLight, SphereAreaLight, etc.

The shader render equation is tailored, in this case, to handle a quad-shaped light. The params that the constructor takes are also specific to it being a rectangle (width, height).

@abelnation
Contributor

One key question to consider: This implementation hard-codes the look-up texture values for the Rect light calculation in arrays inside UniformsLib.js. That data alone adds ~80k to the source code. Do folks feel ok with that? Should it be something you have to compile in as an extra?

@abelnation
Contributor

RE the intensity question, I'm curious what others think. Should intensity represent (a) the irradiance of the entire rect light or (b) the radiance from any given point on the surface of the light?

With option (a), the scene should look equally bright regardless of the size of the area light. Larger rect lights would have larger, but dimmer highlights than smaller rect lights

With option (b), specular highlights will appear the same brightness, but overall scene brightness will increase with the size of the rect.

@abelnation
Contributor
abelnation commented Jun 29, 2016 edited

@bhouston take a look at the example now. scaling intensity by the rect area feels much more natural. also cool to see scene stay roughly the same but watch the specular highlight size change as you change the dims of the rect

@bhouston
Contributor
bhouston commented Jun 29, 2016 edited

This implementation hard-codes the look-up texture values for the Rect light calculation in arrays inside UniformsLib.js. That data alone adds ~80k to the source code. Do folks feel ok with that? Should it be something you have to compile in as an extra?

Argh, that is huge. Any way to precompute that easily? Maybe the first time it needs them, it calls a function that computes these values.

Maybe there is code hanging around somewhere that already does that -- or ask the paper authors for a copy of it. If not, we can not include that in the base ThreeJS but as an add on inside of examples/js.

@abelnation
Contributor
abelnation commented Jun 29, 2016 edited

@bhouston Their pre-computed values are the result of a "fitting" process, whereby they regress on the parameters that result in a distribution that most closely matches the GGX distribution. I do not believe (but could be wrong) that it's feasible to pre-compute the value on the fly each time three.js boots up.

Also, and unfortunately, the size of the hard-coded pre-computed values in plain-text is closer to 200k. Compressed is 75k.

We can perhaps get in touch, also asking how the results compare when using a look-up table of 32x32 instead of 64x64, etc.

Can also play w/ the precision of the floats in the file, seeing how reducing precision affects quality

@bhouston
Contributor
bhouston commented Jun 29, 2016 edited

Interesting. For a while ThreeJS was < 100KB compressed. I think it is around 110KB compressed right now. I believe the tables are smooth and thus one can likely fit some polynomials to it via matlab: http://www.mathworks.com/help/matlab/ref/polyfit.html

Or one could approximate the table by piece-wise linear or cubic patches, again assuming it is smooth.

@abelnation
Contributor

The core concept and trick of the paper is that they are approximating the GGX BRDF as a product of a simple clamped cosine distribution with some linear transformation applied to it. They use the fact that it's a linear transformation to simplify the integral over a polygonal region.

The linear transformation applied depends on the roughness and the view angle. For any given (roughness, theta_v) pair, they represent the linear transformation as a matrix, which has 4 non-zero-or-one values, hence storing 4 (really, 5) float values in the texture for each (roughness, theta_v) pair. So what you're proposing is to come up w/ a fitted function of f(a, t) => (a, b, c, d, e), i.e. a function of two parameters that returns a vector or 5 values.

I'm open to ideas. What about loading the look-up table asynchronously, only when the feature is needed?

@abelnation
Contributor

@mrdoob can you provide a little more context on the link you just posted?

@WestLangley
Collaborator

@abelnation http://threejsworker.com/ is just our handy way of viewing/sharing PRs.

@abelnation
Contributor

gotcha. thanks

@mrdoob
Owner
mrdoob commented Jun 29, 2016

@WestLangley does this PR look good to you?

@bhouston
Contributor

This PR currently increases the size of the file "three.js" by 209K characters because it contains two large lookup tables:

https://github.com/abelnation/three.js/blob/c298ab2b2211e7de4940d88d06bd1d1c8b75e817/src/renderers/shaders/UniformsLib.js#L13

At minimum I would suggest that we move those tables into a file in "examples/js" that filles in those two variables. And when one tries to use the area light class in the renderer it checks if those variables are defined and if they are not it say it is dependent upon this extra file being included.

@mrdoob
Owner
mrdoob commented Jun 29, 2016

Oh, I missed that. Would base64ing those arrays help?

@abelnation
Contributor

No. Compressing the data still adds 80kb.

I'm exploring coming up w/ fitted polynomial based functions to estimate the lookup table. With this option, the idea would be to compute the look-up tables on the fly if/when the feature is needed.

The other option is to on-the-fly fetch the look-up tables as a separate file if/when the feature is needed. Does three.js have other areas where initialization is paused while certain cpu/network-intensive activities are performed?

@mrdoob
Owner
mrdoob commented Jun 29, 2016

I'm exploring coming up w/ fitted polynomial based functions to estimate the lookup table. With this option, the idea would be to compute the look-up tables on the fly if/when the feature is needed.

That sounds like the best option to me.

Does three.js have other areas where initialization is paused while certain cpu/network-intensive activities are performed?

Not that I know of.

@abelnation
Contributor
abelnation commented Jun 29, 2016 edited

Ok. FYI:

  • I just added updates to integrate the RectAreaLight with MeshStandardMaterial
  • I rebased on top of dev to clean up the commit history

Aside from how we fetch the pre-computed values, the rest of the PR is good to go for providing feedback.

Let me know if you guys have best practices for rebasing that I'm not following.

@bhouston
Contributor

@abelnation wrote:

The other option is to on-the-fly fetch the look-up tables as a separate file if/when the feature is needed.

The PMREM generator is dynamic and creates blurred cubemaps on demand. We are running into issues on some older (e.g. crap) mobile devices where this can take upwards of 5 seconds and it blocks devices leading to a very poor user experience. So we are looking to have the option to pre-calculated these.

I think that people can optionally include "examples/js/AreaLightTables.js" after "three.min.js" if they want to use area lights. That would be the easiest solution. We already do this pattern here:

https://github.com/mrdoob/three.js/blob/master/examples/js/postprocessing/DotScreenPass.js#L9

I think dynamic fetch isn't a great idea as you do not know what someone's deployment looks like and fetching else where is problematic because of customized ThreeJS versions and whatnot.

@abelnation
Contributor
abelnation commented Jun 29, 2016 edited

Prelim polynomial fitting results. For each of the 5 pre-computed values, trying to find a polynomial function to fit a 2d function to the data. Def will be interesting to see what kinds of artifacts this results (or doesn't result in) when plugged into the RectAreaLight impl.

Original data:
image

Current fitting:
image

@bhouston
Contributor

Damn, that is beautiful. What degree polynomials are you using? That might already give decent results.

There are other methods of approximation available if the polynomials require very high degree for good results, probably one that positions control points around the 2D grid and then does interpolation between them may also produce good results.

@abelnation
Contributor

most are 4, went up to 6 for graph (3). polynomials have the form

term_num = 0
for i in range(n+1):
    for j in range(n+1):
        result += c_term_num * x**i * y**j
@WestLangley
Collaborator

@WestLangley does this PR look good to you?

@mrdoob Sorry, I will continue to be unavailable for awhile... I will check it over as soon as I can. I have no problem merging if you want.

@thmasn
Contributor
thmasn commented Jun 30, 2016

cant wait for this

although i think it the reflection should be completely sharp if rougness is Zero.
just as it is here

@abelnation
Contributor

@thmasn currently, the demo example floor uses the phong material (which uses shininess instead of roughness). will look into whether roughness=0 results in totally sharp reflections for the MeshStandard Material

@abelnation
Contributor
abelnation commented Jun 30, 2016 edited

@bhouston better results from my tinkering, where polynomial order is optimized for best mean squared error. would love your input on alternate methods for fitting this surface for ltc_n = 2 & 3, whose distributions are characterized by a very sharp spike in the far corner of the distribution. poly_n represents the order of the 2d polynomials.

image

image

image

image

image

@abelnation
Contributor

One note:

The distributions with sharp spikes primarily exhibit the spikes in very narrow bands. For these spikey dist's, we could actually do, e.g. 3 different fittings for the 1 distribution, where each fitting is specific to different regions of the dist. Then, to compute the dist, you apply a mask to each region, to blend the regions together. I dunno, something I'll play with...

@WestLangley
Collaborator
WestLangley commented Jul 1, 2016 edited

@abelnation Would you be willing to show that your LTC approximation is correctly implemented for a given cosine-weighted GGX BRDF? Via a 3D plot, for example.

Assuming everything is correct, how sensitive is the computation of irradiance to approximations in the matrix elements, as you are doing here? How much energy is being gained or lost, for example?

@abelnation
Contributor

@WestLangley just to make sure I understand correctly, you are looking for a comparison between my implementation with the raw pre-computed matrix values from the paper vs. the work I'm doing trying to fit a function on top of that data?

In other words, are you asking me to measure the error between my first impl where the values are hard-coded into the source vs. if the values are computed on init via some fitted function?

OR

are you asking me to measure/validate whether the implementation based on linearly transformed cosines matches up to a real-world GGX BRDF (not approximated)?

@abelnation
Contributor

Also, FYI, I'm leaving on a trip for 10 days or so tomorrow, so I will probably be dropping off the map for a bit, but I intend to continue this work when I'm back.

@WestLangley
Collaborator
WestLangley commented Jul 1, 2016 edited

@abelnation

are you asking me to measure/validate whether the implementation based on linearly transformed cosines matches up to a real-world GGX BRDF (not approximated)?

Yes! That one. : - ) That the technique in the paper is implemented correctly in the code.

Also, FYI, I'm leaving on a trip for 10 days or so tomorrow

No problem, my availability is very limited for awhile, too... And, of course, many thanks for your considerable efforts on this!

@spidersharma03
Contributor

@abelnation Great work!

@WestLangley
Collaborator
WestLangley commented Jul 1, 2016 edited

@abelnation I could have made my request more clear.

Can you show that the technique in the paper is implemented correctly in your code? Can you quantify the error in the illumination calculation caused by the "abelnation" approximation?

How's that? : - )

@abelnation
Contributor
abelnation commented Jul 1, 2016 edited

@WestLangley

ok, so just to confirm, there are 4 different things being discussed in this PR:

  1. Rect area light calculations based on the actual GGX BRDF (this is too expensive in practice, as it requires a full integral over a rectangular domain).

  2. The paper's approach to approximating the GGX BRDF by fitting a linearly transformed cosine function to the real GGX BRDF. This approximation can be represented by 5 float values for each roughness / viewangle combination. This is the set of values I currently have hard-coded into this PR's implementation.

  3. My implementation of (2) in three.js. I'm not sure how to compare (2) and (3) as it requires me to implement (2), which is exactly what I did in (3) :P

  4. As storing the fitted float values requires 80kb of compressed data added to the size of the code base, I am proposing and tinkering with trying to enable us to "re-compute" the 80kb of data when three.js is initialized, so that we can keep source file size down. Doing so requires fitting some 3d function to each of the 5 values that (2) presents. In essence, this will be an approximation of (2), which is an approximation of (1).

Ok. All that said, your last comment makes it sound like you want me to find the error between (2) and (3). I'm not sure really how to do that, as I've effectively ported quite a bit of their code verbatim.

Your comment before that sounded like you want me to compare (4/3) and (1) (see below).

The other two things you could be asking are:

  • Compare the error between (4) and (3). This is easily done
  • Compare the error between (4/3) and (2). Not sure how to go about doing this.
  • Compare the error between (4/3) and (1). Probably doable with some mathematical software, actually performing the true integration over the rectangular light domain w/ the real GGX brdf function. TBH I'm a bit fresh on some of this stuff, so I don't think that would be a trivial amount of work.
@spidersharma03
Contributor

@abelnation, The brdf fitting procedure in that paper dosen't include the fresnel term. Any thoughts, or I am missing something?

@WestLangley
Collaborator

@abelnation Gee, sorry. I guess I am not asking my question in a clear enough fashion.

How can you demonstrate that you coded the algorithm in the paper correctly?

How much error, in units of irradiance, is introduced in using your polynomial approximation?

@abelnation
Contributor

How can you demonstrate that you coded the algorithm in the paper correctly?

I'm open to ideas there. One idea it to code an example that closely matches their sandbox setup, and show corresponding screenshots. But yeah, if anyone has ideas there, let me know.

How much error, in units of irradiance, is introduced in using your polynomial approximation?

I'll put some thought into how I can do this comparison. As mentioned above, this may be a non-trivial amount of work.

@abelnation
Contributor

@spidersharma03 as far as I understand, the fresnel term is built into the BRDF approximation that they present

@abelnation
Contributor

@bhouston @mrdoob

Ok. I'd like to propose a plan for concluding this PR.

  1. For now, treat RectAreaLight as an "experimental" feature. Do not include it's implementation in the default build of three.js, and instead require you include it as an extra when building.

  2. For now, leave the implementation as is WRT including the raw texture data in the src code. I think that coming up with a good solution for minimizing the payload for including that data is a tricky problem, and probably merits it's own PR + discussion

  3. For now, defer the verification work requested by @WestLangley, but treat that verification as a requirement to move RectAreaLight into the main, non-experimental three.js code base.

Thoughts? I worry about this PR dragging on and on, when I believe it is a very big step towards a solid RectAreaLight implementation.

@WestLangley
Collaborator

@abelnation I will gladly debug/verify your code if it is merged as a WIP. My time has been extremely limited, but I am interested in helping you here, and will do what I can.

@bhouston
Contributor

Please add this to the threejs repo somehow, like put the tables in examples/js or something an dleave the code in the main branch. This is good stuff.

@abelnation
Contributor

Ok, well then I will plan to update this PR to treat RectAreaLight as an extra. I think that makes more sense than hiding the LTC tables inside an example.

@abelnation
Contributor

@mrdoob @bhouston can someone clarify for me where the appropriate place would be for the LTC data? It appears to me that extras is compiled in to the main three.js build, which seems counter intuitive.

On another note, one issue with the current system of includes is that an "optional" package can only be added to the source file before or after the entire "common" package. It seems there may be some cases where including an optional feature would require place it's definitions in specific locations interleaved with the common files. Do you guys have thoughts on this?

@bhouston
Contributor

I'd just throw it into examples/js And make it clear in the code that it is required. We are switching hopefully to a ES6 module system with tree shaking so this will become moot in the near term, do not get caught up on it too much.

@abelnation
Contributor

ok, @bhouston i've moved the BRDF texture data to a file in examples. i also rebased on top of dev to make the PR mergeable again.

@abelnation abelnation changed the title from Fast RectAreaLight implementation using Linearly Transformed Cosines (Work in progress) to Fast RectAreaLight implementation using Linearly Transformed Cosines Jul 21, 2016
@spidersharma03
Contributor

@abelnation, I asked the authors about the fresnel term, and they confirmed that in the current github code, it is missing. You can see the GGX evaluate code to see that. They are going to update the code soon, with the fresnel back. But that's just for an update. Your work is Awesome!
I am attaching author's little note here which he sent me, on fresenel::
ltc_fresnel.pdf

@thmasn
Contributor
thmasn commented Oct 14, 2016

bump because id like to implement it in the editor, but it is currently not being mergable. is it dead?

@mrdoob
Owner
mrdoob commented Oct 15, 2016

Yeah, the modules change probably broke this...

@abelnation Could you try pulling from dev?

@abelnation
Contributor

Can try to take a look sometime. Would prefer to get a commitment from the maintainers that they intend to merge this code. This PR was blocked on @WestLangley, and it doesn't feel worth my time if it's ultimately going to continue to stagnate.

@WestLangley
Collaborator

@abelnation wrote:

This PR was blocked on @WestLangley

Blocked? I do not feel that statement is accurate. I wrote this:

@abelnation I will gladly debug/verify your code if it is merged as a WIP.

@abelnation
Contributor

@WestLangley, ah, my mistake. I assumed that was the reason this PR was not merged by the team. If that is the case, what are all the next steps to work towards merging this PR (aside from resolving conflicts)?

@bhouston
Contributor

The buck stops at @mrdoob so you should get his feedback. I like this PR as long as the tables are optional.

@EskelCz
EskelCz commented Oct 31, 2016

@mrdoob Can this please be revived? I would really love to use these lights.

@abelnation
Contributor

@EskelCz this PR is blocked on me, unless someone wants to put in the work of resolving the merge conflicts to get up to date with the latest changes. trying to find some time to get this done

@sam-g-steel
Contributor

@mrdoob @abelnation @EskelCz
I'm working on merging the code and submitting a PR that is up to date.
However, I ran into a problem with the build script.

> run-script build
> three@0.82.0 build ...\repos\three.js
> rollup -c

No name was provided for external module '' in options.globals – guessing ''

Process finished with exit code 0

Does anyone know what this is about?
I'm looking into it I suspect it's something simple related to rollup.

Note: I am a webpack guy

@sam-g-steel
Contributor

Update: JS is now building...
However, the shaders don't compile.
I expect to have more done tonight.

@sam-g-steel
Contributor

Ok, so I've got it working... All demos including the rect area lights are running on my laptop's GTX 960M but I'm having problems with git. I hope to have code checked in soon!

@sam-g-steel
Contributor
sam-g-steel commented Nov 2, 2016 edited

Ok, I have two branches that can be merged without conflicts...

  1. https://github.com/sam-g-steel/three.js/tree/abelnation-polygonal-light-shading-linear-transformed-cosines
  2. https://github.com/sam-g-steel/three.js/tree/abelnation-rect-area-light-with-ltc-approximation

I suspect that the better of the two options is no2. @abelnation is this correct?

There are a few GLSL warnings and bugs in the RectAreaLightHelper that I want to resolve before I submit a PR.

Note: These issues are probably due to the extreme merging that had to be done!

@tiborsaas

I'm rooting for you guys, this will be a killer feature in ThreeJS once it hits a release :)

@sam-g-steel
Contributor

Ok, here it is!
Abelnation RectAreaLight with ltc approximation #10041
No conflicts at present and all demos are working on my XPS 15 2016 & Moto X Pure 2015

@mrdoob mrdoob added a commit that referenced this pull request Nov 9, 2016
@sam-g-steel @mrdoob sam-g-steel + Abelnation RectAreaLight with ltc approximation (#10041)
* sketch of spherical distributions with linearly transformed cosine

* adding prelim example sketches for cosine dists

* makeSkew method added

* add polygon light sandbox example to repo for reference

* formatting

* notes files

* adding skeleton files for area point light

* debug directional light integrated into area light example page

* initial AreaLightHelper functional in example

* makeShape functions for Polygon and add as choices to example

* annotating TODO's with name. partial work on AreaLight shader components

* adding TODOs and placeholders for all places where AreaLight code needs to be added

* fix typo

* RectAreaLight shading works in preliminary fashion

* updates to example

* Preliminary RectAreaLight implementation (no shadows, no distance/decay)

* Integrate RectAreaLight with MeshStandardMaterial

* moving rectarealight brdf data to an example file.  rest of implementation left in place

* TubeBufferGeometry: Removed invisible char (#9943)

* Remove reference to THREE in IcosahedronGeometry.js (#9945)

Fix broken references to THREE namespace in geometries.

* Updated builds.

* Updated package.json.

* Resolved some issues from the first merge

* Added demo from #9234
Noticed that the code from @abelnation is not his latest...
more merging to come!!!

* Fixed issues from merge

* Fixed issues from merge...
webgl_lights_arealight improved
RectAreaLightHelper update bugs fixed

* Removing built js files that cause conflicts

* Use FileLoader.setMimeType() from MMDLoader (#9990)

* MMDPhysics improvement (#9989)

* MMDPhysics improvement

* Add property defined check

* Shoe physic bodies in mmd example by default.

* Updated builds.

* Improved documentation for constants / Materials (#9993)

* Improved documentation for Materials / Material (#9994)

* Added defaults to docs / perspectiveCamera (#10007)

* added constanst / animation (#10005)

* Fixed error in <head> for Docs / AnimationAction, AnimationClip, and AnimationMixer (#10004)

* Added default values for zoom, near and far properties of docs / orthographic camera (#10006)

* Improved documentation for Constants / Textures (#10001)

* Improved documentation for Materials / Material

* Moved Texture Combine Operations to constanst / materials

* updated Basic, Lambert and Phong .combine property to point to Material constant page

* Improved documentation for constants / textures

* Added Encoding constants to Textures constants page

* Ccdik solver optimization (#10010)

* Optimize CCDIKSolver

* Remove lines I should have not commit

* Remove lines I should have not committed

* added missing toJSON method (#10020)

* Added missing toJson method (#10019)

* added missing toJSON method (#10018)

* created documentation for VideoTexture (#10016)

* Created doc for CanvasTexture (#10015)

* Add CCDIKHelper (#9996)

* Add CCDIKHelper

* Clean up MMDPhysics.js

* Fix typo

* Update OBJLoader.html (#10009)

Spelling correction.

* Fix typo in comment (#10021)

* Improved documentation for docs / Texture (#10012)

* Improved documentation for docs / Texture

* Removed duplicate needsUpate

* Improved docs for Clock (#10008)

* Created new document page Constants / Renderer (#10002)

* Created constants / renderer

* renamed Renderer.html to WebGLRenderer.html

* Improved documentation for CompressedTexture (#10014)

* AudioContext: Added getContext() and setContext().

* Updated builds.

* Simplified AudioContext.

* Updated builds.

* BufferAttribute.onUpload() clean up.

* Renamed docs /constants / WebGLRenderer to Renderer (#10028)

* fixes #10026 (#10027)

* capture bufferAttribute.array properties at first upload (#9972)

* save typed array info in attribute properties

* use saved attribute properties

* remove unused variable

* Discard attribute typed arrays for buffered geometries that are not modified after initial rendering (#9512)

* add setDiscardBuffer method to BufferGeometry

* added discard support to BufferAttribute

* add mechanism for discard of BufferAttribute TypedArrays

* use more elegant method for creating dummy typed array.

* fix typo

* Update BufferGeometry.js

fix brain fade

* rework to use callbacks (phase 1)

* rework part 2

* remove build file

* support setting onUploadCallback from Geometry

* remove repeated calculation from renderer

* remove now redundant getter

* remove geoemtry interface

* document discard mechanism.

* merge fixes

* restore return.this

* drop unneeded call()

* rename discard() method to disposeArray()

* Improved documentation for WebGLRenderer (#10030)

* added missing methods

* Finished add methods

* redid changed to WebGLRenderer.html

* removed unused texture.sourceFile property (#10024)

* glTFLoader: Removed hack. See #10024.

* Updated builds.

* add link to project wiki in README.md (#9987)

* Added deprecated msg/fixed link (#10025)

* Created documentation for DepthTexture (#10017)

* Created documentation for DepthTexture

* pulled upstream

* added missing comma to docs/list.js

* Deprecated UniformsUtils. See #8016.

* Updated builds.

* MeshBasicMaterial: Add support for lightMap (#9975)

* Updated builds.
346f38c
@mrdoob mrdoob closed this Nov 9, 2016
@mrdoob
Owner
mrdoob commented Nov 9, 2016

🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment