сорри, не понял про setter/getter для вектора... setter/getter у меня упоминается в пропертях, которые удобно их заворачивают, это не только к векторам и контейнерам относится, а ко всему
с инклюдами проблема в том что их все равно надо делать, а для уменьшения инклюдов все равно нужно писать forward declaration'ы. Это все тупая работа по решению зависимостей, которую в других языках перекладывают на кмпилятор
Нет, зачем весь код С++ мира, только локального проекта. Грубо говоря сначала все распарсить, собрать AST. Решить все зависимости. А потом уже генерить код. Можно представить это как некую аналогию precompiled header'а на весь проект и forward declaration всех типов
Согласен, мой косяк в том что я не разобрался в концептах... если это решает проблему SFINAE, то с темой явно стоит ознакомиться не по-диагонали. Все же отмечу что SFINAE был, и остается с нами надолго. А такой класс решений, на мой взгляд, должен зарубаться еще на уровне идеи. Тем не менее это попало в стандарт.
Решают ли модули проблему инклюдов - не уверен. Опять же, не знаком с темой глубоко на уровне использования, лишь абстрактно. Однако, на мой взгляд, внутри одной библиотеки, коим разработчиком можешь являться, проблема остается все той же
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
нее ) солвер сначала применяет обычные импульсы, чтобы тела разлетались. Если применять только их, то тела будут проникать друг в друга. Поэтому он добавляет еще и "псевдоимпульсы", направленные на то чтобы тела мгновенно "растолкнуть" друг из друга. Эти псевдоимпульсы направлены число на то чтобы тела не проникали друг в друга
Пример с прыгающим мячом - это старый подход, в котором вместо "псевдоимпульсов" применяются настоящие. Которые не только выталкивают, но и задают некоторую скорость. Из-за чего энергия растет
Псевдоимпульсы же не влияют на скорость, но влияют на псевдоскорость. Обычная скорость сохраняется от кадра к кадру, псевдоскосрость же обнуляется на следующем кадре
Это прям отдельная и большая тема ) Газы/жидкости моделируют 2мя способами, насколько я знаю:
частицами. Много-много частиц взаимодействуют друг с другом. Самый распространенный подход в играх
разбиение пространства на кластеры и расчет поведения газа/жидкости в каждой ячейке
В minecraft/teardown я думаю все гораздо проще, там просто у вокселей (кубиков или что там) есть статус горит/не горит, и он распространяется на соседей с некоторым таймером
Был такой не самой последней модели. Покупал чтобы воткнуть в проектор и смотреть кино. Оно настолько мертвое было, что даже подключение блютус-колонок просаживало частоту кадров в проигрывателе. Интересно что на более новой модели даже игры запустились, даже не верится
Господи, ну почему в этих всех крипто-финансовых статьях такой стиль изложения? Яйца маска, сиськи, если бы не модерация хабра и член бы куда-нибудь присунули! простите, заразился стилем автора
сорри, не понял про setter/getter для вектора... setter/getter у меня упоминается в пропертях, которые удобно их заворачивают, это не только к векторам и контейнерам относится, а ко всему
с инклюдами проблема в том что их все равно надо делать, а для уменьшения инклюдов все равно нужно писать forward declaration'ы. Это все тупая работа по решению зависимостей, которую в других языках перекладывают на кмпилятор
Нет, зачем весь код С++ мира, только локального проекта. Грубо говоря сначала все распарсить, собрать AST. Решить все зависимости. А потом уже генерить код. Можно представить это как некую аналогию precompiled header'а на весь проект и forward declaration всех типов
Согласен, мой косяк в том что я не разобрался в концептах... если это решает проблему SFINAE, то с темой явно стоит ознакомиться не по-диагонали. Все же отмечу что SFINAE был, и остается с нами надолго. А такой класс решений, на мой взгляд, должен зарубаться еще на уровне идеи. Тем не менее это попало в стандарт.
Решают ли модули проблему инклюдов - не уверен. Опять же, не знаком с темой глубоко на уровне использования, лишь абстрактно. Однако, на мой взгляд, внутри одной библиотеки, коим разработчиком можешь являться, проблема остается все той же
it_union, харе классы набирать, высасывая желчь из популярных тем. Роблокс - отличная платформа для развития и творчества.
Просто не настроена коллизия ткани самой с собой, в итоге она проникает через себя
Честно говоря не знаю. Думаю это все хаками делается
Наверное самый продвинутый - PhysX, но самую крутая физика в играх как правило с кастомными физ движками..
ага, согласен. Но в играх за такой точностью уже никто не следит, и обычно эта проблема решается тем, что тела не абсолютно упруги и часть энергии всегда поглощается при столкновении, в итоге энергия системы точно не растет
ээм.. оригинала нет. Физика твердого/мягкого тела - это общие понятия в игровой физике, вероятно к остальному миру физики это не особо применимо :)
я б поиграл!
У меня телеге есть небольшой пост про физику самолета. Но там все сильно упрощено
нее ) солвер сначала применяет обычные импульсы, чтобы тела разлетались. Если применять только их, то тела будут проникать друг в друга. Поэтому он добавляет еще и "псевдоимпульсы", направленные на то чтобы тела мгновенно "растолкнуть" друг из друга. Эти псевдоимпульсы направлены число на то чтобы тела не проникали друг в друга
Пример с прыгающим мячом - это старый подход, в котором вместо "псевдоимпульсов" применяются настоящие. Которые не только выталкивают, но и задают некоторую скорость. Из-за чего энергия растет
Псевдоимпульсы же не влияют на скорость, но влияют на псевдоскорость. Обычная скорость сохраняется от кадра к кадру, псевдоскосрость же обнуляется на следующем кадре
Нет ничего после выкладки не правил. Для пуль используется трассировка, либо continous collision detection. Он есть в статье вкратце
мой любимый видос про физические глитчи - skate 3 )
Это прям отдельная и большая тема ) Газы/жидкости моделируют 2мя способами, насколько я знаю:
частицами. Много-много частиц взаимодействуют друг с другом. Самый распространенный подход в играх
разбиение пространства на кластеры и расчет поведения газа/жидкости в каждой ячейке
В minecraft/teardown я думаю все гораздо проще, там просто у вокселей (кубиков или что там) есть статус горит/не горит, и он распространяется на соседей с некоторым таймером
спасибо ) что ж, более глубокие знания дают профит даже при использовании готовых движков
Есть исходники демки Box2D для презентации: https://github.com/erincatto/box2d-lite
Или более математические статейки по физдвижкам, например вот: https://gamedev.ru/code/articles/?id=4706. Там же есть и исходники
Был такой не самой последней модели. Покупал чтобы воткнуть в проектор и смотреть кино. Оно настолько мертвое было, что даже подключение блютус-колонок просаживало частоту кадров в проигрывателе. Интересно что на более новой модели даже игры запустились, даже не верится
Это как вы хорошо завернули! Непонятные задачи сделайте понятными, и тогда они будут прогнозируемы и оцениваемы. Все верно :)
А где время на упрощение и ресерч? Зачастую в задачах с большой неопределенностью это отнимает бОльшую часть времени.
Господи, ну почему в этих всех крипто-финансовых статьях такой стиль изложения? Яйца маска, сиськи, если бы не модерация хабра и член бы куда-нибудь присунули! простите, заразился стилем автора