Three.js: Селективное освещение

То, что я говорю, в основном имеет поле channel в THREE.Light и поле lightChannel в THREE.Mesh или что-то в этом роде. Если последнее значение равно нулю, то на него влияют все источники света. Если последнее не равно нулю, то это влияет только на световые каналы с таким же значением.

Или, может быть, его можно было бы добавить не к самой сетке, а к отдельным граням геометрии сетки.

Похоже, вы хотите использовать тени?

Что ж, я мог бы добиться чего-то подобного с помощью теней (и я уже пробовал), но это дает разные побочные эффекты, и я чувствую, что это хитрость, потому что мне не нужно освещать некоторые объекты, а затем отбрасывать на них тень. . Во-первых, я не должен их зажигать.

Мне нужно, чтобы конкретный источник света не влиял на один набор сеток, но влиял на другой набор.

Обычно я делаю это с помощью такой техники: Пример обсуждения :

glEnable(GL_LIGHT0);
//...
glEnable(GL_LIGHTn);

// Draw the walls to room 1
DrawWalls(room[0]);

// Draw the contents of room 1
DrawContents(room[0]);

glDisable(GL_LIGHT0);
//...
glDisable(GL_LIGHTn);

// Draw the walls to room 2
DrawWalls(room[1]);

// Draw the contents of room 2
DrawContents(room[1]);

Так что это похоже на другую особенность, чем просто тени. Или я что-то упускаю?

Да ... Думаю, это действительно может пригодиться. Не уверен, как должен выглядеть API для этого.

Возможно, самое простое решение может оказаться наиболее эффективным здесь:

1. Добавьте channel (или group ) к THREE.Light
2. Добавьте affectedByLightChannel (или affectedByLightGroup ) к THREE.Mesh (Или, может быть, даже к грани в геометрии)

Что вы думаете?

Может быть, «световой канал» слишком длинный и подойдет что-то вроде «световой канал», но я думаю, что это было бы удобно: просто номера каналов на источнике света и приемниках.

Как это:

    light = new THREE.PointLight(0xFFF7D6, 1.0, 15)
    light.channel = 123
    testScene.add(light)

    testScene = new THREE.Scene
    geometry = new THREE.BoxGeometry(2,2,2)
    material = new THREE.MeshLambertMaterial 
        color: 0xffffff

    cube = new THREE.Mesh(geometry, material)
    cube.lightChannel = 123
    testScene.add(cube)

Если lightChannel равно 0, то на него влияют все каналы. Если channel равно 0, это влияет на все сетки.

Таким образом, он был бы полностью обратно совместим с текущим поведением.

Это может быть слишком сложно понять ... Может быть, лучше что-то вроде этого:

cube.lightInfluences = [ light1, light2 ];

Мне кажется, это нормально.

Может быть, в некоторых случаях это немного сложнее использовать, но, очевидно, это легче понять.

А как насчет простого свойства целочисленной маски для сеток и источников света?

light = new THREE.PointLight(0xFFF7D6, 1.0, 15)
light.mask = 0xffffffff; // default mask
testScene.add(light);

cube = new THREE.Mesh(geometry, material)
cube.mask = 0xffffffff; // default
testScene.add(cube);

В этом случае объекты освещаются светом только в том случае, если логическое И их масок не равно нулю.
Это позволило бы на освещение воздействовать более чем одним каналом без дополнительных методов для объектов.

Значение маски по умолчанию 0xffffffff не повлияет на существующий код.

Что сказал @ satori99 .

Хотя я думаю, что mask вместо этого должно быть свойством Light и Mesh*Material . (Только те материалы, на которые распространяется свет.)

Кроме того, свойство можно также назвать lightMask , lightChannel или channel .

Проблема подхода канал / маска заключается в том, что пользователю необходимо понимать побитовые операции. Слишком интенсивно, если сравнивать с остальным API.

Что можно сделать с масками, чего нельзя сделать с использованием массива?

Я мог бы привести пример из задачи с двумя комнатами выше.

