Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Куда лучше по дизайну засунуть тень?
SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

засунуть в объект, на который падает тень. он должен узнать знать про лампу и объекты на пути света.

Здравствуйте, neFormal, Вы писали:

F>засунуть в объект, на который падает тень. он должен узнать знать про лампу и объекты на пути света.

Слишком много перекрестных пропихиваний линков. Можно конечно тупо всем объектам кидать указатель на сцену, а сцена уж все знает. Но как-то не красиво. Мож покрасивей можно?

Здравствуйте, neFormal, Вы писали:

F>засунуть в объект, на который падает тень. он должен узнать знать про лампу и объекты на пути света.

Может быть несколько объектов, принимающих тень от одного. И наоборот, на один объект могут кастить тени несколько других объектов. А ещё объект может кастить тень сам на себя, если он невыпуклый.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

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

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

А оно здесь надо ооп? Вообще по идее это не тень отрисовывается, а третий объект освещенный лампой.

Здравствуйте, Stanislav V. Zudin, Вы писали:

SVZ>В сцену (либо в специально обученный для этого объект), которая знает и про лампу, и про объект.

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

Здравствуйте, SergeyOsipov, Вы писали:

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

Зачем тебе нестандартное?

В общем случае источники света, объекты кастящие тень и объекты принимающие тень могут двигаться от кадра к кадру. Если у тебя каждый объект будет содержать коллекции всех источников света, всех объектов которые кастят на него тень, и/или всех объектов которые принимают от него тень, то в каждом кадре придётся обновлять эти коллекции.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
Всегда приятно слышать про объекты, которые рисуются, записываются в БД, про работа.Выполняйся(), банковскийСчет.Пополняйся(), пиво.Пейся(), земля.Копайся().

SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.
Немного имел дело с 3D в 2000-х. Мне кажется, что в задаче отрисовки тени вопросы о том, куда ее засунуть — не в первом десятке актуальности. Вообще не помню, что бы в 3D пакетах в сценах присутствовали объекты "тень" как таковые.

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.
С точки зрения букварного ООП, где тень — наследник объекта сцены, все как раз красиво. Т.е. если задача состоит в том, что бы сделать красивый ООП, тут вряд ли одно решение будет чем-то лучше другого. Но если ее все-таки надо нарисовать, то предлагаю от ООП дизайна перейти к методам.

Вообще вопрос из категории "кто будет рисовать дырку от бублика?, бублик, или то, что через него видно?".

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

С точки зрения красоты ООП у тебя есть сцена с несколькими источниками света.
Сцена знает и про лампу и про предмет на пути света и про предмет, на который падает свет.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system

Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

Здравствуйте, SergeyOsipov, Вы писали:

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

Нет там никакого ООП и не нужно оно там. Всё правильно пишут про сцену. Лампа и объект — это данные, нечто пассивное, их обрабатывает сцена.

Здравствуйте, SergeyOsipov, Вы писали:

F>>засунуть в объект, на который падает тень. он должен узнать знать про лампу и объекты на пути света.
SO>Слишком много перекрестных пропихиваний линков. Можно конечно тупо всем объектам кидать указатель на сцену, а сцена уж все знает. Но как-то не красиво. Мож покрасивей можно?

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

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

Здравствуйте, Qbit86, Вы писали:

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

поэтому каждый объект сам смотрит, кем он закрыт от света

Q>И наоборот, на один объект могут кастить тени несколько других объектов.

каждый объект находит все закрывающие его от источников света объекты

Q>А ещё объект может кастить тень сам на себя, если он невыпуклый.

с этим уже сложнее и тут работа передаётся точкам

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются.

Они не отрисовываются. Уж лампа-то (в смысле источника света) точно.

В принципе не возможно "отрисовать" какой-то объект. Можно только вычислить отражаемый свет, который исходит в частности и от этого объекта.

SO>А еще есть тень.

А тени нет.
Есть отраженный или не очень свет.

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

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

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

Здравствуйте, Vladek, Вы писали:

V>В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
V>Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

Entity-Component-System это конкретный подход, можно сказать архитектурный паттерн и он нисколько не противоречит ООП.

ООП нужно не для наследования-инкапсуляции-полиморфизма, а для управления сложностью решения. Т.е. структурирование решения.
Как только ты решил задачу, её нужно перевести в код. Вот здесь и начинает работать ООП. А Entity-Component-System это уже конкретный вариант дизайна.

Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

Отсюда ясно, что привязаны методы к самому объекту или не привязаны это для ООП дело десятое, как ни странно. То есть, takeDamege(entity) и entity.takeDamege() абсолютно эквивалентны.

I>Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

I>Отсюда ясно, что привязаны методы к самому объекту или не привязаны это для ООП дело десятое, как ни странно. То есть, takeDamege(entity) и entity.takeDamege() абсолютно эквивалентны.

По всему остальному да, а вот по примеру -- нет (или переубедите, пожалуйста)
Для меня ООП это в основном не об инстансов объектов и о том, как они обмениваются, а о том, что "код рядом с данным", т.е. на самом деле "данных" нет, это все "инкапсулировано".
И вот тут между takeDamege(entity) и entity.takeDamege() разница приципиальная. Я не хочу сказать, что takeDamege(entity) это плохо, просто разница есть, и если в моей софтине "принимать повреждения" -- это "в природе" самого объекта (а не просто частный сценарий взаиможействия с ним), то я предпочту entity.takeDamege()

Здравствуйте, ylem, Вы писали:

