- 14 11月, 2012 5 次提交
-
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
See #2623.
-
由 Mr.doob 提交于
Without CubeGeometry is a little bit easier to follow. Wasn't sure whether doing it like this or using a single material/texture with modified UVs per side. Also, I've had to comment out some code from GeometryUtils that asumed object2 to be a mesh.
-
由 alteredq 提交于
See #2628 and #2623
-
由 alteredq 提交于
Bumped scene format version to 3.2 Modified correspondingly SceneLoader, SceneExporter, Blender scene exporter and example scene files. See #2628
-
- 13 11月, 2012 3 次提交
-
-
由 alteredq 提交于
Testing the impact of normalization of transformed normals in vertex shaders (phong, normal, normalmap, skin simple). It seems the effects on performance are minimal: in several random examples it's either not measurable, or just a tiny bit worse. See #2613
-
由 alteredq 提交于
Fixed implications of new MeshFaceMaterial.materials at multiple places (Ray, Projector, ShadowMapPlugin, DepthPassPlugin). Thanks to @WestLangley for vigilance (see #2623).
-
由 alteredq 提交于
Patch to #2623
-
- 11 11月, 2012 9 次提交
-
-
由 alteredq 提交于
-
由 alteredq 提交于
I believe this is not needed anymore.
-
由 alteredq 提交于
-
由 alteredq 提交于
Also for the moment in depth pass skipping all ParticleSystems without custom depth material. Otherwise there are GL errors, need to create a proper generic depth material for particles.
-
由 alteredq 提交于
-
由 alteredq 提交于
-
由 alteredq 提交于
See discussion at https://github.com/alteredq/three.js/commit/5cb715520806a5afa1057a31a6777c2e454eeff0
-
由 alteredq 提交于
This is necessary for OpenGL where pow(0,0) is undefined and can be negative (in DirectX you just get zero), leading to negative light creating black areas artefacts. Fixes #1805 and #2615 (related already fixed #998).
-
由 alteredq 提交于
See discussion in #2613 Finally I just left it behind a flag. I was not able to get as good results for TextGeometry as with unweighted method and split materials for side and front faces. I wonder how I got that nice look as in screenshot I posted in the issue. It still does look better with weighted than unweighted but nowhere so close as in that screenshot. Either I did some mistake when testing before or there is some bug in implementation now.
-
- 10 11月, 2012 1 次提交
-
-
由 alteredq 提交于
See #2610
-
- 09 11月, 2012 7 次提交
-
-
由 alteredq 提交于
Small fix to #2610
-
由 WestLangley 提交于
-
由 alteredq 提交于
-
由 alteredq 提交于
Because that's what it is.
-
由 alteredq 提交于
Now it should look the same no matter where the object is located.
-
由 alteredq 提交于
In the process found some issues: - HemisphereLight shading is wrong for objects not in origin, it shouldn't depend on light position amplitude and object position in the scene - GL errors about uniforms thrown when all lights have "visible = false" - object dragging in the viewport sometimes hits invisible wall (I guess it's because of limited picking plane size?) - ArrowHelper doesn't seem to work for (0,-1,0) direction
-
由 WestLangley 提交于
-
- 08 11月, 2012 1 次提交
-
-
由 alteredq 提交于
Also fixed spotlights shading in Lambert material and light helpers init colors for light intensities > 1. Please disregard init scene lighting weirdness, this is just temporary, to be able to test light helpers.
-
- 07 11月, 2012 6 次提交
-
-
由 alteredq 提交于
-
由 alteredq 提交于
This is for PointLights. Also removed unused distance property from DirectionalLight class (at least I think so, I know WebGL materials don't use this and I couldn't find it used elsewhere).
-
由 Mr.doob 提交于
-
由 alteredq 提交于
Added rays also to DirectionalLightHelper. Refactored PointLightHelper and DirectionalLightHelper.
-
由 alteredq 提交于
Also added one PointLight to dummy starting scene to be able to test point lights (at least while there is no UI for adding lights). Changed multiple gizmos not to be affected by fog. Made DirectionalLightHelper constructor take sphere size as a parameter.
-
由 alteredq 提交于
Fixes #2600
-
- 06 11月, 2012 4 次提交
- 03 11月, 2012 1 次提交
-
-
由 alteredq 提交于
-
- 02 11月, 2012 3 次提交
-
-
由 alteredq 提交于
This makes it safer to compile shaders without maxLights cap. Only per vertex phong code path is sensitive to available number of varyings (together with shadow maps, but you would need to be pretty crazy to have enough shadowed lights to hit varying limits). Also like this phong material behaves more as expected for large polygons. Performance wise, for many use cases and systems it's actually similar or even faster.
-
由 Mr.doob 提交于
-
由 Mr.doob 提交于
-