Суть использования канального подхода вместо подхода массива заключается в том, что простые операции, такие как «переместить источник света1 из комнаты 1 в комнату 2», становятся более сложными, если вы используете массивы.

Вместо того, чтобы просто установить

light1.channel = 2

(ранее было установлено 1)

вам нужно будет найти все объекты в комнате 1, у которых ранее был light1 в массиве lightInfluences, затем удалить свет из их массивов, а затем добавить его ко всем объектам в комнате 2.

Та же история с простой операцией вроде «переместить объект 1 из комнаты 1 в комнату 2». Вместо того, чтобы устанавливать его канал влияния от 1 до 2, вам нужно будет найти все источники света в этой комнате, затем удалить их из его массива влияния, затем найти все источники света во второй комнате и добавить их.

Дело не в том, что это невозможно, поэтому я сказал, что подход lightInfluences мне абсолютно подходит. Но материал канала был бы первым, что я бы реализовал выше для себя, просто чтобы сделать общие операции такими же простыми, как одно назначение.

Думаю, это нужно реализовать в виде маски. (Реализовано ли это на ЦП или ГП - вопрос для дальнейшего обсуждения.)

Мы можем показать на примерах, как это установить, и пользователи могут следовать шаблону.

Если вам кажется, что это все еще слишком сложно, мы можем создать для него THREE.Channels API.

light.channels = new THREE.Channels();
...
light.channels.clear();
light.channels.add( channel );
light.channels.remove( channel );
light.channels.all();

Те же методы для Mesh*Material .

Мне нравится этот API :)
Я вижу, как это работает для объектов и источников света, но как вы видите, как это работает для материалов?

Только материалы реагируют на свет. Я думаю, это должно быть свойство материала.

Я согласен в этом с @westlangley. Освещение зависит от материалов.

Та же история с простой операцией вроде «переместить объект 1 из комнаты 1 в комнату 2».

Что ж, это проблема. Channels не будет объектно-ориентированным.

Что ж, это проблема. Каналы не будут объектно-ориентированными.

Но почему? Это техническое ограничение?

Потому что это как бы сводит на нет всю эту идею. Потому что могут быть разные объекты, которые повторно используют один и тот же материал, но один из них должен быть освещен, а другой - нет.

Но почему? Это техническое ограничение?

Нет. Это потому, что объекты не реагируют на свет. Только материалы.

Потому что могут быть разные объекты, которые повторно используют один и тот же материал, но один из них должен быть освещен, а другой - нет.

Вы можете использовать один и тот же материал для всех объектов в сцене - просто clone материал для объектов, материал которых требует разных унифицированных значений. У всех должна быть только одна программа шейдера.

Думаю, это нужно реализовать в виде маски. (Реализовано ли это на ЦП или ГП - вопрос для дальнейшего обсуждения.)

Можно ли с этим легко справиться непосредственно в графическом процессоре?

Можно ли с этим легко справиться непосредственно в графическом процессоре?

Да, вам нужно будет передать дополнительную униформу channels для освещения и материалов.

Как насчет системы управления слоями? Я бы сгруппировал меши в слои и применил маски оттуда (может влиять на освещение, тени, видимость и т. Д.), Единство было бы хорошим примером?

Тени - тоже связанная тема. Думаю, должно быть что-то вроде выборочного отбрасывания теней. Например, "receiveShadowFrom = ..." (и список источников) вместо "receiveShadow = true".

Потому что, когда вы устанавливаете источники света, которые воздействуют только на определенную комнату (в моем примере), вам также сразу нужно, чтобы эти источники света отбрасывали тени только на объекты этой комнаты.

Атрибуты теней действительно должны быть на материалах, а не на объектах по тем же причинам, что и выше в этом потоке.

Атрибуты теней действительно должны быть на материалах, а не на объектах по тем же причинам, что и выше в этом потоке.

Да, в этом есть смысл!

Есть ли какие-либо планы по включению этой функции (например, запланированный целевой выпуск для первого черновика)?

Можно ли в качестве обходного пути выполнить большинство требований, создав отдельную сцену для каждой комнаты (и ее источников света)?

