Comments 35
Да это жесть какая-то, а не вопросы. Современных соискателей боишься спросить вообще что такое mip маппинг, рискуя получить встречный вопрос: а зачем его трогать, оно же само работает как-то? Мб, конечно, это следствие того, что слишком многое сейчас "просто работает само", поэтому глубокие знания не требуются.
Не отчаивайтесь. Ещё есть достойные соискатели, способные ответить про мип-маппинг и не только.
Да, есть такие, правда такие требуют зарплату $100500/год))
Отличные вопросы. В своё время вопрос о том как же выбирается мип уровня привёл к появлению такой шуки https://busyrev.github.io/mipExploration/ Забавно что от производителя карты рисунок зависит, а от модели - нет, также мобилы прям дичь творят иногда. А люди прекрасно ищутся, если задачи интересные, оплата достойная и ищет не просто HR а глава отдела(тобиш я). Если что мы как раз двигло написали очень производительное. Демка https://www.youtube.com/watch?v=adixpp9CK_A риал ворлд из игры https://www.youtube.com/watch?v=QZsPXvuyD8U Сам себя не похвалишь, никто не похвалит :)
это какой-то странный программист графики. На вулкане к примеру мипмапы надо руками генерить, само собой ничего не работает
В целом вопрос о том как работает мипмаппинг очень быстро встает когда нужно самому рассчитать мип уровень, к примеру в случае трассировки лучей
наверное это программист графики для игр на каком-нибудь коммерческом движке (не будем показывать пальцем на движок). на самом деле можно даже генерировать мипы, но не понимать как они выбираются в итоге + когда все есть из коробки многие не задумываются про всякие ваши ddx, ddy, откуда они берутся, как текстуры и вообще данные на гпу приходят и про вообще ваши все эти математики - кинул объект на сцену, какая-то магия, в шейдере уже есть матрицы, есть текстуры, засамплил не думая и уже программист графики (слава богу не все такие, но по ощущениям таких кандидатов все больше, хотя прям собеседовать кого-то я отказался лет 5 назад).
хотя вопросы откровенно простые, но учитывая современный рынок и легкость в первых шагах в геймдеве с использованием движков, даже такие вопросы многих ставят в тупик
Сейчас есть unreal engine 4. Поясните смысл существования программиста графики и написания движка в 2021.
Свой движок даёт намного больше возможностей для низкоуровневых оптимизацией и адаптации всего движка для своих игр.
Смысл существования программистов графики в разработке и улучшении методов компьютерной графики. Пока ещё не все задачи в этой области решены и работа для нас есть.
UE 4 кто-то пишет, и среди этих людей есть программисты графики
UE 4 великолепный движок, но далеко не ультимативное решение со множеством своих проблем и закидонов.
При использовании UE4 иногда все равно есть потребность в программировании графики, написать там кастомные шейдера для игры, подправить чего-то, корректно настроить существующий рендер, пофиксить багло в рендере и т.д.
Кастомные готовые движки других студий никто не отменял, заменять их на ue4 просто так без весомых причин никто не будет.
Куча существующих игр на разных движках требуют поддержки и багофикса
Некоторые игры требуют очень кастомных рендерных решений (см. Claybook, Dreams и т.д., где даже полигонов то нету).
А скока там фпс выдаст этот замечательный движок при 5000 активных акторов с включённым Tick?
Если вы используете unreal engine 4, но вдруг что-то начинает умирать, вам нужен программист графики. Когда вы хотите какой-то эффект которого нет из коробки, вам нужен программист графики. Когда вы хотите отобразить 100 тысяч анимированных объектов, как я показывал в демке https://www.youtube.com/watch?v=adixpp9CK_A вам потребуется программист графики. Если вы просто собираете игры как из конструктора, только из готовых деталей, вам не нужен программист графики, просто ваши задачи не доросли до возможности такого специалиста окупать. Современная видеокарта это невероятно гибкий и мощный инструмент, владение которым требует многих лет тренировки и оттачивания навыков. Ровно как react во фронтенде, очень много кто его использует, но есть множество случаев когда он неуместен.
к остальным комментам. если студия большая и делает большие дорогие игры, то использование стороннего движка это зависимость от лицензии и вообще от желаний юридического отдела разработчика движка. это риски, для многих компаний (см EA, Ubisoft etc) проще разработать свой двиг и не рисковать что разработчики сменят лицензию движка, закроют его, перестанут поддерживать и т.д
Наверное узнал про мир графики по этим вопросам больше, чем знал до этого вообще.
Было бы очень круто, если бы кто-нибудь написал статью с ответами на все эти вопросы.
Посоветуйте, пожалуйста, проверенные временем настольные книги, учебники по разработке графики и игровых движков. Знаю о red book, но этого мало.
По графике могу посоветовать упомянутую выше Real-Time Rendering.
Про игровые движки, к сожалению, не берусь что-то советовать.
По игровым движкам знаю про Game Engine Architecture (уже есть third edition).
Графика: серии Shader X, GPU Pro, GPU Zen, GPU Gems, Ray Tracing Gems. Отдельные книги: Shaders for Game Programmers and Artists, Real-Time Rendering.
Игровые движки, и всякие околодвижковые темы: серии Game Programming Gems, Game Engine Gems.
Принципы компьютерной графики не меняются уже много лет. Возможности видеокарт выросли, пайплайн усложнился немного. Появился compute, ray tracing. Но база та же. Из этих книг можно много чего почерпнуть даже сейчас.
Обычно в книгах очень много интересных техник которые на практике не применимы при текущем развитии. Практические техники лучше смотреть у тех кто занимается практикой. Все ведущие игровые студии выпускают пайперы на Siggraph, GDC или на своих сайтах, там гораздо приспособленные к практике решения. В книгах тоже много интересных и полезных идей, но всё же там часто теоретизируют.
Эта статья
>Вопросы на собеседовании графонщика в гайдзин
«Есть лес, есть танк, найди коллизию танка с деревом»
Тру стори.
Ещё хорошими вопросами будут про MSAA там много тонкостей того, как вычисляются атрибуты для каждого сэмпла. Какие будут ddx ddy в каждом сэмпле и при каких обстоятельствах. Как правильно резолвить msaa в HDR пайплайне.
Про TXAA можно долго говорить о методах подавления гостинга и замыленности.
А так-же стоит поговорить про оптимизацию шейдеров. VGPR, bandwidth, occupancy, wavefront и что происходит при бранче и т.д
Ой, не нравятся мне эти вопросы по MSAA и TXAA. Очень смахивает на "сам только что узнал, буду теперь валить кандидатов". Чего греха таить, сам я не знаю сходу (хотя графический программист, вроде) ответы на эти вопросы. Но это очень специфические, относящиеся к определенной технике/методу/эффекту темы. Кто с этим плотно не работал (я не работал), всех нюансов сходу знать не может. Таких вопросов можно придумать миллион. ИМХО, надо спрашивать про базовые вещи, без понимания которых очевидно что дальше в "MSAA" лезть не следует. Вопросы описанные в статье - база и основа. Хорошие вопросы (Ваш про оптимизации тоже).
Чтобы я еще спрашивал:
Буфер глубины. Как хранятся значения в нем? Как влияет на точность значения near и far plane? Что можно сделать для повышения точности
Матрицы трансформации. Пространства координат и переходы между ними. У нас есть большущий бесшовный мир, будут ли проблемы с точностью вычислений и если будут, то какие есть методы борьбы с ними?
Render Pipeline. Как из вершины модели получается пиксель на экране? Какие оптимизации применяют производители видеокарт для ускорения пайплайна? Что быстрее отрисовать: меш из миллиона вершин занимающих один пиксель, или треугольник занимающий миллион пикселей? (Не смотрите на меня так, очевидно же что вопрос с подвохом).
Владение тулзами. У вас на сцене то исчезает, то появляется модель (должна быть всегда, это баг). Что вы будете делать чтобы локализировать и починить эту проблему? На некоторых видеокартах эффект отличается визуально от референсной реализации. Ваши шаги по выявлению "неисправности"?
на самом деле из всех этих вопросов даже про рендер пайплайн можно говорить часами, начиная с UMD, KMD и их роли в dx/opengl/vulkan и заканчивая тем, как работают кэши у output merger когда стоит блэнд. хотя наверное чтоб спросить в общем и пойдет, но имхо если собеседовать на мидла/сеньора то обсуждения опыта в резюме (а как эту технику сделали, какие были сложности, что бы сделали по другому). из своего последнего собеседования, только положительные ощущения от собеседования с человеком, с которым я час обсуждал как раз анти-алиасинг (который у меня в резюме и был) и очень не понравился вопрос на "пересеките на бумажке луч с плоскостью", что гуглится за 5 минут и особо в памяти потом не задерживается. вывести самому можно (что я и сделал в итоге) но зачем? хотя для джунов нужны как раз общие вопросы
TXAA сейчас используется прям везде, есть сотни техник которые используют его идеи, странно будет если кандидат ничего не слышал про это.
Сложные вопросы нужны чтобы отделить джуна от сеньора. К примеру даже про MSAA сеньор может не знать, но если знает это уже большой плюс.
Ваши вопросы хорошие. Про Parallel reduction ещё неплохо бы спросить.
Вопросы на собеседовании для программистов компьютерной графики