I>>Отсюда ясно, что привязаны методы к самому объекту или не привязаны это для ООП дело десятое, как ни странно. То есть, takeDamege(entity) и entity.takeDamege() абсолютно эквивалентны.
Y>По всему остальному да, а вот по примеру -- нет (или переубедите, пожалуйста)
Y>Для меня ООП это в основном не об инстансов объектов и о том, как они обмениваются, а о том, что "код рядом с данным", т.е. на самом деле "данных" нет, это все "инкапсулировано".
Y>И вот тут между takeDamege(entity) и entity.takeDamege() разница приципиальная. Я не хочу сказать, что takeDamege(entity) это плохо, просто разница есть, и если в моей софтине "принимать повреждения" -- это "в природе" самого объекта (а не просто частный сценарий взаиможействия с ним), то я предпочту entity.takeDamege()

а если "в природе" самого объекта есть возможность изменять "здоровье", то ф-ция takeDamage(entity) будет делать entity.decreaseHp(n), а ф-ция heal(entity) будет делать entity.increaseHp(n)

F>а если "в природе" самого объекта есть возможность изменять "здоровье", то ф-ция takeDamage(entity) будет делать entity.decreaseHp(n), а ф-ция heal(entity) будет делать entity.increaseHp(n)

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

Здравствуйте, Ikemefula, Вы писали:

I>Здравствуйте, Vladek, Вы писали:

V>>В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
V>>Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

I> Entity-Component-System это конкретный подход, можно сказать архитектурный паттерн и он нисколько не противоречит ООП.

I>ООП нужно не для наследования-инкапсуляции-полиморфизма, а для управления сложностью решения. Т.е. структурирование решения.
I>Как только ты решил задачу, её нужно перевести в код. Вот здесь и начинает работать ООП. А Entity-Component-System это уже конкретный вариант дизайна.

I>Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

Это реализация игровой бизнес-логики, а мы про отрисовку говорим.

Здравствуйте, ylem, Вы писали:

F>>а если "в природе" самого объекта есть возможность изменять "здоровье", то ф-ция takeDamage(entity) будет делать entity.decreaseHp(n), а ф-ция heal(entity) будет делать entity.increaseHp(n)
Y>И опять же, я бы предпочел не менять здоровье снаружи так явно, потому что, например, у каких-нибудь десептиконов вообще нет здоровья в обычном понимании или кого-нибудь лечи-нелечи, все бестолку.

это уже зависит от подхода.
ничто не мешает сделать пустую реализацию метода. а если там ещё и entity component system с HealthComponent, то только inc/dec и останутся.

F>ничто не мешает сделать пустую реализацию метода. а если там ещё и entity component system с HealthComponent, то только inc/dec и останутся.

Все-таки пошел читать про ECS. Спасибо.

Здравствуйте, Qulac, Вы писали:

V>>>В геймдеве свои специфические подходы: https://en.wikipedia.org/wiki/Entity%E2%80%93component%E2%80%93system
V>>>Там ООП не на первом месте, главное 60 раз и больше за секунду всё отработать (и если надо — тени отключить).

I>> Entity-Component-System это конкретный подход, можно сказать архитектурный паттерн и он нисколько не противоречит ООП.

I>>ООП нужно не для наследования-инкапсуляции-полиморфизма, а для управления сложностью решения. Т.е. структурирование решения.
I>>Как только ты решил задачу, её нужно перевести в код. Вот здесь и начинает работать ООП. А Entity-Component-System это уже конкретный вариант дизайна.

I>>Собственно именно в геймдеве прижилось чистейшее ООП — объекты состоят из объектов, взаимодействуют с другими объектами посредством сообщений и тд. Частный случай взаимодействия — управление, так же делается посредством сообщений.

Q>Это реализация игровой бизнес-логики, а мы про отрисовку говорим.

Отрисовка это частный случай System в этой архитектуре. Вся бизнес-логика всего лишь разные System, которые между собой взаимодействуют. Коллизии, движение, урон и тд — это все System. И отрисовка здесь ничем не выделяется.

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.

Тени как объекта нет. Есть разная освещенность разных фрагментов объектов, которая расчитывается в зависимости от многих факторов, в том числе и от прямой видимости источников света.

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

Здравствуйте, SergeyOsipov, Вы писали:

SO>Есть 3D объект, и лампа. Они отрисовываются. А еще есть тень.
SO>Тень должна знать про объект, чтобы отрисоваться, но она еще и должна знать про источник света, где он и какие у него характеристики.

SO>Куда лучше по дизайну засунуть тень? В объект? Но тогда как привязать лампу? В лампу? Но тогда лампа должна знать про все объекты.

SO>Вопрос не в том, как сделать. А в том как по красоте с точки зрения ООП.

Зависит от алгоритма рисования. Если что-то хотя бы приблизительно фотореалистичное, то всё вообще не так.
Потому что кроме теней есть ещё блики и отражения. Их тоже отдельными объектами?
И не понятно, как объект у тебя может рисоваться, не зная про лампу -- у него же есть более освещенная сторона и менее и т.п.

При фотореалистичном подходе объект не отрисовывается сам по себе, отрисовывается сцена, с конкретными источниками света и с конкретным положением зрителя этой сцены. В процессе какие-то участки оказываются затененными, а какие-то бликуют, а где-то появляются отражения. Но не потому что у нас есть объект "блик" или "тень", а потому что вся сцена рендерится в картинку и картинка получается вот такой. При этом объекты только содержат информацию о своих цветах и свойствах поверхности, а рисовать сами себя, конечно, не умеют. Рисуется сцена целиком. Например, если свет выключить, то всё должно нарисоваться черным...


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

Но от того, что для отрисовки сцена должна знать всё про все объекты всё равно никуда не деться. Например та же тень рисуется поверх каких-то других объектов, а значит должна про них "знать", ну или они про неё. Источник света часть сцены.