renderer.autoClear = false;
...
renderer.render( scene1, camera );
renderer.render( scene2, camera );

Хм, попробую такой подход!

Выборочное освещение / тени необходимо для будущих версий IMO.

БОЛЬШОЙ +9999 для этого, я бы хотел иметь возможность выбирать, отбрасывает ли материал тень от источника света A или от источника света B. У кого-нибудь есть решение, отличное от двух сцен? Из-за этого мне будет очень больно ...

чёрт возьми, как это до сих пор не реализовано? после +9999 от рохана)

Ха-ха, я предполагаю, что реализовать @tsone довольно сложно, не могли бы вы предоставить информацию об этом

как это сложно реализовать, если это просто униформа, которую они передают материалам. все, что им нужно сделать, это заменить глобальный список источников света на тот, который определен в материале, если он существует, где-то глубоко в рендерере webgl.

Вот простой JSFiddle, который тестирует реализацию Layers ветки Dev:
https://jsfiddle.net/Angrypickle/t8f7q3vo/4/
К сожалению, на данный момент, похоже, что он не работает должным образом. Или я что-то не так делаю?

да. Слои пока не работают со светом. Но они действительно работают с камерой / объектом! 😊

Роджер, сэр! Вот обновленный JSFiddle, который использует перекрывающиеся камеры для селективного освещения слоями:
https://jsfiddle.net/Angrypickle/t4a1eusL/
Кажется, он правильно работает на настольных компьютерах и мобильных устройствах. Кто-нибудь видит в таком подходе что-нибудь принципиально плохое? По крайней мере, до тех пор, пока свет не будет привязан к функциональности слоев?

Кто-нибудь видит в таком подходе что-нибудь принципиально плохое?

конечно плохо. вместо того, чтобы использовать одну камеру для навигации по сцене, люди теперь должны будут делать что-то camera1.add( camera2 ); Я имею в виду, что это WTF, когда я смотрю на это. Как, например? камера в моей камере? что, если у меня есть десятки комнат, которые нужно отдельно освещать? сколько камер мне нужно? и слои ... не было никаких слоев вчера, правда, и теперь я должен узнать о них.

разглагольствовать, чтобы не сказать, что у меня есть идеальное решение для этого. например, alternativa3d люди обычно помещали огни на то, что было в ограничивающих прямоугольниках света. у этого было преимущество настройки «почти 0» для конечных пользователей, но оно разваливалось, когда граница между источниками света должна была быть под углом. но все же, если бы мне пришлось решать эту проблему в реальном проекте прямо сейчас, я бы, скорее всего, решил очистить использованные стандартные материалы в ShaderMaterial-s и передать туда источники света, которые я хочу вручную.

Слои @makc на самом деле очень простые (и мощные)!
Подход @Zob1 определенно неправильный. Надеюсь, скоро слои будут работать со светом.

Ребята, просто чтобы убедиться, что я правильно слежу; допустим, у меня есть одна сцена и «основной» источник света. Возможно ли с помощью этой техники, чтобы определенные материалы игнорировали этот основной источник света, а также отбрасывали тени от другого источника света?

Что ж, для этого нам также нужно добавить поддержку слоев к материалам.

Что мы можем сделать на данный момент, так это показать / скрыть объекты с камеры:

Допустим, вы делаете игру и в редакторе используете сферы для отображения коллайдеров. Эти сферы могут быть установлены на уровень 1, в редакторе камеры могут быть включены слои 0 и 1, но игровая камера может быть установлена ​​на уровень 0. Таким образом, в вашем редакторе вы увидите все манекены, но в игре они ' он ушел.

Я думаю, что это будет иметь больше смысла, когда я добавлю функции в сам редактор. Вероятно, нам тоже стоит привести несколько примеров.

Правильно! В общем, я хочу, чтобы у меня были 2D-персонажи в моем мире Three JS. Этим персонажам нужны «точечные» тени, чтобы они выглядели как часть окружающей среды. В настоящее время я добиваюсь этого, используя геометрию прозрачного черного круга, размещенную у их ног, и некоторые довольно хитрые вещи, чтобы заставить его работать под углами. Даже в этом случае он не работает на сложных поверхностях.

