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

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