Slavik KENNY

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

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

делал замену термопасты и термопрокладок

Зачем, а главное нафига? Выросла нагрузка - выросла температура, все логично.

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

Как проверить АЦП на Arduino МЕГА 2560?

Без всяких шилдов подать на проверяемый аналоговый вход напряжение от 0 до 5В, прочитать его и вывести значение в Serial.

Ищите конвертеры. X точно поддерживался когда то 3dмаксом через плагин. 3ds вообще звучит как нативный. Возможно нужно в максе делать эксопрт, а не open

тут

У Blender есть встроенный аддон Paper Model для генерации схемы бумажной модели, возможно и для обёртки подойдёт.
https://docs.blender.org/manual/en/latest/addons/i...

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

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

В том весь и прикол. Программист это не тот кто пишет код, а тот кто решает конкретную задачу и создает нужное, важное ПО. Для этого необходимо знать и уметь так много, что непосредственное написание кода это дело даже не десятое.
Начни с того что найди какую ни будь проблему, можно свою, но лучше чужую. Подумай что можно автоматизировать для мамы/папы/бабушки/дедушки, для одноклассников (лучше одноклассниц), если работаешь то, разумеется, на работе. Опиши проблему в виде "черного ящика", разработай математическую модель проблемы. Записать матмодель на каком ни будь ЯП это уже мелочи.

Если рассуждать по-дизайнерски, то выбор стиля рисования зависит от того, какого эффекта/впечатления нужно добиться, чему нужно соответствовать (культуре, временной эпохе, возрасту итп).
А художнику (нехудожнику в том числе) все это по барабану, потому что он так самовыражается. И на любой вопрос может ответить "я так вижу".
Отвечаю на вопрос. Самостоятельно можно рисовать как удобно и как угодно. Все зависит от цели.
Делая дизайн для камерного оркестра скрипачей, я найму каллиграфа, потому что сам с вензелями красиво не разберусь. А на обложку к треку гаражной банды могу и сам что-то накидать.
Но развитие и обучение еще не отменили)

Тема топика - экстремальное изучения языка и фреймворков.

Лет 10 назад я-бы запретил. И себе и другим. Но сегодня условия войти-в-айти таковы что на все времени не хватает а фичи языков и фреймворков растут. Уже просто изучать целый семестр один язык недостаточно. Вообще мне термин Core непонятен. Если у тебя Java приложение падает по OOM а для решения этой задачи нужен еще ох какой пласт знаний по Linux по организации памяти и по виртуализации Docker то скажите пожалуйста какой Core это описывает. Или другой пример. Вы сделали бизнес приложение с БД которое быстро работает на детских объемах базы. Но когда зашли продуктовые данные - приложение залагало и упало. Вот скажите какой Core этот процесс оптимизации описывает? Да никакой. Есть совокупность инженерных практик начиная от теории алгоритмов и заканчивая тестированием и контрактами.

Вобщем автор. Ты можешь читать хоть 10 книг одновременно. Просто у тебя должно быть видение того на какую вакансию и должность ты пойдешь. И какие хоть примерно задачи ты будешь решать. Ну и сроки хотя-бы осязаемые. А то так 10 лет можно просидеть.

Любой GAPI является инструментом прикладного уровня, который инженер может встроить в свой код с целью пользоваться его возможностями. Прямое использование любого API является примером тесной интеграции кода программы с кодом целевой платформы.
Целевой платформой является аппаратно-программный комплекс, на котором планируется запускать разрабатываемый код. Целевой может быть Sony Playstation, ПК с виндой, Мак или мобила с Андроидом.

Код с тесной интеграцией целевых API нередко пропитан их общей "атмосферой". Это выражается в стиле кода, в общих конструкциях, в заточенности кода проекта на использование совместно с конкретными API.
Использующий DirectX8 код не так просто перевести на использование DirectX9, еще сложнее перевести на использование DirectX10/11 или DirectX12. Код с использованием OpenGL1.1 тяжело поддается модификации для использования OpenGL2.0, 3.0 или дальше. Любая кодовая база с тесной интеграцией DirectX/OpenGL очень тяжело переводится на Vulkan, Metal или профильные GAPI некоторых закрытых целевых платформ.

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