Моя первоначальная идея заключалась в том, чтобы разместить невидимые геометрические фигуры круга в виде «ореолов» над каждым персонажем и создать свет, направленный прямо вниз, покрывающий всю сцену. Эти ореолы отбрасывали бы только тени от этого источника света, в то время как все остальное в сцене отбрасывало бы тени от «основного» источника света.

Думаю, чтобы эта идея сработала, нам нужны слои, верно?

Эти ореолы отбрасывали бы только тени от этого источника света, в то время как все остальное в сцене отбрасывало бы тени от «основного» источника света.

Раньше у нас была опция shadowOnly , но она была удалена.

FWIW, есть такой подход к созданию теней ...

Ах, но shadowOnly на самом деле не сработает, потому что тогда ореолы будут отбрасывать тени от обоих источников света, я хочу, чтобы они отбрасывали тени только от одного.

Я проверю этот пример по телефону прямо сейчас, но он выглядит многообещающим.

Редактировать Хм, но если эта сфера изменила свое положение в сцене и сетка земли имела разную высоту, будет ли ее тень правильно совпадать с нормалями поверхности земли?

Неа...

Да так и думал. Нужны слои! Хе-хе

Привет @ rohan-deshpande,

Да, для вашего варианта использования вам понадобятся какие-то слои. Некоторое время назад я реализовал функцию теневой сетки. Они предназначались для использования в сценах с плоским полом или землей, потому что они представляют собой одноплоскостные тени. Однако, если вам когда-либо понадобятся быстрые, дешевые (но правильные) одноплоскостные тени, их сложно превзойти с точки зрения производительности. Я добавил их потому, что даже для простых демонстрационных сцен карты теней значительно снизили частоту кадров. С другой стороны, Shadowmeshes работают быстро даже на моем телефоне.

Вы можете проверить мою игру, в которой они используются, здесь:
https://github.com/erichlof/3dLightCycles

Я дважды визуализирую сцену через 2 разных окна просмотра, и все игровые объекты (циклы и стены тропинок) имеют правильные тени. На моем смартфоне он работает гладко, как шелк, что было бы невозможно с картами теней для рендеринга двух сцен в каждом кадре.

+1 вот для слоев в будущем :)

Игра @erichlof выглядит и отлично работает на iPhone6, чувак.

Хорошо, я подожду слоев. До тех пор моего хакерского решения должно хватить.

Привет, ребята
Эта штука реализована?
http://stackoverflow.com/questions/33689781/casting-shadows-based-on-a-specific-light?noredirect=1#comment55153706_33689781

Нет, это еще не реализовано. Вам придется подождать слоев или попробовать одно из решений, перечисленных в ITT (например, отдельные сцены).

+99999 снова

Это определенно было бы очень полезно. И теперь у нас есть рабочие слои, и, похоже, это то, что сдерживало это. Итак, вот дружеская шишка. ;-)

@manthrax проверь это!

+99999 снова

Я бы с радостью за это. У меня есть ситуация, когда каждый аватар освещается только ближайшим источником света, и я могу включить тысячи источников света в сцену, было бы неплохо указать один источник света для каждого аватара.

Привет!
Мне понадобится эта функция, и я подумал о ее реализации, так как думаю, что нашел, где это можно сделать ( initMaterial в WebGLRenderer ), и это должно быть довольно просто, используя существующие слои.

Я подумываю создать битовую маску для конкретного света (как объект Layers ), чтобы выбрать, на какие слои влияет конкретный объект света (независимо от слоя собственного объекта источника света), а затем фильтровать источники света / карты теней, которые задаются как униформы для каждого объекта в процитированной выше функции.

Было бы это актуально?

Я попробую это сделать и отправлю запрос на перенос, как только получу это, если до этого вы не перенаправите меня на какой-либо другой метод.

ОБНОВИТЬ:

https://github.com/tiesselune/three.js/tree/selective-lighting

