3D движок вручную, какие инструменты выбрать?

Всем добрый день, интересует вопрос по поводу того, какие библиотеки использовать для непосредственного написания своего 3D движка. В качестве языка рассматриваю С/С++, но в целом не имеет значения. Не ставлю над этим проектом каких-либо серьезных задач, просто хочется понять как движки устроены внутри реализовав самостоятельно необходимую объектную архитектуру, векторную геометрию, освещение, сглаживание и прочее. Посмотрел в сторону OpenGL, но в связи с обилием множества встроенных функций это не совсем то, что я ищу. Подскажите, пожалуйста, знающие люди какой-либо инструмент в котором, грубо говоря, нет ничего кроме DrawPoint и приходилось бы все реализовывать самостоятельно.

0

Kot_v_losinah, Двумерный массив unsigned (можно и в виде union с ARGB структурой для доступа к самим компонентам цвета без ручных битовых операций и сдвигов),имитирующий буфер кадра (битмап примерно так же устроен можно и его пользовать - именно набор сканлайнов для формата 32 bit/пиксель).
DrawPoint там как такового нет но это как бы установка элемента массива. Он ежели что прекрасно в DC окна выбрасывается (что массив что битмап) чем и имитируется двойная буферизация.
Прекрасно подходит что для растерезирующего что для трассирующего софтверного рендера. Примерно так же всегда и изучали как графический конвейер устроен изнутри во все времена. В досовские времена к примеру этот массив просто напрямую в видеопамять выбрасывался (или в видеопамяти сразу и жил при наличии аппаратной многостраничности у видеокарты).

Добавлено через 6 минут

Сообщение от Kot_v_losinah какие библиотеки использовать

Из остального там разве что std::vector и смарт-поинтеры понадобится или их самодельные аналоги - что вам лично из этого удобнее. ну и библиотека линейной алгебры, причем не общая а для 2d и 3d случая в однородном пространстве - т.е. в общем то свое написать быстрее чем найти готовое именно под это.

Добавлено через 5 минут

Сообщение от Kot_v_losinah просто хочется понять как движки устроены внутри реализовав самостоятельно необходимую объектную архитектуру

Движки или 3D конвейер/API? Движок уже обычно пользует готовый аппаратный 3D конвейер и его API. По сути задача конвейера - отрисовка тектсурированого освещенного треугольника в огромных количествах оных треугольников в секунду, что софтверно в нужных количествах давно не достижимо. Задача же движка уже другая - создание и логика работы (типа анимации и т.д.) сцены аки набора оных треугольников с логическим разделением их групп на меши и т.д.

1

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

0

Kot_v_losinah, Буфер экрана это тупо массив лежащий одним линейным куском. То же самое z-буфер и остальные буфера какие ни придумывай - отличаются они только назначением и форматом элемента(ячейи). Для удобства доступа еще массив указателей на начало каждой строки (скан-лайна) буфера чтобы быстро можно было адресовать по x,y, вернее y,x . Битмап, именно так и устроен - это массив указателей на сканлайны (еще можно и отдельным куском каждую строку сделать что было очень актуально во времена когда одним куском можно было не более 64kb памяти выделять).
Ну а в окно это попадает путем его отправки в DC которое получается через хендл. Не знаю дает Qt прямой доступ к хендлу окна и функциям WinAPI как VCL или не дает как FireMonkey, но под капотом для винды они это точно все пользуют. Это штатный способ отрисовки битмапки и т.п. в окно и другого в общем то нет. Но если не дает то как бы проще в визуалстудии это поиметь создав пустойдесктопный проект. Там создание главного окна средствами WinAPI и получение его DC при приходе события WM_PAINT по которому оный буфер и надо кинуть в DC уже сразу есть.

0

https://habr.com/ru/post/249139/

1

Сообщение от Kot_v_losinah реализовав самостоятельно необходимую объектную архитектуру, векторную геометрию, освещение, сглаживание и прочее.

Сообщение от Kot_v_losinah нет ничего кроме DrawPoint и приходилось бы все реализовывать самостоятельно.

Тогда учебник типа Машинная графика на ЭВМ + самодельный софтверный рендер с нуля.

Из готовых библиотек можно взять любой способ что закрашивает субпиксель на экране. Например гуглить рисование фракталов С++, там как раз субпиксельно и работают. Или взять glut только чтобы закрашивать пиксели и все.

Никакой скорости и практической пользы не будет, лютый матан, море кода и велосипедов. Зато все свое…как и хотели.

Добавлено через 7 минут
Если крутая видеокарта, как вариант можно попробовать написать рендер на GPU например 3д фракталов Mandelbulb 3d. Так простые формулы очень сложных поверхностей+ вероятно скорость работы.

0