В задачах кроссплатформенности решающую роль играет знание архитектуры П.О. Потому что кроссплатформенность требует разработать агностический слой, под которым будет находиться настраиваемая связь с целевым API. Когда речь идет о системных API целевых платформ, агностический слой представляет из себя фасад универсальной операционной системы. Когда речь идет о GAPI, агностический слой представляет собой API для универсального GPU. Когда речь идет о звуке, агностический слой представляется универсальной звуковой системой.
Без всеобъемлющего знания архитектуры П.О. такие инструменты разработать крайне сложно. Без глубокой экспертизы во всех целевых API и целевых платформах разработать такой слой возможным не представляется. Без экспертных знаний используемых в разработке языков построение кроссплатформенного кода выливается в не распутываемый клубок взаимопереплетающихся проблем, решение каждой из которых на одной платформе гарантированно сломает поддержку другой.
Я об этом пишу потому что знаю множество подходов к решению задач разработки кроссплатформенного кода. Я сталкивался с подходами которые не решают задачу кроссплатформенности и знаю пути более эффективного решения этих задач для конкретных случаев в конкретных проектах.

Когда агностический слой выведен, весь кроссплатформенный код пользуется только им. Под агностическим слоем, тем или иным способом, весь код сводится к использованию целевого API.
Таким образом, для того чтобы позволить игре рендериться и через DirectX, и через OpenGL, и через Vulkan, нужно в движке игры разработать универсальный внутренний GAPI, вызовы которого будут передаваться в выбранный пользователем целевой GAPI. Форматы данных, ресурсы и шейдеры, при этом, ровно так же выбираются исходя из выбранного пользователем целевого GAPI и могут пересекаться между разными GAPI.
Те же шейдеры сегодня спокойно транслируются из HLSL в GLSL или SPIR-V специальными трансляторами. Геометрия может быть одинакова, форматы текстур на целевой платформе между всеми GAPI, как правило, одинаковы.
Дело остается только за грамотной разработкой своего маленького виртуального GPU.

Организуйте движение в тюрьме или ИТУ.
Времени там целая куча, ЗК реально страдают фигней. На выходе будут иметь проффессию и какой то статус.
Начать можно с подачи запроса вашему депутату, он примет ваше предложение и возможно оно пройдет

Так и не смог понять, как мог устареть алгоритм сортировки или поиска пути за лет 5... Тогда мне это показалось диким и, как оказалось, не зря.

Не знаю, что вы поняли из того, что вам сказали загадочные "мидолами" с несколькими лет стажа, но вот что вам сказал выше уважаемый Wataru вы похоже таки и не поняли.
Поясню. Алгоритмы учат не для того, что бы запомнить еще один "самый современный" алгоритм, - все равно завтра вы его забудете, а если надо будет применить - поищете в Гуугле. Алгоритмы УЧАТ для того, что бы приобрести навыки алгоритмического мышления. А ВЫСОКОквалифицированный разработчик тем и отличается от "мидола" с "несколькими годами опыта работы", что в первую очередь умеет проанализировать ЛЮБОЙ алгоритм, найти его ограничения, сильные и слабые стороны и пр., а не похвастаться, что он запомнил самый новейший алгоритм, который улучшает некоторые ранее известные на 0.00002%.

Это как в музыке - сначала учатся играть гаммы (изучают язык программирования), потом учатся играть этюды - простые и незамысловатые пьесы, что-бы приобрести навыки, а уж потом играют сложные композиции. Так вот в программировании, изучение алгоритмов - это и есть этюды. Только тренируете вы не руки, как музыканты, а мозги. И не важно, по учебнику какого года вы это делаете.