Я кое-что получаю. Не уверен, как это может повлиять на производительность или как оптимизировать мой код для производительности, но он работает на нескольких тестах, которые я провел. Послойное освещение! Ура!

Тем не менее, мне все еще нужно протестировать еще несколько и сделать соответствующий пример перед отправкой запроса на перенос.

ОБНОВИТЬ:

Я провел еще несколько тестов, и наличие одного и того же материала на двух объектах, которые находятся на разных слоях (и имеют разные настройки освещения), заставляет средство визуализации постоянно обновлять материал (через needsUpdate ), поскольку настройки освещения о материальных изменениях между двумя объектами, что раньше было невозможно. Это означает огромное падение производительности и визуальные странности (поскольку последняя загрузка материала выигрывает во время рендеринга)

Конечно, этого можно избежать, создав новый экземпляр материала вместо использования одного и того же для двух объектов с разными настройками освещения. Но я сомневаюсь, что клонирование его для пользователя - хорошая идея, поскольку это будет означать просмотр исходного материала на предмет изменений, чтобы отразить их на клоне.

Вот два решения, которые я мог бы использовать:

1. Я мог бы просто отобразить предупреждение, когда два объекта на разных слоях с разными настройками освещения используют один и тот же материал, чтобы пользователь мог сам создавать и управлять новым материалом клона.

2. Я мог бы добавить слои на уровне материала вместо уровня объекта (и создать систему параллельных слоев для источников света), чтобы было обязательно использовать разные материалы для достижения разных настроек освещения. Это будет означать, что будет существующая система слоев для видимости (для объектов и камер) и другая для освещения (для материалов и источников света).

Что вы думаете, ребята?

Я как раз думал об этом, когда увидел ваш комментарий. Я думаю, что отображение предупреждения бесполезно, так как многие люди, вероятно, его не увидят. Из этих двух я определенно предпочитаю устанавливать световые слои на материале, а не на объекте. Это немного нелогично, но все же имеет смысл.

Просто чтобы уточнить, когда установлен needsUpdate , в этом случае он просто пересчитывает единые значения, не так ли? Не нужно повторно компилировать шейдер, потому что все шейдеры должны быть кэшированы. Какого рода успехи в производительности вы наблюдаете? Вы использовали профилировщик, чтобы увидеть, где именно происходят дополнительные вычисления?

Кстати, filterAmbiantLights должно быть filterAmbientLights .

Вы правы насчет орфографической ошибки. На самом деле я написал все с помощью "ambiant", прежде чем заметил, что это неправильно, и забыл об одном случае. 😇

Думаю, тогда я перенесу информацию о слое в материал. Это кажется более актуальным и согласуется с тем, как это работает.

Падение производительности произошло (и до сих пор происходит) из-за того, что initMaterial (а затем acquireProgram и getShaderParameter что по какой-то причине очень медленно) вызывается каждый кадр несколько раз, потому что lightHash каждый раз будет отличаться, установив material.needsUpdate на true .

Кстати, я использую инструменты профилирования Chrome. (Временные шкалы и профайлер).

Меня это устраивает, но я не понимаю, почему acquireProgram должен работать все время. Если количество каждого типа света добавляется к параметрам программы, то не следует ли каждый раз заново компилировать шейдер?

Я тоже этого не понимаю;

Вот стек вызовов (в каждом кадре) и следующая за этим ужасная утечка памяти, если вы знакомы с ними, это может помочь мне понять, что идет не так. Похоже, он создает новые WebGLProgram s каждый кадр ...

Может быть, это может быть replaceLightNums который обновляет код вершинного / фрагментного шейдера во время создания WebGLProgram, вызывая его перекомпиляцию, или учитывая, что это другой шейдер ...?

РЕДАКТИРОВАТЬ: В любом случае использование слоев на уровне материала решает проблему, как и ожидалось. У меня просто где-то есть утечка памяти, которую я должен исследовать, но в остальном она выглядит неплохо.

Вероятно, неплохо понять, почему это происходит, просто для того, чтобы убедиться, что вы полностью понимаете код и не вносите какую-либо новую ошибку. Можете ли вы пройти через это, чтобы понять, почему код шейдера меняется каждый кадр?

Я не знаю WebGLPrograms достаточно хорошо, чтобы сказать, что происходит, но похоже, что он должен кэшировать эти шейдеры за вас.

На самом деле это довольно просто:

• чтобы знать, вызывать ли acquireProgram , initMaterial получает "код" шейдера из кеша (фактически, это скорее хэш, построенный в getProgramCode ) и сравнивает это к "коду" программы текущего материала.
• Поскольку эта функция создает «код» из параметров, включая количество каждого типа света, который фильтруется и хотя и различается между объектами, код может быть разным для одного и того же материала (так сказать, одной и той же программы) от объекта к объекту. разное.
• Поскольку этот процесс повторяется для каждого объекта, «код» изменяется несколько раз за кадр, заставляя его перекомпилировать столько раз за один кадр: что вызывает падение производительности.
• Тем не менее, поскольку несколько объектов имеют один и тот же материал, и, следовательно, одна и та же программа, последний объект, прошедший итерацию, наложил свои параметры на программу, что привело к тому, что оба объекта были освещены с одной и той же настройкой освещения, но не обязательно с одинаковыми теневыми картами (что может быть вычислен для объектов в другом порядке, но страдает той же проблемой «побеждает последний объект»), вызывая мои визуальные странности.

Теперь все работает так, как ожидалось (поскольку каждый объект с разными настройками освещения имеет разный материал и другую программу), за исключением оптимизации памяти, которую я мог бы сделать с моими собственными хэшами освещения, чем я собираюсь заняться в ближайшее время.

Могло бы быть некоторое улучшение, если бы световые числа были переменными, так что каждый материал был бы просто экземплярами одной и той же программы, но поскольку эти числа вставлены в код шейдера (в replaceLightNums ), это кажется несовместимым с текущим положением вещей. есть (и их оптимизация).

Надеюсь, объяснение было достаточно понятным

Интересно, можем ли мы передать маску слоя шейдеру (одна форма на объект и еще одна на источник света). Тогда мы могли бы добавить сюда что-то вроде этого .

Что-то типа...

for ( int i = 0; i < NUM_POINT_LIGHTS; i ++ ) {

    pointLight = pointLights[ i ];
    pointLight.distance *= float( object.mask & pointlight.mask > 0.0 );

    ...

}

Я не думаю, что мы можем выполнять побитовые операции в glsl ...

Да, похоже, что побитовые операции начинаются в GLSL 1.30, а стандартный WebGL использует 1.00. 😕

Привет, @mrdoob и @tiesselune!

Chrome 56 и Firefox 51 только что приземлились, что означает, что WebGL 2.0 включен по умолчанию (WebGL2 следует спецификации OpenGL ES 3.0). Это означает, что теперь доступны битовые операции (и другие интересные вещи, например, 3D-текстуры). Я не знаю, медленно ли Three готовился к переходу на WebGL 2.0, но я внес несколько обязательных изменений в свою копию three84.js и включил WebGL 2.0, а также немного поработал в шейдере, чтобы убедиться, что он сработало, и оно сработало!
https://developers.google.com/web/updates/2017/01/nic56
https://developer.mozilla.org/en-US/Firefox/Releases/51

Просто хотел, чтобы вы знали. +1 за идею маскировки :-)

Привет @erichlof ! Это отличная новость для WebGL2; это означает, что средство визуализации WebGL2, вероятно, сможет более эффективно решать проблемы маскировки.

В любом случае, учитывая очень ограниченное использование браузеров, поддерживающих WebGL2 , я не думаю, что мы можем отказаться от усилий, направленных на то, чтобы заставить его работать в WebGL 1: потребовалось много времени, чтобы почти все браузеры могли запускать приложения WebGL, так что это, вероятно, немного дольше, пока WebGL 2 не станет действительно широко используемым ... 😕 Но спасибо за подсказку!

Привет еще раз!

Новое обновление: я сделал то, что считал необходимым для управления памятью, но сборка мусора из кучи JS, похоже, имеет прямое отношение к конфигурации моего программного обеспечения (запуск программ, открытые вкладки, расширения) во время запуска профилей. Может ли кто-нибудь с немного большим опытом подтвердить, что мой код не так сильно требует памяти по сравнению с текущей версией threejs?

Во всяком случае, я привел пример в

Вот скриншот:

Здесь должна быть возможность просмотреть пример в реальном времени:

https://rawgit.com/tiesselune/three.js/selective-lighting/examples/webgl_lights_selective_lights.html

Я получаю сообщение об ошибке:

Uncaught TypeError: Cannot read property 'set' of undefined
    at init (webgl_lights_selective_lights.html:117)
    at webgl_lights_selective_lights.html:67

@looeee : вам нужно будет запустить npm run build-uglify на локальном хосте. Я добровольно не включал сборки в свои коммиты в целях слияния ...

Или я должен?

РЕДАКТИРОВАТЬ: вот рабочая ссылка на другую ветку для тестовых целей: https://rawgit.com/tiesselune/three.js/selective-lights-test/examples/webgl_lights_selective_lights.html

Привет, +999999 от меня. Это должно быть реализовано (по крайней мере, с THREE.Layers )

$$('.comment-body').reduce((acc, el) => {
  let mat = el.textContent.match(/\+(\d+)/)
  let num = +(mat && mat[1] || 0)
  return acc + num
}, 0)
>> 1219997

🤔

@mrdoob он подсчитал + Ns в этой ветке

кстати, +14570 для селективного освещения

Это будет невероятно хорошо для точной настройки того, как работает освещение в более высокой абстракции.

Например, в следующем пером я хотел бы, чтобы освещение работало одним способом для элементов DOM по сравнению с другим способом для сферы, чтобы освещение было более реалистичным:

https://codepen.io/trusktr/pen/RjzKJx

Определенные эффекты, похожие на точечный источник света, могут быть достигнуты путем объединения двух или более источников света, которые выборочно воздействуют только на определенные элементы.

Например, в моем предыдущем примере я могу увеличить интенсивность света, чтобы получить красивую тень на «элементе DOM», но тогда сфера будет выглядеть слишком блестящей и яркой. Если бы у меня был более тусклый свет для сферы и более яркий свет для «элемента DOM», тогда я мог бы добиться чего-то более реалистичного таким образом, когда зрителю казалось бы, что есть только один источник света. Затем подобные вещи можно абстрагировать в высокоуровневом API, который создает впечатление, будто существует только один источник света, которым управляют, когда за сценой фактически задействованы два источника света Three.js.

@WestLangley

Можно ли в качестве обходного пути выполнить большинство требований, создав отдельную сцену для каждой комнаты (и ее источников света)?

У вас есть ссылка на такой пример? Может ли это иметь другие неожиданные эффекты рендеринга на результат?

другие неожиданные эффекты рендеринга на результат?

порядок рендеринга прозрачных объектов, например - прозрачные объекты в сцене 1 будут рендериться перед непрозрачными объектами в сцене 2.

У вас есть ссылка на такой пример?

вот я сделал его специально для вас: https://jsfiddle.net/f2Lommf5/524/

порядок рендеринга прозрачных объектов, например - прозрачные объекты в сцене 1 будут рендериться перед непрозрачными объектами в сцене 2.

Вот о чем я думал; это делает обходной путь только для очень ограниченного числа случаев. С нетерпением жду настоящего решения!

Что ж, вы можете возразить, что проблема может возникнуть только в том случае, если вы сможете видеть непрозрачные объекты сцены2 из сцены1 через указанные прозрачные объекты. но если это так, свет тоже должен проходить сквозь них, и не было бы причин для начала разделять сцены. но я согласен, что такой аргумент не очень убедителен.

@makc Вот пример проблемы, которую я пытаюсь решить:

https://discourse.threejs.org/t/how-to-make-shadows-darker-on-transparent-objects/1389

Думаю, в этом действительно поможет селективное освещение.

@trusktr Я думаю, вы можете решить эту проблему, изменив теневой материал mrdoob. он просто показывает черно-белую текстуру тени, и вы можете сделать ее прозрачной по мере необходимости.

Маски в PlayCanvas кажутся очень простыми в использовании для выборочного освещения: https://forum.playcanvas.com/t/set- sure-object-to-not-receive-light/785

мы можем объединить это? Я думаю, что проблемы с тенями возникли из-за того, что шейдер Ламберта не имеет ничего общего с изменением кода. @tiesselune

@ErikBehar Я действительно искал чем заняться сегодня днем, я собираюсь попробовать обновить код до последней версии threejs и, может быть, отправить запрос на перенос? Мне действительно было приятно знать, что я внес реальный вклад в такой большой проект. (И хорошо иметь подтверждение, что эта ошибка не имеет ничего общего с моими изменениями)

РЕДАКТИРОВАТЬ: только что обнаружил, что эта часть кода сильно изменилась. Думаю, понадобится немного времени, поскольку состояния, которые я использовал ранее, переместились из WebGLRenderer в WebGLLights.

@tiesselune Мне как бы нужно было https://github.com/ErikBehar/three.js/tree/selectiveLights

Я могу устроить пиар, если хотите? @mrdoob

@ErikBehar Ну, похоже, я к чему стремился, но у меня не было времени на это полностью. Я думаю, что я бы переместил функции фильтрации / хеширования из WebGLRenderer и добавил их в объект состояния WebGLLights. Я чувствую, что они принадлежат этому сейчас, поскольку система слоев является частью состояния, а не частью модуля рендеринга.

@ErikBehar, пиар было бы здорово!

@tiesselune Я подумаю о его перемещении, как вы предлагаете, или не стесняйтесь продвигать PR на мою вилку lol =], и я скоро опубликую PR

Какой статус по этому поводу? Я слил код r94dev из @ErikBehar в r94, затем слил с ним r97, только пара очень простых конфликтов (смена версии, несколько переменных для выборочного освещения и создание хэша в рендерерах / WebGLRenderer.js; я бы будьте счастливы поставить PR. @tiesselune, если вы можете дать мне какое-то представление о том, куда вы намеревались перейти в состояние избирательного освещения, я был бы счастлив переместить его, протестировать и поставить PR.

РЕДАКТИРОВАТЬ:
Немного позже: я вижу, что теперь нужно немного поработать, чтобы работать с новым световым хешем.

@VaelynPhi Я бы подумал, что, независимо от того, готовы ли они принять код @ErikBehar или нет, неплохо было бы отправить PR, просто чтобы заменить устаревший, на случай, если другие люди захотят этого, например, вы сами сделал

Извините, что бросил мяч в этих ребят = / ... @VaelynPhi, вы можете опубликовать свою вилку / ветку?

Не беспокойся; Я понимаю, что занят. Увы, я не смог получить даже ту ветку, с которой вы работали, @ErikBehar; Я решил прочитать код, чтобы попытаться разбить его, чтобы я мог переместить состояние в соответствующее место и, надеюсь, исправить любые ошибки. Мне еще предстоит добраться до рабочего состояния порта даже на v94. Возможно, я смогу очистить его и поставить PR, чтобы обновить его, как предлагает @makc . Дай мне немного; Я очень занят. :) По крайней мере, это может помочь выделить изменения, которые необходимо внести, чтобы включить избирательное освещение в последнюю версию.

добавлен PR на основе:
https://github.com/ErikBehar/three.js/commit/ac0499b70b82bc7bb780100a8372fcdf318d1424#diff -5e43a0b5002eb2c419def3baf67d4e67
автор: @ErikBehar
может кто-нибудь протянуть руку с обзором и примером?

https://github.com/mrdoob/three.js/pull/15223

Привет, ребята, какой статус у этого? @tiesselune @ErikBehar Могу я вам чем-нибудь помочь? Было бы неплохо реализовать его наконец через 4 года 😄💯

@flyrell Я думаю, что мы могли бы закрыть эту проблему, потому что, похоже, это ближе к завершению в # 15223, может быть?