134 Кб, 1296x758Рисуй треугольник!
Треугольник сам себя не нарисует!
Спрашиваем, сами же решаем проблему, сами же отписываемся. Постим книжечки, гуглим, учим математику. Посылаем нахуй за легаси.
Читаем шапку перед тем как задать очередной тупорылый вопрос.
Добро пожаловать. Снова.
Шапка треда:
https://gist.github.com/2ch-gd-opengl/26b94fc6f16100af730d84a3d8bbd557
Треугольник сам себя не нарисует!
Спрашиваем, сами же решаем проблему, сами же отписываемся. Постим книжечки, гуглим, учим математику. Посылаем нахуй за легаси.
Читаем шапку перед тем как задать очередной тупорылый вопрос.
Добро пожаловать. Снова.
Шапка треда:
https://gist.github.com/2ch-gd-opengl/26b94fc6f16100af730d84a3d8bbd557
Перекатил чтобы задать вопрос.
Пишу ray casting игру на sdl2, но увы, она не тянет 7к полигонов даже на этапе поиска пересечений. Посмотрел на glsl и это то, что мне нужно - описываешь входные вектора, что-то с ними делаешь и возвращаешь выходные. Но проблема в том, что все гайды, которые я видел, рисуют треугольники а не проводят вычисления на видеокарте.
Я бы хотел загрузить все полигоны в видеопамять и когда нужно, запускать glsl код, который будет принимать лучи, а возвращать координаты пересечений лучей с полигонами, чтобы я через sdl2 наложил текстурки. Как это сделать?
Пишу ray casting игру на sdl2, но увы, она не тянет 7к полигонов даже на этапе поиска пересечений. Посмотрел на glsl и это то, что мне нужно - описываешь входные вектора, что-то с ними делаешь и возвращаешь выходные. Но проблема в том, что все гайды, которые я видел, рисуют треугольники а не проводят вычисления на видеокарте.
Я бы хотел загрузить все полигоны в видеопамять и когда нужно, запускать glsl код, который будет принимать лучи, а возвращать координаты пересечений лучей с полигонами, чтобы я через sdl2 наложил текстурки. Как это сделать?
>>678946
Тебе скорее всего надо надо треугольниками оперировать, а мешами (наборами треугольников). Лучи пересекают меш - записываешь в какой-нибудь массив baseVertex этого меша, а потом glDrawElementBaseVertex где последний аргумент и есть тот baseVertex
Хотя это уже не рейкастинг совсем
Короче, проще найти готовый пример
> Я бы хотел загрузить все полигоны в видеопамять и когда нужно, запускать glsl код, который будет принимать лучи, а возвращать координаты пересечений лучей с полигонами, чтобы я через sdl2 наложил текстурки. Как это сделать?
Тебе скорее всего надо надо треугольниками оперировать, а мешами (наборами треугольников). Лучи пересекают меш - записываешь в какой-нибудь массив baseVertex этого меша, а потом glDrawElementBaseVertex где последний аргумент и есть тот baseVertex
Хотя это уже не рейкастинг совсем
Короче, проще найти готовый пример
>>678987
Уже нашел готовый пример, по описанию делает 1 в 1 то что мне нужно.
https://antongerdelan.net/opengl/compute.html
сейчас впадлу разбирать код правда
Уже нашел готовый пример, по описанию делает 1 в 1 то что мне нужно.
https://antongerdelan.net/opengl/compute.html
сейчас впадлу разбирать код правда
Вопрос в умершем треде
>>679116 →
>>679116 →
>>679117
OpenGL сам за тебя выбирает, куда писать данные. А static/dynamic draw — просто подсказки для OpenGL.
OpenGL сам за тебя выбирает, куда писать данные. А static/dynamic draw — просто подсказки для OpenGL.
>>678945 (OP)
Ты почему о перекате в предыдущем треде не сообщил?
...хотел задать вопрос, но пофиг уже
Ты почему о перекате в предыдущем треде не сообщил?
...хотел задать вопрос, но пофиг уже
>>678945 (OP)
Перекатчик лох.
Перекатчик лох.
>>684868
Кстати двачую - была идея переименовать в тред графических технологий (сразу для всех opengl/directx и других api), и чтобы тут же разбирались детали реализации всяких теней/отражений. Тред отдельно по opengl не нужен.
Кстати двачую - была идея переименовать в тред графических технологий (сразу для всех opengl/directx и других api), и чтобы тут же разбирались детали реализации всяких теней/отражений. Тред отдельно по opengl не нужен.
Для Opengl pipelines (glGenProgramPipelines) можно задавать отдельно стейты вроде блендинга, куллинга и т.д., как в вулкане или эта шняга только для шейдерных стадий. Рендер стейт по прежнему один и глобальный?
>>678946
Вычисления на видеокартах с помощью шейдеров называется GPGPU. Гугли opengl gpgpu example или типа того.
А вообще для вычислений на картах нормальные люди используют openCL или cuda если поддерживается.
Вычисления на видеокартах с помощью шейдеров называется GPGPU. Гугли opengl gpgpu example или типа того.
А вообще для вычислений на картах нормальные люди используют openCL или cuda если поддерживается.
>>686156
Выдаёт на 30% меньшую производительность, чем вычислительный шейдер. Можно просто один в один скопировать код и размеры всяких рабочих групп. Это было на древней нвидия-карточке десятилетней давности, и я думал что это просто потому что opencl был в новинку - но даже на свежей карточке прошлого года со свежим драйвером такой же результат.
>openCL
Выдаёт на 30% меньшую производительность, чем вычислительный шейдер. Можно просто один в один скопировать код и размеры всяких рабочих групп. Это было на древней нвидия-карточке десятилетней давности, и я думал что это просто потому что opencl был в новинку - но даже на свежей карточке прошлого года со свежим драйвером такой же результат.
Антуаны, а где почитать по пайплайну?
Мне нужен форвард/деверенд, шобы заебись было, но я в душе не ебу где про это читать. А может кто-то за меня написал отдельную либу пайплайна? Или нужно воровать код у существующих движков?
Мне нужен форвард/деверенд, шобы заебись было, но я в душе не ебу где про это читать. А может кто-то за меня написал отдельную либу пайплайна? Или нужно воровать код у существующих движков?
>>686169
Ну, зависит от задачи, и одинаковый код не факт что будет хорошо работать и там и там. Для СЛ-я мб эффективнее юзать какие-то встроенные функции.
Ну, зависит от задачи, и одинаковый код не факт что будет хорошо работать и там и там. Для СЛ-я мб эффективнее юзать какие-то встроенные функции.
>>686173
Было бы интересно посмотреть хоть на одну задачу, где cl выдаст более хорошие результаты. Там даже матриц вроде как нет и нужно вручную их делать.
Было бы интересно посмотреть хоть на одну задачу, где cl выдаст более хорошие результаты. Там даже матриц вроде как нет и нужно вручную их делать.
>>684867
Долбоёб? Схуяли?
Долбоёб? Схуяли?
>>696939
Так, пока можно задавать цвет бекграунда.
Завтра буду писать обертки под draw линий и меши. А потом учить прогу их грузить с файлов.
Так, пока можно задавать цвет бекграунда.
Завтра буду писать обертки под draw линий и меши. А потом учить прогу их грузить с файлов.
>>697246
Нашёл из прошлого треда.
Нашёл из прошлого треда.
Ну что, треугольниковёрты? Нашли уже работу мечты? Разрабатываете ли моднейший кластерный рендерер на вулкане? Пишите ли будоражащие вайтпаперы для сигграфа? Похвастайте хоть.
>>701849
Освоил опенгл достаточно чтобы делать свою говно-игру без обёрток в виде движков.
Освоил опенгл достаточно чтобы делать свою говно-игру без обёрток в виде движков.
Reticulating Splines...
>>706914
Нихуя я косой, сразу не заметил, а теперь и не знаю, что за слово должно было быть.
Короче - только cg и оправдывает унылое байтоёбство.
> смывов
Нихуя я косой, сразу не заметил, а теперь и не знаю, что за слово должно было быть.
Короче - только cg и оправдывает унылое байтоёбство.
>>706851
Сам ты говно. Что ты тут делаешь, раз забил?
Сам ты говно. Что ты тут делаешь, раз забил?
>>706914
Что оправдывающая? Тебе нравится смотреть на вращающийся кубы? Оргазм получаешь? Или тебе нравится делать свой велосипедный движок и смотреть как коряво он работает? Тоже наслаждение внеземное получаешь ? (ты ведь сам его сделал! Какой ты молодец! И совсем не говно получилось!)
Что оправдывающая? Тебе нравится смотреть на вращающийся кубы? Оргазм получаешь? Или тебе нравится делать свой велосипедный движок и смотреть как коряво он работает? Тоже наслаждение внеземное получаешь ? (ты ведь сам его сделал! Какой ты молодец! И совсем не говно получилось!)
>>707076
Ты новичок? Теперь учи как делать карты теней. Сам же видишь, что свет попадает туда где его не должно быть.
Ты новичок? Теперь учи как делать карты теней. Сам же видишь, что свет попадает туда где его не должно быть.
>>707084
Нет, я не семейство фторфосфорорганических азоторганических отравляющих веществ нервно-паралитического действия
Нет, я не семейство фторфосфорорганических азоторганических отравляющих веществ нервно-паралитического действия
>>707042
Всё так: люблю вращать кубы и руками собирать сраные икосаэдры, покрывать их жырным слоем кривых шейдеров с циклами и динамическими ветвления ми. Густо поливать подливой теней с алиасингом и акне, медленным ссао и шумными фейковыми отражениями.
А разве вы не любите?
Всё так: люблю вращать кубы и руками собирать сраные икосаэдры, покрывать их жырным слоем кривых шейдеров с циклами и динамическими ветвления ми. Густо поливать подливой теней с алиасингом и акне, медленным ссао и шумными фейковыми отражениями.
А разве вы не любите?
>>709310
Ух бля.
Ух бля.
Освящу тред модной молодежной интерактивной хипстотой.
https://webglfundamentals.org/webgl/lessons/ru/
https://webglfundamentals.org/webgl/lessons/ru/
>>709310
Тебе кроносы дали glTF, пердоль!, Пердоль, блядь, нет не хотим, хотим руками из байтов флотами сладкий хлеб набирать.
> руками собирать сраные икосаэдры
Тебе кроносы дали glTF, пердоль!, Пердоль, блядь, нет не хотим, хотим руками из байтов флотами сладкий хлеб набирать.
>>709519
Как раз хотел вебгл начать изучать. Разобрался с основами шейдеров тут thebookofshaders.com
Как раз хотел вебгл начать изучать. Разобрался с основами шейдеров тут thebookofshaders.com
>>709705
Неплохо! Наверное. А что нибудь в нормальном, текстовом виде есть?
Неплохо! Наверное. А что нибудь в нормальном, текстовом виде есть?
Пишу по туториалу, там у чувака не GLFW, а у меня GLFW. Он начал писать профайлер, у него время кадра меньше миллисекунды, а у меня - 16 мс. Этот фреймлок в ОпенГЛе выставляется или в GLFW?
>>710158
glfwSwapInterval(0);
glfwSwapInterval(0);
>>710158
Похоже у тебя vsync включается по дефолту. glfwSwapInterval(0) поставь в месте, где контекст настраиваешь.
Похоже у тебя vsync включается по дефолту. glfwSwapInterval(0) поставь в месте, где контекст настраиваешь.
Управление ресурсами.
Кто как задумывался над этим? Самый простой способ это делать классы текстур, буферов, шейдеров и тд.
Но потом придётся думать над копированием и уничтожением объектов.
А тут как-то раз решил почитать исходники месы (драйвер свободный для графики) и натолкнулся на мысль, что управление ресурсами можно попробовать не раздавать разным классам, а делать всё в одной (GLContext или типа того). Он же может и следить также за учётом ссылок.
Кто как задумывался над этим? Самый простой способ это делать классы текстур, буферов, шейдеров и тд.
Но потом придётся думать над копированием и уничтожением объектов.
А тут как-то раз решил почитать исходники месы (драйвер свободный для графики) и натолкнулся на мысль, что управление ресурсами можно попробовать не раздавать разным классам, а делать всё в одной (GLContext или типа того). Он же может и следить также за учётом ссылок.
>>678945 (OP)
Возможно ли пользоваться этой фичей на OpenGL? Или это более низкоуровневая вещь?
https://www.nvidia.com/en-us/geforce/news/rtx-io-gpu-accelerated-storage-technology/
Возможно ли пользоваться этой фичей на OpenGL? Или это более низкоуровневая вещь?
https://www.nvidia.com/en-us/geforce/news/rtx-io-gpu-accelerated-storage-technology/
>>711320
Нет. Для этого нужна DirectStorage API (часть DirectX), и то она будет доступна только в следующем году.
Нет. Для этого нужна DirectStorage API (часть DirectX), и то она будет доступна только в следующем году.
>>711319
Ты ослеп или одурел?
Ты ослеп или одурел?
>>710982
У меня в графическом движке есть просто структуры (классы) для текстур, которые содержат указатель на данные и их формат (ширина, высота, байт/флоат). Когда используется опенгл-бекенд, он на лету подхватывает текстурки и если у них нет GLuint текстуры, то генерирует и юзает её. При удалении текстурки вызывается коллбек опенгл-бекенда, удаляющий GLuint имя текстуры.
У меня в графическом движке есть просто структуры (классы) для текстур, которые содержат указатель на данные и их формат (ширина, высота, байт/флоат). Когда используется опенгл-бекенд, он на лету подхватывает текстурки и если у них нет GLuint текстуры, то генерирует и юзает её. При удалении текстурки вызывается коллбек опенгл-бекенда, удаляющий GLuint имя текстуры.
>>711332
ты умеешь смотреть сколько памяти на видяхе юзается?
ты умеешь смотреть сколько памяти на видяхе юзается?
>>711358
Это из-за того что МС сама башляет бабки вендорам, сама продвигает и контролирует.
А кронос - это джентельменский клуб для попиздеть и изобразить антимонопольную альтернативу.
>Это из-за того, что у нвидии проприетарные драйвера?
Это из-за того что МС сама башляет бабки вендорам, сама продвигает и контролирует.
А кронос - это джентельменский клуб для попиздеть и изобразить антимонопольную альтернативу.
>>710377
Эпичный кал
Эпичный кал
Как вкотиться из дженерик байтоёбство в пиксельебство?
Написать свой разудалый говнофреймворк с парой тройкой модных технологий и форсить на собесах гитхабом? Дрочить теорию и надеяться, что проскочишь, а там какнить втянешься?
Написать свой разудалый говнофреймворк с парой тройкой модных технологий и форсить на собесах гитхабом? Дрочить теорию и надеяться, что проскочишь, а там какнить втянешься?
>>712359
Пушто некоторым тяжело работать в столь абстрактной сфере, как программинг без визуализации своих трудов.
Кому-то норм херачить в банках и перекладывать цифири в бездонных бэкэндах. Кому-то прельстиво, если их код имеет визуальный результат.
Если персонально: работал над десктопными приложениями для отображения инфы аля убогий ГИС. И в бекенде работал. Второе невероятно печальнее, хоть и понимаешь, что дело может и даже более полезное, чем первый случай.
Такие дела, байтаны.
Пушто некоторым тяжело работать в столь абстрактной сфере, как программинг без визуализации своих трудов.
Кому-то норм херачить в банках и перекладывать цифири в бездонных бэкэндах. Кому-то прельстиво, если их код имеет визуальный результат.
Если персонально: работал над десктопными приложениями для отображения инфы аля убогий ГИС. И в бекенде работал. Второе невероятно печальнее, хоть и понимаешь, что дело может и даже более полезное, чем первый случай.
Такие дела, байтаны.
>>712395
Ты хочешь поменять одно низкоуровневое говно на другое. Сказано же, что в вулкане надо 1000 строчек, чтобы треугольник нарисовать. По-твоему это весело?
Ты хочешь поменять одно низкоуровневое говно на другое. Сказано же, что в вулкане надо 1000 строчек, чтобы треугольник нарисовать. По-твоему это весело?
>>712406
Только это не правда.
1к строк кода - создают устройство, проверяют технические фичи, создают слои, и т.д. и т.д. То есть не имеют никакого отношения к выводу треугольника
>Сказано же, что в вулкане надо 1000 строчек, чтобы треугольник нарисовать
Только это не правда.
1к строк кода - создают устройство, проверяют технические фичи, создают слои, и т.д. и т.д. То есть не имеют никакого отношения к выводу треугольника
>>712407
Тем не менее, человеку с опытом в бэке (востребованном и хорошо оплачиваемом) вкатываться с нуля в область сложную и не нуждающуюся в большом количестве кватывальщиков, как-то не разумно.
Тем не менее, человеку с опытом в бэке (востребованном и хорошо оплачиваемом) вкатываться с нуля в область сложную и не нуждающуюся в большом количестве кватывальщиков, как-то не разумно.
>>712411
Если хочешь не сойти с ума от выжигания глазонек, то в один непрекрасный момент придётся задуматься о выборе денежка vs уровень радости от работы.
Зря чтоль об этом вашем выгорании столько написано.
Если хочешь не сойти с ума от выжигания глазонек, то в один непрекрасный момент придётся задуматься о выборе денежка vs уровень радости от работы.
Зря чтоль об этом вашем выгорании столько написано.
>>712429
Я считаю, что выгорание происходит не от того, чем ты занимаешься, а от того, насколько интенсивно ты этим занимаешься, и таким образом выгореть можно от чего угодно, хоть от байтоебства, хоть от типа "творческой" 3д графики.
А сколько еще написано о рабах геймдев индустрии, перерабатывающих сверх нормы за несопоставимо низкую зарплату.
Я считаю, что выгорание происходит не от того, чем ты занимаешься, а от того, насколько интенсивно ты этим занимаешься, и таким образом выгореть можно от чего угодно, хоть от байтоебства, хоть от типа "творческой" 3д графики.
>Зря чтоль об этом вашем выгорании столько написано.
А сколько еще написано о рабах геймдев индустрии, перерабатывающих сверх нормы за несопоставимо низкую зарплату.
>>712441
Так за гейдев я и не радею. Есть более практичные сферы, связанные с визуалом типа тренажёрных систем. Проблема, что таких продуктов на порядок меньше перекладывания чиселок.
Так за гейдев я и не радею. Есть более практичные сферы, связанные с визуалом типа тренажёрных систем. Проблема, что таких продуктов на порядок меньше перекладывания чиселок.
>>678946
bvh загугли
bvh загугли
>>712479
Работаю в таком, задачи действительно интересные, как по мне. Единственное что раздражает это требования по поддержке довольно древнего железа.
Бтв насчёт того что визуальный результат приятнее не согласен. Базы данных/распределенные хранилища(и другая байтоебля) тоже очень классно, хотя опыта у меня в этом у меня меньше. Мне кажется в бекенде скучно делать какую-нибудь бизнес логику, бесконечное прокидывание всякого от бека к фронту.
Ещё у меня ненависть к парсерам, но кому-то вроде нравится...
Работаю в таком, задачи действительно интересные, как по мне. Единственное что раздражает это требования по поддержке довольно древнего железа.
Бтв насчёт того что визуальный результат приятнее не согласен. Базы данных/распределенные хранилища(и другая байтоебля) тоже очень классно, хотя опыта у меня в этом у меня меньше. Мне кажется в бекенде скучно делать какую-нибудь бизнес логику, бесконечное прокидывание всякого от бека к фронту.
Ещё у меня ненависть к парсерам, но кому-то вроде нравится...
>>712548
Хз, изучаешь то что интересно, подаешься на вакансии куда интересно, если нет привычки решать задачки на время может быть полезен литкод или аналоги
Хз, изучаешь то что интересно, подаешься на вакансии куда интересно, если нет привычки решать задачки на время может быть полезен литкод или аналоги
Пилю скелетную анимацию, возникли проблемы с моделями для теста. У меня нет пока загрузчика, а писать свой крайне лениво до момента, пока не получу рабочий код постановки меша в позу
Где можно взять простую заскиненную модельку + скелет из пары костей в читабельном для человека виде для отладки?
Где можно взять простую заскиненную модельку + скелет из пары костей в читабельном для человека виде для отладки?
Допустим я рисую одну картинку просто треугольниками, а вторую генерирую фрагментым шейдером при помощи реймаршинга, вместе с depth буффером.
Как мне наложить вторую картинку на первую, используя её depth-буфер?
Как мне наложить вторую картинку на первую, используя её depth-буфер?
>>718387
Как ты пишешь в depth buffer? Это условный буффер, то есть просто текстура или АПИшный depth buffer?
Просто рисуй дополнительным проходом и используй в нем картинку реймарчинга в качестве текстуры и сэмплевай с нее. Я не знаю на сколько у тебя там сложная сцена, но вообще ты это можешь одним проходом рендерить. После того как отрисовал основную сцену, следует дравкалл квада для реймарчинга. В этом случае не надо к нему текстуру привязывать, а можешь сразу в фрагмент шейдере реймарчить. При этом читай актуальную глубину пикселя из до этого отрисованой сцены и сравнивай ее с глубиной куда попал реймарч. Если глубина меньше, заначит рисуешь пиксель реймарчинга, а если нет, то просто пропускаешь пиксель с discard;
Как ты пишешь в depth buffer? Это условный буффер, то есть просто текстура или АПИшный depth buffer?
>Как мне наложить вторую картинку на первую, используя её depth-буфер?
Просто рисуй дополнительным проходом и используй в нем картинку реймарчинга в качестве текстуры и сэмплевай с нее. Я не знаю на сколько у тебя там сложная сцена, но вообще ты это можешь одним проходом рендерить. После того как отрисовал основную сцену, следует дравкалл квада для реймарчинга. В этом случае не надо к нему текстуру привязывать, а можешь сразу в фрагмент шейдере реймарчить. При этом читай актуальную глубину пикселя из до этого отрисованой сцены и сравнивай ее с глубиной куда попал реймарч. Если глубина меньше, заначит рисуешь пиксель реймарчинга, а если нет, то просто пропускаешь пиксель с discard;
>>718387
Еще забыл добавить: Перед дравкаллам квада для реймарчинга отключи тест глубины с glDisable(GL_DEPTH_TEST), чтобы не было проблем с рисованием поверх. Глубину ты и так сам в фрагмент шейдере тестишь. Потом в цикле перед основной сценой не забудь снова включить glEnable(GL_DEPTH_TEST).
Еще забыл добавить: Перед дравкаллам квада для реймарчинга отключи тест глубины с glDisable(GL_DEPTH_TEST), чтобы не было проблем с рисованием поверх. Глубину ты и так сам в фрагмент шейдере тестишь. Потом в цикле перед основной сценой не забудь снова включить glEnable(GL_DEPTH_TEST).
2 Кб, 64x32У меня вопрос, допустим нужно нарисовать тайл пикрил без сглаживания. Если его рисовать методом обычного спрайта в виде квадратной сетки вершин, то он рисуется нормально, если же сетка вершин будет подогнана под форму, то на краях образуется сглаживание краёв. Вопрос как сделать чтобы нормально он рисовался без сглаживания? Сделать сетку на 1 пиксель больше? И вообще интересно насколько оптимизация по форме спрайта влияет на производительность?
>>718387
Во фрагментном шейдере стреляния лучами, просто запиши глубину в gl_FragDepth.
Во фрагментном шейдере стреляния лучами, просто запиши глубину в gl_FragDepth.
>>718387
Ты уже разобрался? Напиши хоть, что конкретно ты делаешь или скриншот выложи.
Ты уже разобрался? Напиши хоть, что конкретно ты делаешь или скриншот выложи.
>>718651
Что у тебя там сглаживается? MSAA что ли включил? Или ты хочешь типа пиксель-арт стайл? Тогда в функцие glTexParameteri() поставь у мин и маг фильтра последний параметр на GL_NEAREST вместо GL_LINEAR. Сделай скриншот, так будет понятнее, что у тебя там не так.
Что у тебя там сглаживается? MSAA что ли включил? Или ты хочешь типа пиксель-арт стайл? Тогда в функцие glTexParameteri() поставь у мин и маг фильтра последний параметр на GL_NEAREST вместо GL_LINEAR. Сделай скриншот, так будет понятнее, что у тебя там не так.
>>718764
Пока не занимался этим. Я просто не сразу подумал, что можно сразу в реймаршинг-шейдере глубину проверять. Через gl_FragDepth или юниформить текстуру с глубиной в шейдер, потом разберусь и, может, скриншот выложу.
Вообще я хотел для своей следующей игры вокруг некоторых объектов сделать полупрозрачные сферы и другие объекты, между которыми происходит smooth union и они слипаются.
Пока не занимался этим. Я просто не сразу подумал, что можно сразу в реймаршинг-шейдере глубину проверять. Через gl_FragDepth или юниформить текстуру с глубиной в шейдер, потом разберусь и, может, скриншот выложу.
Вообще я хотел для своей следующей игры вокруг некоторых объектов сделать полупрозрачные сферы и другие объекты, между которыми происходит smooth union и они слипаются.
17 Мб, mp4,1460x860, 0:33
>>718764
Сделал. Конечно, офигел от этого всего, джва часа разбирался куда что прикрепить. В связи с особенностями моих графического и ГУИ движков сделал так: рендерю в квадрат, закрывающий весь экран реймаршинг сцену, при этом передаю ей текстуру, в которую срендерил depth buffer основной сцены.
Зато теперь можно сделать красивые эффекты. И вообще, я раньше не думал о том, что можно вот так миксить быструю опенгл-сцену и красивую реймаршинг-сцену.
Сделал. Конечно, офигел от этого всего, джва часа разбирался куда что прикрепить. В связи с особенностями моих графического и ГУИ движков сделал так: рендерю в квадрат, закрывающий весь экран реймаршинг сцену, при этом передаю ей текстуру, в которую срендерил depth buffer основной сцены.
Зато теперь можно сделать красивые эффекты. И вообще, я раньше не думал о том, что можно вот так миксить быструю опенгл-сцену и красивую реймаршинг-сцену.
>>719497
Прикольно смотрится. Можешь еще немного фонга на эти сферы добавить. Нормали сферы в реймарчинге легко высчитываются: точка поверхности - центр сферы = вектор нормали. А дальше фонг шейдинг как в обычном шейдере.
Ну собственно еще есть компьют шейдеры, в которых можно сложные эффекты просчитывать, а потом совмещать с обычным фреймбуфером, в том числе реймарчинг и рейтрейсинг.
Прикольно смотрится. Можешь еще немного фонга на эти сферы добавить. Нормали сферы в реймарчинге легко высчитываются: точка поверхности - центр сферы = вектор нормали. А дальше фонг шейдинг как в обычном шейдере.
>И вообще, я раньше не думал о том, что можно вот так миксить быструю опенгл-сцену и красивую реймаршинг-сцену.
Ну собственно еще есть компьют шейдеры, в которых можно сложные эффекты просчитывать, а потом совмещать с обычным фреймбуфером, в том числе реймарчинг и рейтрейсинг.
>>719816
Да, фонг это хорошо, но для моего эффекта не подходит, слишком перегруженным кажется.
И в реймаршинг же нормали вычисляются одинаково для всей сцены:
vec3 SceneNormal(vec3 ori) {
return normalize(vec3(SceneSDF(vec3(ori.x + NORM_EPSILON,ori.y,ori.z),vec3(0,1,0)).d - SceneSDF(vec3(ori.x - NORM_EPSILON,ori.y,ori.z),vec3(0,1,0)).d,
SceneSDF(vec3(ori.x,ori.y + NORM_EPSILON,ori.z),vec3(0,1,0)).d - SceneSDF(vec3(ori.x,ori.y - NORM_EPSILON,ori.z),vec3(0,1,0)).d,
SceneSDF(vec3(ori.x,ori.y,ori.z + NORM_EPSILON),vec3(0,1,0)).d - SceneSDF(vec3(ori.x,ori.y,ori.z - NORM_EPSILON),vec3(0,1,0)).d));
}
Да, фонг это хорошо, но для моего эффекта не подходит, слишком перегруженным кажется.
И в реймаршинг же нормали вычисляются одинаково для всей сцены:
vec3 SceneNormal(vec3 ori) {
return normalize(vec3(SceneSDF(vec3(ori.x + NORM_EPSILON,ori.y,ori.z),vec3(0,1,0)).d - SceneSDF(vec3(ori.x - NORM_EPSILON,ori.y,ori.z),vec3(0,1,0)).d,
SceneSDF(vec3(ori.x,ori.y + NORM_EPSILON,ori.z),vec3(0,1,0)).d - SceneSDF(vec3(ori.x,ori.y - NORM_EPSILON,ori.z),vec3(0,1,0)).d,
SceneSDF(vec3(ori.x,ori.y,ori.z + NORM_EPSILON),vec3(0,1,0)).d - SceneSDF(vec3(ori.x,ori.y,ori.z - NORM_EPSILON),vec3(0,1,0)).d));
}
>>720016
То что я панисал, это быстрое решение для обычной сферы. А твоя жирная функция с шестью сэмплами высчитывает нормаль с помощью градиента. Ну для сложной геометрии только так, да.
Не по теме: у тебя камера дерганая из-за резких движений мышки. На видео это не приятно смотрится в качестве презентации. Для плавного передвижения камеры ты можешь добавить управление аналог-стиками геймпада. Или для клавомыши захуячить свой алгоритм сглаживания движения камеры. Мы же любим свои велосипеды писать, правильно? :)
>И в реймаршинг же нормали вычисляются одинаково для всей сцены
То что я панисал, это быстрое решение для обычной сферы. А твоя жирная функция с шестью сэмплами высчитывает нормаль с помощью градиента. Ну для сложной геометрии только так, да.
Не по теме: у тебя камера дерганая из-за резких движений мышки. На видео это не приятно смотрится в качестве презентации. Для плавного передвижения камеры ты можешь добавить управление аналог-стиками геймпада. Или для клавомыши захуячить свой алгоритм сглаживания движения камеры. Мы же любим свои велосипеды писать, правильно? :)
Изучаю Batch Rendering
и у меня вопрос по поводу функций:
glGenVertexArrays и glCreateVertexArrays
какие в них различия?
и у меня вопрос по поводу функций:
glGenVertexArrays и glCreateVertexArrays
какие в них различия?
Вопрос по поводу матриц, где их лучше считать? Просто у меня вычисления в коде и в шейдер передаётся уже итоговая матрица, у других же наоборот, в шейдер передаются несколько матриц и они там считаются.
>>720419
Твой вариант лучше, т.к. видеокарта не считает n раз одну и ту же матрицу, берет готовую. Обычно у других матрицы комбинируются по всякому и их для этого передают раздельно
Твой вариант лучше, т.к. видеокарта не считает n раз одну и ту же матрицу, берет готовую. Обычно у других матрицы комбинируются по всякому и их для этого передают раздельно
Изучаю Cherno и у него там есть пример
https://www.youtube.com/watch?v=bw6JsLnx5Jg&list=PLlrATfBNZ98f5vZ8nJ6UengEkZUMC4fy5&index=3
шейдер вида:
uniform sampler2D colorTexture[2];
Код:
glBindTextureUnit(0, texture1);
glBindTextureUnit(1, texture2);
Но как я понял это под 4.5 версию работает, у меня же 4.3.
Как биндить текстуру в нужный текстурный слот на моей версии?
https://www.youtube.com/watch?v=bw6JsLnx5Jg&list=PLlrATfBNZ98f5vZ8nJ6UengEkZUMC4fy5&index=3
шейдер вида:
uniform sampler2D colorTexture[2];
Код:
glBindTextureUnit(0, texture1);
glBindTextureUnit(1, texture2);
Но как я понял это под 4.5 версию работает, у меня же 4.3.
Как биндить текстуру в нужный текстурный слот на моей версии?
>>720638
Кажется разобрался как надо:
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture1);
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, texture2);
Кажется разобрался как надо:
glActiveTexture(GL_TEXTURE0);
glBindTexture(GL_TEXTURE_2D, texture1);
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, texture2);
>>721501
Ян Черников.
Ян Черников.
Сап графончики, я тут внезапно решил обмазаться ретро OpenGL'ем, ну там fixed pipeline, draw lists, GL_ARB_texture_env_combine и так далее. Прост сделать пару демок на Си, посмотреть чем деды увлекались в годы моего детства. Посоветуйте годных мануалов? Гугл выдаёт кучу битых ссылок, с трудом нашёл рабочий архив NeHe и ещё поглядываю на демки humus.name. Но чёт не густо. Может есть какие-то олдскульные книги на эту тему? Уверен тогда только так делились инфой. Сейчас пытаюсь найти первые издания OpenGL Red Book. Есть смысл? Или везде только шейдеры и тому подобное?
>>722865
"Расширения OpenGL" погляди, там есть асм-подобные шейдеры и даже nv_register_combiners, и только потом переход к легаси-версиям glsl. Она за 2005 год вроде бы.
Если совсем ретро по типу gluNurbsSurface - то такое я только в красной книге видел, и я листал вот эту или очень похожую версию: https://studfile.net/preview/2807154/
"Расширения OpenGL" погляди, там есть асм-подобные шейдеры и даже nv_register_combiners, и только потом переход к легаси-версиям glsl. Она за 2005 год вроде бы.
>обмазаться ретро
Если совсем ретро по типу gluNurbsSurface - то такое я только в красной книге видел, и я листал вот эту или очень похожую версию: https://studfile.net/preview/2807154/
>>722865
А, да, ещё книга Краснова по opengl для делфи.
К ней ещё архив с демками есть, вот с этими буферам выбора и другими функциями которые никто никогда и нигде не использовал.
А, да, ещё книга Краснова по opengl для делфи.
К ней ещё архив с демками есть, вот с этими буферам выбора и другими функциями которые никто никогда и нигде не использовал.
>>723157
Спасибо что напомнил о Борескове, анончик. Нашёл всё что нужно у него на сайте в разделе старых статей.
Спасибо что напомнил о Борескове, анончик. Нашёл всё что нужно у него на сайте в разделе старых статей.
>>722865
Чем бы человек не обмазывался, лишь бы...
Изучать OGL старых версий в 2021-м году - это стрелять себе в ногу. OGL 3.1 не просто так родили на свет. Везде уже только шейдеры, только хардкор. Можно конечно почитать чего там творили в прошлом и как выкручивались с multitexture extension для блендинга нескольких текстур для одного материала без использования шейдера. Но это все уже далеко далеко в прошлом.
ПС: отдельный изврат без четкого определения - это использовать расширение для шейдеров и при этом продолжать пользоваться FFP функциями. В 2009-м году - прокатывало.
Чем бы человек не обмазывался, лишь бы...
Изучать OGL старых версий в 2021-м году - это стрелять себе в ногу. OGL 3.1 не просто так родили на свет. Везде уже только шейдеры, только хардкор. Можно конечно почитать чего там творили в прошлом и как выкручивались с multitexture extension для блендинга нескольких текстур для одного материала без использования шейдера. Но это все уже далеко далеко в прошлом.
ПС: отдельный изврат без четкого определения - это использовать расширение для шейдеров и при этом продолжать пользоваться FFP функциями. В 2009-м году - прокатывало.
>>723670
Пост не читал, лишь бы ответить? Пчел явно обозначил, что он осознанно именно fixed function хочет потеребонькать. Почему? Ради лулзов, очевидно.
Пост не читал, лишь бы ответить? Пчел явно обозначил, что он осознанно именно fixed function хочет потеребонькать. Почему? Ради лулзов, очевидно.
>>722865
Тогда не было OpenGL. Деды увлекались этим https://github.com/kendallb/scitech-mgl
>чем деды увлекались в годы моего детства
Тогда не было OpenGL. Деды увлекались этим https://github.com/kendallb/scitech-mgl
>>723670
Вот ты душнила, я задал конкретный вопрос, даже цель описал да, для лулзов. Но нет, надо вставить свой охуительный совет. Чего сразу не написал что "в 2021-м году кодать -- это стрельба себе в ногу, игру надо мышкой на готовых ассетах в Юнити делать"?
>>723835
Двачую, именно что для лулзов.
>>723840
Окей, с дедами загнул конечно.
Алсо по ссылке как раз OpenGL, возможно ты хотел запостить какие-то софтварные рендеры или рейкастер какой?
Вот ты душнила, я задал конкретный вопрос, даже цель описал да, для лулзов. Но нет, надо вставить свой охуительный совет. Чего сразу не написал что "в 2021-м году кодать -- это стрельба себе в ногу, игру надо мышкой на готовых ассетах в Юнити делать"?
>>723835
Двачую, именно что для лулзов.
>>723840
Окей, с дедами загнул конечно.
Алсо по ссылке как раз OpenGL, возможно ты хотел запостить какие-то софтварные рендеры или рейкастер какой?
>>723954
Да, объебался немного - ОпенГЛ тогда был, но MGL и без него работает.
>Алсо по ссылке как раз OpenGL, возможно ты хотел запостить какие-то софтварные рендеры или рейкастер какой?
Да, объебался немного - ОпенГЛ тогда был, но MGL и без него работает.
137 Кб, 866x1200>>724265
Вот это?
Вот это?
314 Кб, 920x1280Сап, ананасы.
Посвящаю сегодня эту хуйню самому себе, разработчикам стандарта, и всеобщей борьбе жабы с гадюкой.
Посвящаю сегодня эту хуйню самому себе, разработчикам стандарта, и всеобщей борьбе жабы с гадюкой.
>>725552
велкам ту опенгл
велкам ту опенгл
>>725552
вообще не представляю как этим говном можно пользоваться без тайпсейф обертки какой-нибудь
вообще не представляю как этим говном можно пользоваться без тайпсейф обертки какой-нибудь
Анонче, где сейчас пишут шейдеры руками и можно ли как-то профит с этого получать? Не так давно нашёл канал The Art of Code, где показывают и объясняют как делать эффекты на GLSL, запуская это всё в Shadertoy. Посмотрел пару видео оттуда, что-то свое даже получилось сделать, хочу продолжить, или же это говно без задач на данный момент?
>>725936
Везде пишут. Когда в уе или юнити ты создаешь материалы, ты по сути пишешь шейдеры.
Везде пишут. Когда в уе или юнити ты создаешь материалы, ты по сути пишешь шейдеры.
>>725660
Вообще в glbindings вроде бы енумы вместо макросов, но не уверен, не юзал.
А вообще похуй, это не самое хуевое
Вообще в glbindings вроде бы енумы вместо макросов, но не уверен, не юзал.
А вообще похуй, это не самое хуевое
25 Кб, 544x298Всё что нужно знать про компилятор glsl на этой картинке.
Я что-то переписывал, и обнаружил что сильно фпс просел, хотя я ничего не менял. А там вот оно что.
То что побеждает четвёртый вариант это вообще какая-то петрушка.
Кто-нибудь может объяснить почему разница в два раза? Там же регистры сразу vec4 содержат, по идее - и ему без разницы умножать float или умножать vec4 на -1.
А ещё если в коде есть uniform и я его не использую, то glGetUniformLocation выдаёт -1 (ошибку), как будто юниформа не существует.
И если он входит в какое-то выражение с умножением на ноль по типу float y=x+0⚹<uniform> - то glGetUniformLocation так же выдаёт -1.
Я что-то переписывал, и обнаружил что сильно фпс просел, хотя я ничего не менял. А там вот оно что.
То что побеждает четвёртый вариант это вообще какая-то петрушка.
Кто-нибудь может объяснить почему разница в два раза? Там же регистры сразу vec4 содержат, по идее - и ему без разницы умножать float или умножать vec4 на -1.
А ещё если в коде есть uniform и я его не использую, то glGetUniformLocation выдаёт -1 (ошибку), как будто юниформа не существует.
И если он входит в какое-то выражение с умножением на ноль по типу float y=x+0⚹<uniform> - то glGetUniformLocation так же выдаёт -1.
>>728269
Да, ещё хотел спросить - glGetUniformLocation достаточно оптимизированный (кеширует имена-номера в хеш-таблице) и я могу его каждый кадр вызывать, или лучше сохранить полученный номер и обращаться по нему?
Да, ещё хотел спросить - glGetUniformLocation достаточно оптимизированный (кеширует имена-номера в хеш-таблице) и я могу его каждый кадр вызывать, или лучше сохранить полученный номер и обращаться по нему?
>>728269
Добавлю ещё.
Перенёс определение знака нормали в геометрический шейдер, и остались те же 37 с хвостиком фпс, то есть последний вариант для карточки то же самое, как и просто множить vec3 на float без проверок.
Ещё если использовать (gl_FrontFacing?1:-1)⚹nor - 32 фпс, если поменять на (gl_FrontFacing?1.0:-1.0)⚹nor - 37 фпс.
Это просто форменный беспредел.
Я смотрю на компилятор с++, который мне деление на 7 заменяет на комбинацию imul/sar/shr, а потом на это, где абсолютно (и самое главное численно) эквивалентный код работает с разницей больше чем в два раза по времени, и...
Это в самом деле нужно смотреть на все шейдеры и заменять условия и тернарный оператор на функцию хевисайда?
Добавлю ещё.
Перенёс определение знака нормали в геометрический шейдер, и остались те же 37 с хвостиком фпс, то есть последний вариант для карточки то же самое, как и просто множить vec3 на float без проверок.
Ещё если использовать (gl_FrontFacing?1:-1)⚹nor - 32 фпс, если поменять на (gl_FrontFacing?1.0:-1.0)⚹nor - 37 фпс.
Это просто форменный беспредел.
Я смотрю на компилятор с++, который мне деление на 7 заменяет на комбинацию imul/sar/shr, а потом на это, где абсолютно (и самое главное численно) эквивалентный код работает с разницей больше чем в два раза по времени, и...
Это в самом деле нужно смотреть на все шейдеры и заменять условия и тернарный оператор на функцию хевисайда?
>>728269
Четвертый вариант побеждает потому что терарнарный оператор = branching. А branching мобильные GPU не любят
Четвертый вариант побеждает потому что терарнарный оператор = branching. А branching мобильные GPU не любят
>>728269
>>728270
>>728301
1) Я правильно понимаю, что ты рисуешь двусторонние грани? Если так, то зачем? Просто в большинстве случаев это двойной overdraw. (Хотя это может быть система частиц?)
2) На каком устройстве ты все это запускаешь?
2.1) Компилятор glsl в принципе моложе чем gcc, и у каждого вендора он запросто будет собственный.
2.2) Даже в рамках одного вендора могут быть разные результаты на чипах разных поколений.
3) Функция Хевисайда - гуд. Step в glsl - существует с 1.20, следовательно сегодня может быть даже выполняется с одного опкода в АЛУ, хрен его знает, но если сокращает время вычислений - так даже лучше.
4) Про неиспользованные юниформы и -1 вместо location - да, регулярно наступал на эти грабли, тут компилятор glsl (по крайней мере на nvidia) оптимизирует, сука, тупо вырезая то, что не вносит вклад (в том числе умножается на ноль), поэтому когда я пишу шейдер с кучей входных параметров, то сначала я их все сваливаю в сложение в одну переменную, которую затем умножаю на эпсилон и прибавляю к результату.
5) Про float и int - да, печалька, что компилятор не делает автоматическое приведение констант к типу левой части. Я с давних пор пишу как завещал дедушка Кармак: везде где требуется вещественный тип - число пишется полностью, т.е. так - 1.0f.
6) Про GetUniformLocation:
6.1) Пруфов не будет, где-то читал, что тривиальные части состояния (т.е. не буферы, и не то, что вычисляется только на видеокарте) современный драйвер хранит у себя и возвращает не запрашивая устройство, но не очень в это верю и предпочитаю нужные части кешировать в своем приложении, все равно цепочка вызовов будет короче.
6.2) А зачем вообще его вызывать каждый кадр? Ты каждый кадр компилируешь программу заново из динамически составленных исходников? Сделай класс или структуру, которая будет хранить location вместе с хэндлдом шейдерной программы, ты же где-то и так его хранишь.
>>728270
>>728301
1) Я правильно понимаю, что ты рисуешь двусторонние грани? Если так, то зачем? Просто в большинстве случаев это двойной overdraw. (Хотя это может быть система частиц?)
2) На каком устройстве ты все это запускаешь?
2.1) Компилятор glsl в принципе моложе чем gcc, и у каждого вендора он запросто будет собственный.
2.2) Даже в рамках одного вендора могут быть разные результаты на чипах разных поколений.
3) Функция Хевисайда - гуд. Step в glsl - существует с 1.20, следовательно сегодня может быть даже выполняется с одного опкода в АЛУ, хрен его знает, но если сокращает время вычислений - так даже лучше.
4) Про неиспользованные юниформы и -1 вместо location - да, регулярно наступал на эти грабли, тут компилятор glsl (по крайней мере на nvidia) оптимизирует, сука, тупо вырезая то, что не вносит вклад (в том числе умножается на ноль), поэтому когда я пишу шейдер с кучей входных параметров, то сначала я их все сваливаю в сложение в одну переменную, которую затем умножаю на эпсилон и прибавляю к результату.
5) Про float и int - да, печалька, что компилятор не делает автоматическое приведение констант к типу левой части. Я с давних пор пишу как завещал дедушка Кармак: везде где требуется вещественный тип - число пишется полностью, т.е. так - 1.0f.
6) Про GetUniformLocation:
6.1) Пруфов не будет, где-то читал, что тривиальные части состояния (т.е. не буферы, и не то, что вычисляется только на видеокарте) современный драйвер хранит у себя и возвращает не запрашивая устройство, но не очень в это верю и предпочитаю нужные части кешировать в своем приложении, все равно цепочка вызовов будет короче.
6.2) А зачем вообще его вызывать каждый кадр? Ты каждый кадр компилируешь программу заново из динамически составленных исходников? Сделай класс или структуру, которая будет хранить location вместе с хэндлдом шейдерной программы, ты же где-то и так его хранишь.
>>728334
А зачем оно преобразует int во float? Компилятор с++ даже с -O0 подменяет int на float сам (там в обоих функциях загружается .LC0). Какая мотивация чтобы оставлять в шейдере int целочисленным числом, а не преобразовать по максимуму в конечный тип?
А если я там напишу (5+6+4) вместо (15) он тоже считать это будет каждый кадр? Нет, такое вроде бы сворачивает.
Уже попробовал, ничего не меняется.
Я же написал, что я в фрагментном шейдере вовсе убрал обращение к gl_FrontFacing (считаю знак нормали прямо в геометрическом) - и фпс те же 37, выше уже не подняться.
>>728331
Так оно само считает обе ветви и подставляет результат похожим способом. Третий вариант совпадает по фпс с четвёртым (после замены 1 на 1.0).
>>728347
1 - Листья на ветках.
2 - 1660 ti. Вообще было бы очень интересно, чтобы кто-то в шейдере поставил такую же заглушку и потестил так же у него работает компилятор glsl или нет. У меня есть другой комп постарше, но карточек амд у меня вовсе нету, чтобы проверить что на них.
2.1 - Предположу что ситуация такая же как с openCL. Ты можешь один в один одинаковый код написать на openCL и на куде/glsl (в вычислительном шейдере) - и openCL будет работать где-то в 1.3 раза медленнее. С одинаковым размером локальных групп и всем остальным полностью совпадающим. Думаю что это всё из-за того, что у нвидии нет особой мотивации совершенствовать компилятор openCL, а вот куду они хотят вылизать до максимума, чтобы там не преобразовывалось в каждой нити 1 в 1.0 без какого-либо смысла и цели. А вычислительному шейдеру glsl просто повезло, видимо. Могу демку откопать, запустишь и заценишь сам.
4,6 - со стороны кода решил на всякий случай (внутри оператора присваивания проверку на -1 добавил), чтобы не натыкаться каждый раз при отладке шейдера - и юниформы тоже у себя кеширую, вряд ли драйвер сильно быстрее может это у себя сделать, даже если он этим занимается.
Незачем. После компиляции стоило бы сохранить номера и использовать только их. Ради удобства написания хочется использовать символьные имена переменных - и оператор обращения по индексу неплохо подходит. То есть на каждый шейдер не создаётся свой класс и не загромождает код.
Можно через шаблоны в компайл-тайме сделать, чтобы constexpr-функция во всех местах подменяла строку-идентификатор на номер в массиве - поэтому я пока забью и буду гонять строку в рантайме, а потом переделаю если все более актуальные проблемы буду решены. Всё-равно это нужно только ради эстетической красоты что мол код не делает ничего лишнего, хеш одной строки посчитать это меньше микросекунды наверное. Разница как между 60 и 59.996
Хотя впрочем если бы там было land_shader.sun={..} - то это тоже более чем норм, но не хочется держать отдельный файл со списком юниформов для каждого шейдера, где нужно будет вручную вносить изменения после любого изменений состава юниформов. И ещё во всех местах придётся поменять тип шейдера с общего на специальный с нужным набором юниформов. Может быть на какой-то итоговой версии так сделаю, но на время разработки - нет, спасибо.
>Скорее всего теряется fps на преобразовании int во float.
А зачем оно преобразует int во float? Компилятор с++ даже с -O0 подменяет int на float сам (там в обоих функциях загружается .LC0). Какая мотивация чтобы оставлять в шейдере int целочисленным числом, а не преобразовать по максимуму в конечный тип?
А если я там напишу (5+6+4) вместо (15) он тоже считать это будет каждый кадр? Нет, такое вроде бы сворачивает.
>float(gl_FrontFacing)
Уже попробовал, ничего не меняется.
Я же написал, что я в фрагментном шейдере вовсе убрал обращение к gl_FrontFacing (считаю знак нормали прямо в геометрическом) - и фпс те же 37, выше уже не подняться.
>>728331
Так оно само считает обе ветви и подставляет результат похожим способом. Третий вариант совпадает по фпс с четвёртым (после замены 1 на 1.0).
>>728347
1 - Листья на ветках.
2 - 1660 ti. Вообще было бы очень интересно, чтобы кто-то в шейдере поставил такую же заглушку и потестил так же у него работает компилятор glsl или нет. У меня есть другой комп постарше, но карточек амд у меня вовсе нету, чтобы проверить что на них.
2.1 - Предположу что ситуация такая же как с openCL. Ты можешь один в один одинаковый код написать на openCL и на куде/glsl (в вычислительном шейдере) - и openCL будет работать где-то в 1.3 раза медленнее. С одинаковым размером локальных групп и всем остальным полностью совпадающим. Думаю что это всё из-за того, что у нвидии нет особой мотивации совершенствовать компилятор openCL, а вот куду они хотят вылизать до максимума, чтобы там не преобразовывалось в каждой нити 1 в 1.0 без какого-либо смысла и цели. А вычислительному шейдеру glsl просто повезло, видимо. Могу демку откопать, запустишь и заценишь сам.
4,6 - со стороны кода решил на всякий случай (внутри оператора присваивания проверку на -1 добавил), чтобы не натыкаться каждый раз при отладке шейдера - и юниформы тоже у себя кеширую, вряд ли драйвер сильно быстрее может это у себя сделать, даже если он этим занимается.
>А зачем вообще его вызывать каждый кадр?
Незачем. После компиляции стоило бы сохранить номера и использовать только их. Ради удобства написания хочется использовать символьные имена переменных - и оператор обращения по индексу неплохо подходит. То есть на каждый шейдер не создаётся свой класс и не загромождает код.
Можно через шаблоны в компайл-тайме сделать, чтобы constexpr-функция во всех местах подменяла строку-идентификатор на номер в массиве - поэтому я пока забью и буду гонять строку в рантайме, а потом переделаю если все более актуальные проблемы буду решены. Всё-равно это нужно только ради эстетической красоты что мол код не делает ничего лишнего, хеш одной строки посчитать это меньше микросекунды наверное. Разница как между 60 и 59.996
Хотя впрочем если бы там было land_shader.sun={..} - то это тоже более чем норм, но не хочется держать отдельный файл со списком юниформов для каждого шейдера, где нужно будет вручную вносить изменения после любого изменений состава юниформов. И ещё во всех местах придётся поменять тип шейдера с общего на специальный с нужным набором юниформов. Может быть на какой-то итоговой версии так сделаю, но на время разработки - нет, спасибо.
>>728334
А зачем оно преобразует int во float? Компилятор с++ даже с -O0 подменяет int на float сам (там в обоих функциях загружается .LC0). Какая мотивация чтобы оставлять в шейдере int целочисленным числом, а не преобразовать по максимуму в конечный тип?
А если я там напишу (5+6+4) вместо (15) он тоже считать это будет каждый кадр? Нет, такое вроде бы сворачивает.
Уже попробовал, ничего не меняется.
Я же написал, что я в фрагментном шейдере вовсе убрал обращение к gl_FrontFacing (считаю знак нормали прямо в геометрическом) - и фпс те же 37, выше уже не подняться.
>>728331
Так оно само считает обе ветви и подставляет результат похожим способом. Третий вариант совпадает по фпс с четвёртым (после замены 1 на 1.0).
>>728347
1 - Листья на ветках.
2 - 1660 ti. Вообще было бы очень интересно, чтобы кто-то в шейдере поставил такую же заглушку и потестил так же у него работает компилятор glsl или нет. У меня есть другой комп постарше, но карточек амд у меня вовсе нету, чтобы проверить что на них.
2.1 - Предположу что ситуация такая же как с openCL. Ты можешь один в один одинаковый код написать на openCL и на куде/glsl (в вычислительном шейдере) - и openCL будет работать где-то в 1.3 раза медленнее. С одинаковым размером локальных групп и всем остальным полностью совпадающим. Думаю что это всё из-за того, что у нвидии нет особой мотивации совершенствовать компилятор openCL, а вот куду они хотят вылизать до максимума, чтобы там не преобразовывалось в каждой нити 1 в 1.0 без какого-либо смысла и цели. А вычислительному шейдеру glsl просто повезло, видимо. Могу демку откопать, запустишь и заценишь сам.
4,6 - со стороны кода решил на всякий случай (внутри оператора присваивания проверку на -1 добавил), чтобы не натыкаться каждый раз при отладке шейдера - и юниформы тоже у себя кеширую, вряд ли драйвер сильно быстрее может это у себя сделать, даже если он этим занимается.
Незачем. После компиляции стоило бы сохранить номера и использовать только их. Ради удобства написания хочется использовать символьные имена переменных - и оператор обращения по индексу неплохо подходит. То есть на каждый шейдер не создаётся свой класс и не загромождает код.
Можно через шаблоны в компайл-тайме сделать, чтобы constexpr-функция во всех местах подменяла строку-идентификатор на номер в массиве - поэтому я пока забью и буду гонять строку в рантайме, а потом переделаю если все более актуальные проблемы буду решены. Всё-равно это нужно только ради эстетической красоты что мол код не делает ничего лишнего, хеш одной строки посчитать это меньше микросекунды наверное. Разница как между 60 и 59.996
Хотя впрочем если бы там было land_shader.sun={..} - то это тоже более чем норм, но не хочется держать отдельный файл со списком юниформов для каждого шейдера, где нужно будет вручную вносить изменения после любого изменений состава юниформов. И ещё во всех местах придётся поменять тип шейдера с общего на специальный с нужным набором юниформов. Может быть на какой-то итоговой версии так сделаю, но на время разработки - нет, спасибо.
>Скорее всего теряется fps на преобразовании int во float.
А зачем оно преобразует int во float? Компилятор с++ даже с -O0 подменяет int на float сам (там в обоих функциях загружается .LC0). Какая мотивация чтобы оставлять в шейдере int целочисленным числом, а не преобразовать по максимуму в конечный тип?
А если я там напишу (5+6+4) вместо (15) он тоже считать это будет каждый кадр? Нет, такое вроде бы сворачивает.
>float(gl_FrontFacing)
Уже попробовал, ничего не меняется.
Я же написал, что я в фрагментном шейдере вовсе убрал обращение к gl_FrontFacing (считаю знак нормали прямо в геометрическом) - и фпс те же 37, выше уже не подняться.
>>728331
Так оно само считает обе ветви и подставляет результат похожим способом. Третий вариант совпадает по фпс с четвёртым (после замены 1 на 1.0).
>>728347
1 - Листья на ветках.
2 - 1660 ti. Вообще было бы очень интересно, чтобы кто-то в шейдере поставил такую же заглушку и потестил так же у него работает компилятор glsl или нет. У меня есть другой комп постарше, но карточек амд у меня вовсе нету, чтобы проверить что на них.
2.1 - Предположу что ситуация такая же как с openCL. Ты можешь один в один одинаковый код написать на openCL и на куде/glsl (в вычислительном шейдере) - и openCL будет работать где-то в 1.3 раза медленнее. С одинаковым размером локальных групп и всем остальным полностью совпадающим. Думаю что это всё из-за того, что у нвидии нет особой мотивации совершенствовать компилятор openCL, а вот куду они хотят вылизать до максимума, чтобы там не преобразовывалось в каждой нити 1 в 1.0 без какого-либо смысла и цели. А вычислительному шейдеру glsl просто повезло, видимо. Могу демку откопать, запустишь и заценишь сам.
4,6 - со стороны кода решил на всякий случай (внутри оператора присваивания проверку на -1 добавил), чтобы не натыкаться каждый раз при отладке шейдера - и юниформы тоже у себя кеширую, вряд ли драйвер сильно быстрее может это у себя сделать, даже если он этим занимается.
>А зачем вообще его вызывать каждый кадр?
Незачем. После компиляции стоило бы сохранить номера и использовать только их. Ради удобства написания хочется использовать символьные имена переменных - и оператор обращения по индексу неплохо подходит. То есть на каждый шейдер не создаётся свой класс и не загромождает код.
Можно через шаблоны в компайл-тайме сделать, чтобы constexpr-функция во всех местах подменяла строку-идентификатор на номер в массиве - поэтому я пока забью и буду гонять строку в рантайме, а потом переделаю если все более актуальные проблемы буду решены. Всё-равно это нужно только ради эстетической красоты что мол код не делает ничего лишнего, хеш одной строки посчитать это меньше микросекунды наверное. Разница как между 60 и 59.996
Хотя впрочем если бы там было land_shader.sun={..} - то это тоже более чем норм, но не хочется держать отдельный файл со списком юниформов для каждого шейдера, где нужно будет вручную вносить изменения после любого изменений состава юниформов. И ещё во всех местах придётся поменять тип шейдера с общего на специальный с нужным набором юниформов. Может быть на какой-то итоговой версии так сделаю, но на время разработки - нет, спасибо.
>>728430
Еще по поводу location для юниформов: если у тебя целевая платформа поддерживает OpenGL 4.3 или выше, или может быть чуть ниже, но содержит GL_ARB_explicit_uniform_location, то можно забить на glGetUniformLocation и использовать код типа layout(location = 1) uniform vec4 yobaColor;
Еще по поводу location для юниформов: если у тебя целевая платформа поддерживает OpenGL 4.3 или выше, или может быть чуть ниже, но содержит GL_ARB_explicit_uniform_location, то можно забить на glGetUniformLocation и использовать код типа layout(location = 1) uniform vec4 yobaColor;
>>728454
Благодарю, не знал. Прям от души благодарю, это решает многие неудобства, прямо сейчас перепишу всё.
Ещё в версии 2.1 не понимал зачем самплеру в шейдер необходимо передавать номер текстурного юнита, если это известно на стадии компиляции и там почти всегда 0/1/2, которые можно было бы константой в шейдере прописать. И очень обрадовался, когда это появилось в четвёртых версиях.
А про dsa вообще молчу - искренне не понимаю почему opengl с первых версий не сделан в куда более интуитивном dsa-стиле. По идее это же исключительно программная приблуда, которую можно полностью реализовать на программном уровне (что я собственно и делал поверх opengl в своих структурах) хоть в версии 1.1, верно? Точно не интересовался устройством opengl, но всегда казалось что глобальное состояние в opengl - это концепция только самого opengl, и железо об этом ничего не знает. Со стороны разрабов так вдвойне просто сделать возможность вместо смены глобального состояния и обращению к глобальному номеру текстуры связанным с GL_TEXTURE_2D добавить возможность обращаться просто по номеру текстуры.
Почему же тогда оно только в 4.5 появилась как часть стандарта?
4.3 вышло в 2012 году и поддерживается ещё более ранними карточками с драйверами помоложе. По ощущениям как будто ещё только вчера про геометрические шейдеры никто не слышал, а на половине компьютеров только ARB_vertex_program было. Так радовался, когда первую демку с фейерверком и отражениями сделал через асм-подобные шейдеры.
>>728433
Просто исчезают почему-то. Пробую ещё раз.
Благодарю, не знал. Прям от души благодарю, это решает многие неудобства, прямо сейчас перепишу всё.
Ещё в версии 2.1 не понимал зачем самплеру в шейдер необходимо передавать номер текстурного юнита, если это известно на стадии компиляции и там почти всегда 0/1/2, которые можно было бы константой в шейдере прописать. И очень обрадовался, когда это появилось в четвёртых версиях.
А про dsa вообще молчу - искренне не понимаю почему opengl с первых версий не сделан в куда более интуитивном dsa-стиле. По идее это же исключительно программная приблуда, которую можно полностью реализовать на программном уровне (что я собственно и делал поверх opengl в своих структурах) хоть в версии 1.1, верно? Точно не интересовался устройством opengl, но всегда казалось что глобальное состояние в opengl - это концепция только самого opengl, и железо об этом ничего не знает. Со стороны разрабов так вдвойне просто сделать возможность вместо смены глобального состояния и обращению к глобальному номеру текстуры связанным с GL_TEXTURE_2D добавить возможность обращаться просто по номеру текстуры.
Почему же тогда оно только в 4.5 появилась как часть стандарта?
4.3 вышло в 2012 году и поддерживается ещё более ранними карточками с драйверами помоложе. По ощущениям как будто ещё только вчера про геометрические шейдеры никто не слышал, а на половине компьютеров только ARB_vertex_program было. Так радовался, когда первую демку с фейерверком и отражениями сделал через асм-подобные шейдеры.
>>728433
Просто исчезают почему-то. Пробую ещё раз.
>>728629
Послушай совета мудрого, SDL уже есть, и не ищи ничего больше, ты уже пришел куда надо, максимум - imgui еще прикрутишь, если надо поверх графики интерфейс рисовать, и все. Да, поебаться придется, но только один раз, пока сделаешь из этого что-то типа шаблонного проекта со всеми настройками для сборки. Собственно SDL не надо компилить - инклюдишь и потом поставляешь со сборкой его библиотеку (а если под никсы, то там библиотека уже обязана быть в системе), а с imgui можно работать как с header-only.
Кстати, как компилишь под виндой? Cygwin/MSYS или MSVC?
Послушай совета мудрого, SDL уже есть, и не ищи ничего больше, ты уже пришел куда надо, максимум - imgui еще прикрутишь, если надо поверх графики интерфейс рисовать, и все. Да, поебаться придется, но только один раз, пока сделаешь из этого что-то типа шаблонного проекта со всеми настройками для сборки. Собственно SDL не надо компилить - инклюдишь и потом поставляешь со сборкой его библиотеку (а если под никсы, то там библиотека уже обязана быть в системе), а с imgui можно работать как с header-only.
Кстати, как компилишь под виндой? Cygwin/MSYS или MSVC?
>>728454
А это норм, что после этого перестаёт работать glGetUniformLocation, и всегда возвращает -1?
То есть если я указал номер явно, то по имени больше никак нельзя?
>layout(location = 1) uniform vec4 yobaColor
А это норм, что после этого перестаёт работать glGetUniformLocation, и всегда возвращает -1?
То есть если я указал номер явно, то по имени больше никак нельзя?
>>731520
А, забейте, у меня в начале шейдера слишком малая версия и включить явно расширение в шейдере я тоже забыл.
В итоге glGetUniformLocation перестаёт работать, но по номеру 2 юниформ записывает нормально, лол. Если поставить 430 или включить, то всё работает.
А, забейте, у меня в начале шейдера слишком малая версия и включить явно расширение в шейдере я тоже забыл.
В итоге glGetUniformLocation перестаёт работать, но по номеру 2 юниформ записывает нормально, лол. Если поставить 430 или включить, то всё работает.
>>728347
Потестил. Столбцы 1/2/3 - обращение через GetUniformLocation/обращение по номеру через layout/и взятия номера из обычной std::unordered_map<std::string,int>. Справа то же самое в цикле на 1000 повторов. Время в мс показано.
На второй картинке std::map, который при одном значении в таблице выигрывает.
В общем скорее всего если не упарываться constexp, то специально обученный код без всяких std::string для только максимального быстрого извлечения чисел из таблицы обгонит GetUniformLocation, но в остальном можно забить и юзать GetUniformLocation хоть в каждом кадре, если по какой-то причине впадлу прописать все числа на стадии компиляции.
Ну и 35 мкс для вызова 1000 GetUniformLocation+glUniform4f это энивей смешно. Разница как между 60.00 и 59.87 фпс. Для неадекватных 1000 вызовов.
>Пруфов не будет, где-то читал, что тривиальные части состояния (т.е. не буферы, и не то, что вычисляется только на видеокарте) современный драйвер хранит у себя и возвращает не запрашивая устройство
Потестил. Столбцы 1/2/3 - обращение через GetUniformLocation/обращение по номеру через layout/и взятия номера из обычной std::unordered_map<std::string,int>. Справа то же самое в цикле на 1000 повторов. Время в мс показано.
На второй картинке std::map, который при одном значении в таблице выигрывает.
В общем скорее всего если не упарываться constexp, то специально обученный код без всяких std::string для только максимального быстрого извлечения чисел из таблицы обгонит GetUniformLocation, но в остальном можно забить и юзать GetUniformLocation хоть в каждом кадре, если по какой-то причине впадлу прописать все числа на стадии компиляции.
Ну и 35 мкс для вызова 1000 GetUniformLocation+glUniform4f это энивей смешно. Разница как между 60.00 и 59.87 фпс. Для неадекватных 1000 вызовов.
>>731530
Не согласен.
Я кешировал значение glGetUniformLocation - и получал довольно ощутимый прирост производительности (около 10%).
Не согласен.
Я кешировал значение glGetUniformLocation - и получал довольно ощутимый прирост производительности (около 10%).
>>731635
В какой структуре?
std::unordered_map отстаёт в три раза от glGetUniformLocation, std::map в полтора раза - ты в самом деле ради этой хуиты что-то ещё писал?
Имеется ввиду ситуация, когда ты каждый кадр получаешь идентификатор из строки.
В какой структуре?
std::unordered_map отстаёт в три раза от glGetUniformLocation, std::map в полтора раза - ты в самом деле ради этой хуиты что-то ещё писал?
Имеется ввиду ситуация, когда ты каждый кадр получаешь идентификатор из строки.
>>731640
Я в int хранил
Типа такого:
при сборке шейдера
unsigned locPos = 0;
locPos = glGetUniformLocation(m_programId, "position");
И в мейнлупе:
glUniform4f(locPos , value.x, value.y, value.z, value.w);
Плюс сделал тест с 100к DIP (чтобы фпс было ниже 30 на моем железе) и сравнивал.
И кстати:
Не совсем неадекватно. Скорее реально. Как минимум каждому мешу нужно передавать матрицу трансформации каждый кадр. Видимых уникальных мешей может быть больше 1к. А к этому надо еще добавить дополнительные проходы рендера - deffered, тени, отражения и т.д. Там и до 10к может дойти
И это при условии что есть uniform constant и можно передавать множество переменных одним вызовом
>В какой структуре?
Я в int хранил
Типа такого:
при сборке шейдера
unsigned locPos = 0;
locPos = glGetUniformLocation(m_programId, "position");
И в мейнлупе:
glUniform4f(locPos , value.x, value.y, value.z, value.w);
Плюс сделал тест с 100к DIP (чтобы фпс было ниже 30 на моем железе) и сравнивал.
И кстати:
>Для неадекватных 1000 вызовов.
Не совсем неадекватно. Скорее реально. Как минимум каждому мешу нужно передавать матрицу трансформации каждый кадр. Видимых уникальных мешей может быть больше 1к. А к этому надо еще добавить дополнительные проходы рендера - deffered, тени, отражения и т.д. Там и до 10к может дойти
И это при условии что есть uniform constant и можно передавать множество переменных одним вызовом
>>731641
Ещё раз повторю, что имеется ввиду ситуация, когда ты каждый кадр получаешь идентификатор из строки.
А не когда ты тупо int хранишь.
Это вторая колонка в моей таблице, когда я вызываю только glUniform по номеру заданному через layout.
Речь о том, насколько быстра glGetUniformLocation если использовать её каждый кадр. Про производительность glUniform речи не шло.
Матрица - это один юниформ. Ты вызовешь для неё один glGetUniformLocation, а не 1000.
Кажется ты не читал, но там выше же было обсуждение, что по хорошему нужно вызвать glGetUniformLocation только один раз при загрузке шейдера - но суть была в том, что а если вдруг не сохранять идентификатор униформа, то достаточно ли оптимизирована glGetUniformLocation?
И да, более чем достаточна, и вызов glGetUniformLocation+glUniform всего в три раза отстаёт от glUniform, и занимает меньше микросекунды.
Ещё раз повторю, что имеется ввиду ситуация, когда ты каждый кадр получаешь идентификатор из строки.
А не когда ты тупо int хранишь.
>при сборке шейдера
Это вторая колонка в моей таблице, когда я вызываю только glUniform по номеру заданному через layout.
Речь о том, насколько быстра glGetUniformLocation если использовать её каждый кадр. Про производительность glUniform речи не шло.
>Не совсем неадекватно. Скорее реально.
Матрица - это один юниформ. Ты вызовешь для неё один glGetUniformLocation, а не 1000.
Кажется ты не читал, но там выше же было обсуждение, что по хорошему нужно вызвать glGetUniformLocation только один раз при загрузке шейдера - но суть была в том, что а если вдруг не сохранять идентификатор униформа, то достаточно ли оптимизирована glGetUniformLocation?
И да, более чем достаточна, и вызов glGetUniformLocation+glUniform всего в три раза отстаёт от glUniform, и занимает меньше микросекунды.
Сап, как начать вкатываться в огл? Хочу замутить одну штучку на lwjgl
Где брать экзамплы и как рендерить кубики/пирамидки/призмы/другие примитивы?
Где брать экзамплы и как рендерить кубики/пирамидки/призмы/другие примитивы?
>>731824
Learnopengl.com в оригинале или перевод на Хабре, гуглится
Learnopengl.com в оригинале или перевод на Хабре, гуглится
А может быть такое, что расширение в списке есть, но по факту не поддерживается или поддерживается не полностью?
Я отослал демку на тест знакомому, а она не работает - хотя я ничего редкого не использовал.
Дописал проверку расширений и версий - всё на месте. Выяснилась что проблема в простейшем геометрическом шейдере, который у меня даже на интеле работает. Какая-то неудачная версия драйвера с багом или почему такое может быть?
Я отослал демку на тест знакомому, а она не работает - хотя я ничего редкого не использовал.
Дописал проверку расширений и версий - всё на месте. Выяснилась что проблема в простейшем геометрическом шейдере, который у меня даже на интеле работает. Какая-то неудачная версия драйвера с багом или почему такое может быть?
>>732368
Да, драйвера с багами в принципе бывают, периодически натыкаюсь на сообщения типа "обновил драйвер на свежую версию и все заработало", еще бывают сообщения о регрессе, т.е. "поставил прошлогоднюю версию - работает, ставлю свежую - не работает", но это намного реже.
Да, драйвера с багами в принципе бывают, периодически натыкаюсь на сообщения типа "обновил драйвер на свежую версию и все заработало", еще бывают сообщения о регрессе, т.е. "поставил прошлогоднюю версию - работает, ставлю свежую - не работает", но это намного реже.
>>678945 (OP)
Ребят, мне лень писать на форумы, поэтому спрошу здесь. Сразу оговорюсь, у меня ноуст с линуксом и nvidia пашет только через optirun -b virtualgl. Так вот, почему в играх у меня fps проседает на 15 по сравнению с cpu, хотя по идеи так не должно быть, но при этом на отдельных шейдерах, например на шейдере моря, явно заметно, что nvidia даёт нехилый буст к перфомансу - картинка идеально плавная.
Есть ещё один прикол. У меня при загрузке этого шейдера сразу кулер начинает работать во всю мощь (и это хороший признак, значит видюха работает), а в игре кулера не слышно. Может такое быть, что разраб прост софтварно какие-то ограничения поставил и не даёт моей видеокарте разогнаться на полную мощь, или у меня драйвер/бридж/(хуй пойми чё ещё) не так работает?
Ребят, мне лень писать на форумы, поэтому спрошу здесь. Сразу оговорюсь, у меня ноуст с линуксом и nvidia пашет только через optirun -b virtualgl. Так вот, почему в играх у меня fps проседает на 15 по сравнению с cpu, хотя по идеи так не должно быть, но при этом на отдельных шейдерах, например на шейдере моря, явно заметно, что nvidia даёт нехилый буст к перфомансу - картинка идеально плавная.
Есть ещё один прикол. У меня при загрузке этого шейдера сразу кулер начинает работать во всю мощь (и это хороший признак, значит видюха работает), а в игре кулера не слышно. Может такое быть, что разраб прост софтварно какие-то ограничения поставил и не даёт моей видеокарте разогнаться на полную мощь, или у меня драйвер/бридж/(хуй пойми чё ещё) не так работает?
>>732524
Что значит "при загрузке этого шейдера? Шейдер разве не за милисекунду загружается?
На видеокарте есть разные блоки, и шейдер может упираться в какой-то не самый энергозатратный. Или например если у тебя узкое место - пересылка данных между карточкой и процессором, то возможно карточка будет довольно холодной (или наоборот, я без понятия - вдруг это самая горячая операция), потому что почти ничего не считает, а просто данные пересылает-принимает.
В общем не так уж невозможно написать шейдер, который будет выдавать 10 фпс и почти не прогревать карточку.
Нет, это шиза. Это не ограничения, а просто хуёвый код, скорее.
Что значит "при загрузке этого шейдера? Шейдер разве не за милисекунду загружается?
>а в игре кулера не слышно
На видеокарте есть разные блоки, и шейдер может упираться в какой-то не самый энергозатратный. Или например если у тебя узкое место - пересылка данных между карточкой и процессором, то возможно карточка будет довольно холодной (или наоборот, я без понятия - вдруг это самая горячая операция), потому что почти ничего не считает, а просто данные пересылает-принимает.
В общем не так уж невозможно написать шейдер, который будет выдавать 10 фпс и почти не прогревать карточку.
>Может такое быть, что разраб прост софтварно какие-то ограничения поставил
Нет, это шиза. Это не ограничения, а просто хуёвый код, скорее.
>>732632
Ну при работе имею ввиду. Но к слову об этой могу сказать, что когда я сидел на debian'е, тот же optirun давал небольшой прирост в фпс, ну или как минимум уж точно не ухудшал производительность. За всю подноготную не шарю этих графических api не шарю, но насколько я вычитал virtualgl работает не напрямую, а ориентирован как клиент-серверное приложение, мб это даёт свой оверхед. Хотя может ты за линуск и не шаришь, конечно, чё я тебя гружу
>при загрузке
Ну при работе имею ввиду. Но к слову об этой могу сказать, что когда я сидел на debian'е, тот же optirun давал небольшой прирост в фпс, ну или как минимум уж точно не ухудшал производительность. За всю подноготную не шарю этих графических api не шарю, но насколько я вычитал virtualgl работает не напрямую, а ориентирован как клиент-серверное приложение, мб это даёт свой оверхед. Хотя может ты за линуск и не шаришь, конечно, чё я тебя гружу
>>732638
vsync включил?
vsync включил?
Ананасы, есть два вершинных буфера: 1 для вершин и их цвета (чанки карты), 2 для текстурных координат (у всех чанков одинаковые).
Как бы сделать так чтобы буфер для текстурных координат использовался для рисования всех чанков, а то выходит что один рисуется нормально, а остальные нет.
Как бы сделать так чтобы буфер для текстурных координат использовался для рисования всех чанков, а то выходит что один рисуется нормально, а остальные нет.
19 Кб, 1532x459>>733176
Показывай код.
https://pastebin.com/caw3xBVv
У меня всё работает как по маслу, буфер цветов отлично работает на других координатах. Просто замени glColorPointer на glTexCoordPointer или, вернее, на glVertexAttribPointer.
glEnableClientState не нужен в новых версиях что ли? Я его прописал думая, что он нужен из-за легаси - а у меня программа перестала вообще хоть что-то показывать после disable, как будто он изначально был включён для всех пунктов.
Показывай код.
https://pastebin.com/caw3xBVv
У меня всё работает как по маслу, буфер цветов отлично работает на других координатах. Просто замени glColorPointer на glTexCoordPointer или, вернее, на glVertexAttribPointer.
glEnableClientState не нужен в новых версиях что ли? Я его прописал думая, что он нужен из-за легаси - а у меня программа перестала вообще хоть что-то показывать после disable, как будто он изначально был включён для всех пунктов.
>>733190
А не должно быть? Как это вообще работать должно, если тебе не хватает текстурных координат?
Я и говорю код показывай.
А не должно быть? Как это вообще работать должно, если тебе не хватает текстурных координат?
Я и говорю код показывай.
>>733192
В первом буфере 145 вершин на каждый чанк т.е. 32на32 чанка это 21025 вершин
Во втором только 145 текстурных координат.
Соответственно из первого буфера и второго буфера считывается 145 вершин нормально, а дальше выходит хуйня.
Что тебе код-то даст? Ты же нихера в этом не понимаешь всё равно.
В первом буфере 145 вершин на каждый чанк т.е. 32на32 чанка это 21025 вершин
Во втором только 145 текстурных координат.
Соответственно из первого буфера и второго буфера считывается 145 вершин нормально, а дальше выходит хуйня.
Что тебе код-то даст? Ты же нихера в этом не понимаешь всё равно.
Анон, помоги понять суть VBO. Насколько я понимаю на данный момент, VBO собой представляет некий массив с какими угодно данными о вершинах. Пока, насколько я понял, пайплайн с его участием происходит так:
1) Создаётся в OpenGL context некий абстрактный буфер общего назначения
2) Этот буфер общего назначения привязывается к GL_ARRAY_BUFFER, чтоб второй ссылался на первый
3) GL_ARRAY_BUFFER (его бэкер) функцией glBufferData заполняются данными и высылаются в реальный VBO в видеопамяти
Правильно ли я понимаю на данный момент, как это происходит?
1) Создаётся в OpenGL context некий абстрактный буфер общего назначения
2) Этот буфер общего назначения привязывается к GL_ARRAY_BUFFER, чтоб второй ссылался на первый
3) GL_ARRAY_BUFFER (его бэкер) функцией glBufferData заполняются данными и высылаются в реальный VBO в видеопамяти
Правильно ли я понимаю на данный момент, как это происходит?
>>733196
Я то понимаю как раз, может быть не в этом, но в логике работы opengl и что он может/не может.
Поучусь. Без подкола - почему бы не смотреть на чужой код и не черпать оттуда удачные идеи при любой возможности?
Забинди текстурные координаты в начале, и бинди заново вершины указывая смещение последним аргументом в glVertexAttribPointer, и вызывай glDrawArrays на каждый чанк.
Или можешь сделать ssbo с текстурными координатами, а в шейдере вручную их доставать для нужного индекса, который вроде бы через gl_VertexID поступен.
Я то понимаю как раз, может быть не в этом, но в логике работы opengl и что он может/не может.
>Что тебе код-то даст? Ты же нихера в этом не понимаешь всё равно.
Поучусь. Без подкола - почему бы не смотреть на чужой код и не черпать оттуда удачные идеи при любой возможности?
Забинди текстурные координаты в начале, и бинди заново вершины указывая смещение последним аргументом в glVertexAttribPointer, и вызывай glDrawArrays на каждый чанк.
Или можешь сделать ssbo с текстурными координатами, а в шейдере вручную их доставать для нужного индекса, который вроде бы через gl_VertexID поступен.
>>733201
VBO просто хранит данные и всё. Через glVertexAttribPointer ты указывает как эти данные интерпретировать.
Соответственно, создаёшь vertexarrayobject и биндишь его.
Создаёшь vbo на самом деле ты можешь создать его, залить в него данные когда угодно, биднишь, заливаешь данные.
Скажем, этот буфер хранит Vertex'ы некоего куба. Вершина состоит из vec3 позиция, vec2 координаты текстур, vec4 цвет.
glEnableVertexAttribArray( 0 ) // в шейдере это будет layout(location = 0) in vec3 inVertex;
glVertexAttribPointer( 0, sizeof( vec3 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), 0 );
glEnableVertexAttribArray( 1 ) // в шейдере это будет layout(location = 1) in vec2 inTexCoord;
glVertexAttribPointer( 1, sizeof( vec2 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), sizeof( vec3 ) );
glEnableVertexAttribArray( 2 ) // в шейдере это будет layout(location = 2) in vec4 inColor;
glVertexAttribPointer( 2, sizeof( vec4 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), sizeof( vec3 ) + sizeof( vec2 );
sizeof( Vertex ) это sizeof( vec3 ) + sizeof( vec2 ) + sizeof( vec4 )
Последний параметр в glVertexAttribPointer, это отступ в байтах от начала Vertex. Чтобы не ебаться с этим отсуптом, просто заранее пишешь в какие-то переменные отступ типа так:
https://pastebin.com/iQu2BDBX
Короче, говоря: VAO нужен чтобы запомнить какие атрибуты ты включил или отключил для какого буфера.
При биндинге VAO он сам биндит VBO и EBO (индексный буфер), устанавливает атрибуты и всё.
И тебе останется включить шейдер, забиндить текстуры и рисовать.
VBO просто хранит данные и всё. Через glVertexAttribPointer ты указывает как эти данные интерпретировать.
Соответственно, создаёшь vertexarrayobject и биндишь его.
Создаёшь vbo на самом деле ты можешь создать его, залить в него данные когда угодно, биднишь, заливаешь данные.
Скажем, этот буфер хранит Vertex'ы некоего куба. Вершина состоит из vec3 позиция, vec2 координаты текстур, vec4 цвет.
glEnableVertexAttribArray( 0 ) // в шейдере это будет layout(location = 0) in vec3 inVertex;
glVertexAttribPointer( 0, sizeof( vec3 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), 0 );
glEnableVertexAttribArray( 1 ) // в шейдере это будет layout(location = 1) in vec2 inTexCoord;
glVertexAttribPointer( 1, sizeof( vec2 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), sizeof( vec3 ) );
glEnableVertexAttribArray( 2 ) // в шейдере это будет layout(location = 2) in vec4 inColor;
glVertexAttribPointer( 2, sizeof( vec4 ), GL_FLOAT, GL_FALSE, sizeof( Vertex ), sizeof( vec3 ) + sizeof( vec2 );
sizeof( Vertex ) это sizeof( vec3 ) + sizeof( vec2 ) + sizeof( vec4 )
Последний параметр в glVertexAttribPointer, это отступ в байтах от начала Vertex. Чтобы не ебаться с этим отсуптом, просто заранее пишешь в какие-то переменные отступ типа так:
https://pastebin.com/iQu2BDBX
Короче, говоря: VAO нужен чтобы запомнить какие атрибуты ты включил или отключил для какого буфера.
При биндинге VAO он сам биндит VBO и EBO (индексный буфер), устанавливает атрибуты и всё.
И тебе останется включить шейдер, забиндить текстуры и рисовать.
>>733219
Спасибо за разъяснение! Но есть один непонятный момент: вот этот "биндинг", который запоминает VAO. Никак в толк не возьму, что именно он запоминает. Насколько я понимаю, биндинг VBO - это просто создание пустого буфера и биндинг его на GL_ARRAY_BUFFER. Какой из этих шагов воспроизводит VAO?
Спасибо за разъяснение! Но есть один непонятный момент: вот этот "биндинг", который запоминает VAO. Никак в толк не возьму, что именно он запоминает. Насколько я понимаю, биндинг VBO - это просто создание пустого буфера и биндинг его на GL_ARRAY_BUFFER. Какой из этих шагов воспроизводит VAO?
>>733391
Какие VBO ты забиндил, какие атрибуты включены или включены, и что они означают.
VBO это vertex buffer object, да это GL_ARRAY_BUFFER.
Создаётся он функцией glGenBuffer. Биндинг это вызов glBindBuffer.
Биндинг glBindBuffer
Ты один VBO можешь использовать хоть в 10 разных VAO.
> икак в толк не возьму, что именно он запоминает.
Какие VBO ты забиндил, какие атрибуты включены или включены, и что они означают.
> Насколько я понимаю, биндинг VBO - это просто создание пустого буфера и биндинг его на GL_ARRAY_BUFFER
VBO это vertex buffer object, да это GL_ARRAY_BUFFER.
Создаётся он функцией glGenBuffer. Биндинг это вызов glBindBuffer.
> Какой из этих шагов воспроизводит VAO?
Биндинг glBindBuffer
Ты один VBO можешь использовать хоть в 10 разных VAO.
>>733395
Вот этот момент непонятен. Если есть один VBO - новый пустой буфер, забинденый на GL_ARRAY_BUFFER. Что там можно запомнить? Ведь данные мы заносим дальше через glBufferData, а на момент glBindBuffer в GL_ARRAY_BUFFER пусто.
>Какие VBO ты забиндил
Вот этот момент непонятен. Если есть один VBO - новый пустой буфер, забинденый на GL_ARRAY_BUFFER. Что там можно запомнить? Ведь данные мы заносим дальше через glBufferData, а на момент glBindBuffer в GL_ARRAY_BUFFER пусто.
[/b]
36 Кб, 590x799>>733397
Биндинг это как бы его включение. Шейдеры будут читать данные из включённых буферов, если ты конечно правильно настроил аттрибуты (glEnableVertexAttribArray и glVertexAttribPointer)
Что ты включил конкретно вот этот вот буфер и что аттрибуты у него вот такие.
Данные тут не причём. Если же буфер пустой, то понятно что ничего не нарисуется.
Можешь считать что VAO это просто автоматизация действий: биндинг буфера, включение и установка атриубтов и всё.
Короче, вот тебе картинка с псевдокодом.
Что обведено красным VAO запоминает и делает за тебя каждый раз.
Биндинг это как бы его включение. Шейдеры будут читать данные из включённых буферов, если ты конечно правильно настроил аттрибуты (glEnableVertexAttribArray и glVertexAttribPointer)
> Что там можно запомнить?
Что ты включил конкретно вот этот вот буфер и что аттрибуты у него вот такие.
Данные тут не причём. Если же буфер пустой, то понятно что ничего не нарисуется.
Можешь считать что VAO это просто автоматизация действий: биндинг буфера, включение и установка атриубтов и всё.
Короче, вот тебе картинка с псевдокодом.
Что обведено красным VAO запоминает и делает за тебя каждый раз.
>>733402
То есть правильно ли я понял, что VAO за меня создаст пустой буфер, и его уже забиндит на GL_ARRAY_BUFFER?
То есть правильно ли я понял, что VAO за меня создаст пустой буфер, и его уже забиндит на GL_ARRAY_BUFFER?
>>733405
Ну а где он возьмёт буфер, который забиндит функцией glBindBuffer? Я это пытаюсь понять.
Ну а где он возьмёт буфер, который забиндит функцией glBindBuffer? Я это пытаюсь понять.
>>733406
Внутри драйвера оглы хранится полное внутреннее состояние, которое в тч включает в себя так называемые точки подключения/биндинги. Назначение этим биндингам тех или иных буферов можно представить как простое присваивание 'указателя' на буфер. Vao в этом случае собственно и сохраняет часть внутреннего состояния, в частности и значения 'указателей' на подключённые буфера. В этом его основная польза - вся настроечная инфа относительно того, какие буферы к каким биндингам подключены и в каком формате из них нужно читать, содержится в одной сущности, которую активировать проще, чем всё по отдельности.
Внутри драйвера оглы хранится полное внутреннее состояние, которое в тч включает в себя так называемые точки подключения/биндинги. Назначение этим биндингам тех или иных буферов можно представить как простое присваивание 'указателя' на буфер. Vao в этом случае собственно и сохраняет часть внутреннего состояния, в частности и значения 'указателей' на подключённые буфера. В этом его основная польза - вся настроечная инфа относительно того, какие буферы к каким биндингам подключены и в каком формате из них нужно читать, содержится в одной сущности, которую активировать проще, чем всё по отдельности.
88 Кб, 1072x1080Здравствуйте, господа математики.
Я к вам с вопросом. До этого никогда не писал на низкоуровневых библиотеках, Я C# разработчик. Извините, если вопрос не совсем по адресу.
Я ищу решение следующей проблемы. Опишу подробнее.
У меня есть плата raspberry Pi с установленным линуксом, ещё основная проблема это Arm64.
И мне нужно написать небольшую прогу, которая
1. пару раз в минуту обращается наружу хттп гет запросами, откуда получает json, парсит, и получает необходимые обьекты. И из них В общем, строки для последующей работы.
2. Полученные строки необходимо плавно(линейная интерполяция) рисовать и двигать по экрану, тем самым создавая такой красивый заанимированный графический интерфейсинтерфейс бегущих строк
Размер окна, в котором это нужно рисовать маленький(200х300).
Я до этого поста пробовал сделать на wpF+avalonia(кроссплатформенный wpF), оно работает, но бывают частые лаги. Я замерил интервалы отрисовки, когда вызывался Invalid окна, 90% кадров рисовались отлично с задержкой 15-16миллисекунд, а 10% кадров с задержкой 30 миллисекунд. В результате этих лагов выглядит криво. Как я гуглил, у многих такая же проблема, и разрабы avalonia пока не исправляют.
Мне посоветовали посмотреть в сторону SDL2, и я нашел нугет пакет для .Net core, но опыта в нём, соответственно, ноль. Опыта работы с линуксом околонуля.
Я бы написал все прекрасно на юнити и не парился по всему этому поводу, но в юнити нельзя собрать для линукс arm64.
Собственно тут я вижу два стула.
1. Подскажите, пожалуйста, какими средствами это лучше и быстрее сделать.
2. Если у кого-то есть опыт в этом деле и время быстро с этим помочь(именно линукс и именно arm64), то может договоримся за оплату.
Я к вам с вопросом. До этого никогда не писал на низкоуровневых библиотеках, Я C# разработчик. Извините, если вопрос не совсем по адресу.
Я ищу решение следующей проблемы. Опишу подробнее.
У меня есть плата raspberry Pi с установленным линуксом, ещё основная проблема это Arm64.
И мне нужно написать небольшую прогу, которая
1. пару раз в минуту обращается наружу хттп гет запросами, откуда получает json, парсит, и получает необходимые обьекты. И из них В общем, строки для последующей работы.
2. Полученные строки необходимо плавно(линейная интерполяция) рисовать и двигать по экрану, тем самым создавая такой красивый заанимированный графический интерфейсинтерфейс бегущих строк
Размер окна, в котором это нужно рисовать маленький(200х300).
Я до этого поста пробовал сделать на wpF+avalonia(кроссплатформенный wpF), оно работает, но бывают частые лаги. Я замерил интервалы отрисовки, когда вызывался Invalid окна, 90% кадров рисовались отлично с задержкой 15-16миллисекунд, а 10% кадров с задержкой 30 миллисекунд. В результате этих лагов выглядит криво. Как я гуглил, у многих такая же проблема, и разрабы avalonia пока не исправляют.
Мне посоветовали посмотреть в сторону SDL2, и я нашел нугет пакет для .Net core, но опыта в нём, соответственно, ноль. Опыта работы с линуксом околонуля.
Я бы написал все прекрасно на юнити и не парился по всему этому поводу, но в юнити нельзя собрать для линукс arm64.
Собственно тут я вижу два стула.
1. Подскажите, пожалуйста, какими средствами это лучше и быстрее сделать.
2. Если у кого-то есть опыт в этом деле и время быстро с этим помочь(именно линукс и именно arm64), то может договоримся за оплату.
34 Кб, 401x300>>733429
Выглядит как легкая задачка для Lazarus Free Pascal (это намёк на гуглинг, да)
> 1. пару раз в минуту обращается наружу хттп гет запросами, откуда получает json, парсит, и получает необходимые обьекты. И из них В общем, строки для последующей работы.
> 2. Полученные строки необходимо плавно(линейная интерполяция) рисовать и двигать по экрану, тем самым создавая такой красивый заанимированный графический интерфейсинтерфейс бегущих строк
> Размер окна, в котором это нужно рисовать маленький(200х300).
> Если у кого-то есть опыт в этом деле и время быстро с этим помочь
Выглядит как легкая задачка для Lazarus Free Pascal (это намёк на гуглинг, да)
>>733552
Спасибо, теперь понятнее. То есть я вызываю VAO, рисую с использованием его буфера и атрибутов, после рисования буфер очищается, через некоторое время я снова вызываю VAO и снова рисую в том же самом буфере и с теми же атрибутами.
Спасибо, теперь понятнее. То есть я вызываю VAO, рисую с использованием его буфера и атрибутов, после рисования буфер очищается, через некоторое время я снова вызываю VAO и снова рисую в том же самом буфере и с теми же атрибутами.
>>733621
У тебя в одном предложении три раза используется слово буфер, не знаю точно что ты имел в виду, так как это многозначное понятие в рамках OpenGL, его надо уточнять: буфер вершин, элементов, юниформов, кадра, и т.д.
Схема примерно такая должна быть:
1) сгенерировать VAO и подключить его, сгенерировать VBO и опционально буфер элементов, если ты используешь индексы вершин, и подключить их.
2) если у тебя статическая геометрия, то заполни VBO сейчас, либо же только задай его размер, а вместо данных будет нулевой указатель, и не забудь сразу задать указатели на атрибуты вершин (glVertexAttribPointer, glEnableVertexAttribArray).
3) далее можешь отключить только VAO (glBindVertexArray(0)) и делать все остальное.
Затем в каждом кадре:
1) подключаешь только VAO;
2) если геометрия динамическая, то заливаешь ее в текущий VBO (который уже подключен через VAO) - glBufferData, glBufferSubData (считается быстрее всего, если обновляешь небольшую часть буфера вершин), glMapBuffer (будет слоупочно), если статическая, то ничего не делаешь - она уже в буфере вершин;
3) подключаешь шейдерную программу, заполняешь юниформы;
4) рисуешь - glDraw-чего-то-там в зависимости от того, как именно рисуешь.
Если ты имел в виду еще где-то GL_FRAMEBUFFER, то это отдельная тема.
У тебя в одном предложении три раза используется слово буфер, не знаю точно что ты имел в виду, так как это многозначное понятие в рамках OpenGL, его надо уточнять: буфер вершин, элементов, юниформов, кадра, и т.д.
Схема примерно такая должна быть:
1) сгенерировать VAO и подключить его, сгенерировать VBO и опционально буфер элементов, если ты используешь индексы вершин, и подключить их.
2) если у тебя статическая геометрия, то заполни VBO сейчас, либо же только задай его размер, а вместо данных будет нулевой указатель, и не забудь сразу задать указатели на атрибуты вершин (glVertexAttribPointer, glEnableVertexAttribArray).
3) далее можешь отключить только VAO (glBindVertexArray(0)) и делать все остальное.
Затем в каждом кадре:
1) подключаешь только VAO;
2) если геометрия динамическая, то заливаешь ее в текущий VBO (который уже подключен через VAO) - glBufferData, glBufferSubData (считается быстрее всего, если обновляешь небольшую часть буфера вершин), glMapBuffer (будет слоупочно), если статическая, то ничего не делаешь - она уже в буфере вершин;
3) подключаешь шейдерную программу, заполняешь юниформы;
4) рисуешь - glDraw-чего-то-там в зависимости от того, как именно рисуешь.
Если ты имел в виду еще где-то GL_FRAMEBUFFER, то это отдельная тема.
>>733488
Открыл в гугле.
Там пизданешься с ума раньше, чем на винде соберешь в этом лазарусе для линукса арм64.
Открыл в гугле.
Там пизданешься с ума раньше, чем на винде соберешь в этом лазарусе для линукса арм64.
>>733668
Таки да. Программирование - непростая штука. И программистам не просто так 300КК/нсек плотют. Хоть паскаль, хоть си/плюсы, хоть лисп, хоть фортран, если ты не шаришь - ты соснёшь.
Копи деньги на оплату специалиста.
Таки да. Программирование - непростая штука. И программистам не просто так 300КК/нсек плотют. Хоть паскаль, хоть си/плюсы, хоть лисп, хоть фортран, если ты не шаришь - ты соснёшь.
Копи деньги на оплату специалиста.
>>733668
У тебя там линукс крутится с иксами или без? По-разному можно сделать.
У тебя там линукс крутится с иксами или без? По-разному можно сделать.
>>733429
И всего-то?
Библиотека curl, cjson, stb_truetype (можно и freetype2), рисовать самым простым опенглом, а компилировать прямо на малинке.
У тебя же там иксы?
Незнаю, отчего могут быть лаги, но вряд ли это что-то нерешаемое.
Если готов оплатить, то могу сделать долларов за 40-80, кидай почту или телеграм.
И всего-то?
Библиотека curl, cjson, stb_truetype (можно и freetype2), рисовать самым простым опенглом, а компилировать прямо на малинке.
У тебя же там иксы?
Незнаю, отчего могут быть лаги, но вряд ли это что-то нерешаемое.
Если готов оплатить, то могу сделать долларов за 40-80, кидай почту или телеграм.
Как рендерить жидкости? Не плоские поверхности с волнами, а симуляции, чтоб она перетекала через всякие каналы и прочие отверстия
>>733672
Рыночек порешал прост, но по своей сути программисты - это обычные ремесленники, на ступень выше чёрнорабочих
>300кк/нсек
Рыночек порешал прост, но по своей сути программисты - это обычные ремесленники, на ступень выше чёрнорабочих
>>733860
Повар тоже обычный ремесленник. Попробуй устройся в элитный ресторан шефом. Жду через неделю с пруфами.
> по своей сути программисты - это обычные ремесленники
Повар тоже обычный ремесленник. Попробуй устройся в элитный ресторан шефом. Жду через неделю с пруфами.
>>733861
Я так понял это только для тех у кого карта от нвидии и кто может в куду, а есть симуляции для нищих? Мне фотореализм и абсолютная физическая достоверность не нужны. Если бы было что-то как в 2д симуляторах песка, только в полигонах - я был бы счастлив
Я так понял это только для тех у кого карта от нвидии и кто может в куду, а есть симуляции для нищих? Мне фотореализм и абсолютная физическая достоверность не нужны. Если бы было что-то как в 2д симуляторах песка, только в полигонах - я был бы счастлив
>>733919
Можешь попробовать загуглить "SPH fluid", там простой код - если частицы по равномерной сетке раскидать, то на современном процессоре можно 50-200к в 60 фпс получить.
По этому же запросу есть демки, где из частиц прям поверхность получают - но как это делается я не знаю.
Можешь попробовать загуглить "SPH fluid", там простой код - если частицы по равномерной сетке раскидать, то на современном процессоре можно 50-200к в 60 фпс получить.
По этому же запросу есть демки, где из частиц прям поверхность получают - но как это делается я не знаю.
>>678945 (OP)
Существует понятный гайд по установке glfw на линух?
Если нужно с исходников компилить то в какой директории? Сначала cmake или make? Где потом искать и подключать includ'ы?
Существует понятный гайд по установке glfw на линух?
Если нужно с исходников компилить то в какой директории? Сначала cmake или make? Где потом искать и подключать includ'ы?
>>734363
А там есть какие-то сложности? Сделай build каталог на уровне каталога с сырцами
cd build
cmake ../sources
make install
Возможно что-то подшаманить в конфигурации, выбрать install каталог.
А там есть какие-то сложности? Сделай build каталог на уровне каталога с сырцами
cd build
cmake ../sources
make install
Возможно что-то подшаманить в конфигурации, выбрать install каталог.
>>734508
Если install_path оставишь системным, то никакой, достаточно того, как в примерах на сайте либо показано, т.е. <GLFW/glfw3.h>
Вообще на сайте либы есть компайл-гайды нормальные. Или ингришь совсем не осилишь?
Если install_path оставишь системным, то никакой, достаточно того, как в примерах на сайте либо показано, т.е. <GLFW/glfw3.h>
Вообще на сайте либы есть компайл-гайды нормальные. Или ингришь совсем не осилишь?
>>734363
Госпаде, я сейчас сижу на винде только потому что рабочий софт только на ней, и радуюсь, что в кои-то веки в винде MSYS работает почти искаропки (ы-ы-ы, pacman, без всяких сраных WSL, виндовые бинарники с легким привкусом линуха, ы-ы-ы), когда в линухах уже давно все было сделано как надо - поставил либу, если заголовки в отдельном пакете, то поставил и их, и просто все работает. А тут кто-то дрочит ручную сборку достаточно распространенной либы в линухах и спрашивает про пути. Маня, apt/yum/pacman/или-что-там-у-тебя сделал один раз и просто все работает, никаких путей не надо, не надо никаких cmake/make/zalupacake дрочить, codelite какой-нибудь навернул, сказал ему gcc найти на машине, зависимости из пакетного менеджера докинул, и ПРОСТО ВСЕ РАБОТАЕТ.
Госпаде, я сейчас сижу на винде только потому что рабочий софт только на ней, и радуюсь, что в кои-то веки в винде MSYS работает почти искаропки (ы-ы-ы, pacman, без всяких сраных WSL, виндовые бинарники с легким привкусом линуха, ы-ы-ы), когда в линухах уже давно все было сделано как надо - поставил либу, если заголовки в отдельном пакете, то поставил и их, и просто все работает. А тут кто-то дрочит ручную сборку достаточно распространенной либы в линухах и спрашивает про пути. Маня, apt/yum/pacman/или-что-там-у-тебя сделал один раз и просто все работает, никаких путей не надо, не надо никаких cmake/make/zalupacake дрочить, codelite какой-нибудь навернул, сказал ему gcc найти на машине, зависимости из пакетного менеджера докинул, и ПРОСТО ВСЕ РАБОТАЕТ.
>>734578
И будет твоя прога только через msys.dll работать и фризить, такие пердоли...
И будет твоя прога только через msys.dll работать и фризить, такие пердоли...
>>734747
git только без префикса
git только без префикса
Может ли кто-то прояснить про bindless-текстуры? Вот я читаю то, что записано в вики у кроноса:
То есть получается, что я не могу просто взять и сделать все свои текстуры сразу доступными для bindless, и надо фактически каждый кадр еще вычислять, какие из них будут использоваться, а какие нет, иначе драйвер может в любой момент сказать "чота памяти маловато", так?
>Before a handle can be used in a bindless operation, the data associated with it must be made resident.
>Note that a handle is what is being made resident, not a texture. As such, if you have handles that refer to the same texture's storage, making one resident is not sufficient to use one of the other handles. Residency affects more than just the image data.
>Conceptually, image data being resident means that it lives within GPU-accessible memory directly. The amount of storage available for resident images/textures may be less than the total storage for textures that is available. As such, you should attempt to minimize the time a texture spends being resident. Do not attempt to take steps like making textures resident/unresident every frame or something. But if you are finished using a texture for some time, make it unresident.
То есть получается, что я не могу просто взять и сделать все свои текстуры сразу доступными для bindless, и надо фактически каждый кадр еще вычислять, какие из них будут использоваться, а какие нет, иначе драйвер может в любой момент сказать "чота памяти маловато", так?
>>736035
Можешь, если они все в видеопамять влазят.
Если ты стримингом текстур не занимаешься, просто забей и все делай резидентными.
Можешь, если они все в видеопамять влазят.
Если ты стримингом текстур не занимаешься, просто забей и все делай резидентными.
>>736091
Понял, спасибо.
Понял, спасибо.
Только начал с этой хуйней разбираться, концептуально не понимаю.
Есть значит массив треугольников. Я его загоняю в VBO и они рисуются на своих координатах и все хорошо. Теперь я хочу двигать только один элемент из этого массива, и насколько я понял, менять координаты прямо в VBO - хуевая идея, надо как-то через вертексный шейдер и матрицу переноса в юниформу передавать. Но блядь как если у меня все треугольники одним дравколлом рисуются, и соответственно в шейдер я могу передать только одну матрицу, одинаковую для всех треугольников.
Есть значит массив треугольников. Я его загоняю в VBO и они рисуются на своих координатах и все хорошо. Теперь я хочу двигать только один элемент из этого массива, и насколько я понял, менять координаты прямо в VBO - хуевая идея, надо как-то через вертексный шейдер и матрицу переноса в юниформу передавать. Но блядь как если у меня все треугольники одним дравколлом рисуются, и соответственно в шейдер я могу передать только одну матрицу, одинаковую для всех треугольников.
>>738128
В зависимости от ситуации
1) Каждый треугольник - отдельный vbo, передавай матрицу и двигай как надо
2) Записывай в vbo новые координаты, при изменении
В зависимости от ситуации
1) Каждый треугольник - отдельный vbo, передавай матрицу и двигай как надо
2) Записывай в vbo новые координаты, при изменении
>>738133
Да проблема в том, шо то што это хуйня.
1. Отдельные vbo - дохуя дравколлов.
2. Менять vbo - я хочу двигать объекты мышкой, получатеся буфер будет очень часто обновляться и тормозить карточку, не оптимально. И в интернетах пишут, что такие вещи надо матрицами делать.
Я нагуглили что-то про Instancing, но там либо ограниченное кол-во объектов, либо переносы тоже надо будет в буфер заносить и его менять
Это все варианты решения проблемы, тут же сверхразумы есть?
Да проблема в том, шо то што это хуйня.
1. Отдельные vbo - дохуя дравколлов.
2. Менять vbo - я хочу двигать объекты мышкой, получатеся буфер будет очень часто обновляться и тормозить карточку, не оптимально. И в интернетах пишут, что такие вещи надо матрицами делать.
Я нагуглили что-то про Instancing, но там либо ограниченное кол-во объектов, либо переносы тоже надо будет в буфер заносить и его менять
Это все варианты решения проблемы, тут же сверхразумы есть?
>>738139
Говоря про треугольник, ты же упрощаешь задачу.
По факту у меня могут быть разные 3д модели, с миллионами треугольников. Совершенно логично, что каждая модель это отдельный vao/vbo со своими матрицами, и чтоб передвинуть одну модель относительно другой нужно менять ей матрицу.
Или у тебя единая сложная (допустим 2д) геометрия из отдельных треугольников, меняющая свою форму и количество треугольников. Тут никуда не деться от перегенерации vao.
Если у тебя куча однотипных моделей, ну инстансинг вполне пойдет, но опять же для каждого перемещения модели, придется менять данные в буфере, может только частично через glBufferSubData. Если моделей дофига, сделаешь несколько drawcallов.
Прямо таки стремиться к единственному drawcallу, конечно можно, но без фанатизма.
Говоря про треугольник, ты же упрощаешь задачу.
По факту у меня могут быть разные 3д модели, с миллионами треугольников. Совершенно логично, что каждая модель это отдельный vao/vbo со своими матрицами, и чтоб передвинуть одну модель относительно другой нужно менять ей матрицу.
Или у тебя единая сложная (допустим 2д) геометрия из отдельных треугольников, меняющая свою форму и количество треугольников. Тут никуда не деться от перегенерации vao.
Если у тебя куча однотипных моделей, ну инстансинг вполне пойдет, но опять же для каждого перемещения модели, придется менять данные в буфере, может только частично через glBufferSubData. Если моделей дофига, сделаешь несколько drawcallов.
Прямо таки стремиться к единственному drawcallу, конечно можно, но без фанатизма.
>>738139
Какая-то дичь. Я не заметил заметной разницы между тем, чтобы рисовать из памяти, и тем, чтобы каждый кадр полностью обновлять все вершины в vbo. И при этом ты можешь рисовать несколько сотен тысяч вершин из оперативы, и любая карточка моложе десяти лет это скушает в реальном времени. А передавать можно только изменённые.
Вершины это почти последнее место, которое станет узким местом производительности.
Можешь для каждой вершины хранить индекс соответствующего объекта, а множество матриц преобразования хранить в ssbo (или ubo, но его я никогда не использовал - точно не обещаю что он подходит).
Один дравколл, при движении объекта меняется только одна матрица. Можно хоть каждый кадр полностью перезаливать в буфер все матрицы.
Просто по количеству объектов смотри. Если меньше тысячи разных vbo, то я бы их так и оставил - почему нет? Если больше и для каждого своя матрица, и при этом каждый объект состоит из малого числа редко обновляющихся вершин (которые привлекательно посчитать один раз поменяв vbo) - то уже замерял бы производительность, так ли медленны эти несколько тысяч вызовов и нужно ли их менять на glBufferSubData.
У меня во всех случаях производительность упирается в фрагментные шейдеры, который кушают 90% времени - а во всех остальных местах можно что угодно делать любым подходом, и это почти никак не влияет на производительность.
>я хочу двигать объекты мышкой, получается буфер будет очень часто обновляться и тормозить карточку, не оптимально
Какая-то дичь. Я не заметил заметной разницы между тем, чтобы рисовать из памяти, и тем, чтобы каждый кадр полностью обновлять все вершины в vbo. И при этом ты можешь рисовать несколько сотен тысяч вершин из оперативы, и любая карточка моложе десяти лет это скушает в реальном времени. А передавать можно только изменённые.
Вершины это почти последнее место, которое станет узким местом производительности.
>Это все варианты решения проблемы
Можешь для каждой вершины хранить индекс соответствующего объекта, а множество матриц преобразования хранить в ssbo (или ubo, но его я никогда не использовал - точно не обещаю что он подходит).
Один дравколл, при движении объекта меняется только одна матрица. Можно хоть каждый кадр полностью перезаливать в буфер все матрицы.
Просто по количеству объектов смотри. Если меньше тысячи разных vbo, то я бы их так и оставил - почему нет? Если больше и для каждого своя матрица, и при этом каждый объект состоит из малого числа редко обновляющихся вершин (которые привлекательно посчитать один раз поменяв vbo) - то уже замерял бы производительность, так ли медленны эти несколько тысяч вызовов и нужно ли их менять на glBufferSubData.
У меня во всех случаях производительность упирается в фрагментные шейдеры, который кушают 90% времени - а во всех остальных местах можно что угодно делать любым подходом, и это почти никак не влияет на производительность.
>>738151
Отдельные vbo (один vbo со множественными дравколлам) предпочтительнее, потому что ты их просто по пирамиде видимости можешь отсекать вовсе никаких вызовов не делая для невидимых объектов. Поэтому меня и не смутила бы даже тысяча разных vbo.
Просто необходимость объекты делить на чанки (кучи объектов расположенных примерно в одном месте) уже мотивирует использование разных vbo.
Если же у тебя есть одинаковые объекты расположенные в разных частях мира (стулья какие-нибудь, ящики, кусты) - тогда тебе в любом случае нужно использовать один vbo, и для разных кустов разные матрицы использовать. И да, несколько дравколлов. Сложно представить игру, где каждый стул уникальный и повторяющейся геометрии нет. Одинаковый стул из одного буфера всё ещё возможно нарисовать в разных местах одним дравколлом с использованием некоторых костылей - но они повредят как ясности кода (и возможности его изменения), так и производительности.
Можно конечно хоть вообще все данные хранить в одном буфере обновляя разные его части - но так ли тебе этот дрочь нужен ради 2% производительности? Лучше над игрой-геймплеем поработай или что ты там делаешь. Какая-то высокоуровневая оптимизация по типу отсечения по пирамиде видимости даст тебе на порядок больше, чем выбор между одним/множественными vbo и всеми другими подходами. Неверная точка приложения сил - если ты не просто учишься и экспериментируешь.
Отдельные vbo (один vbo со множественными дравколлам) предпочтительнее, потому что ты их просто по пирамиде видимости можешь отсекать вовсе никаких вызовов не делая для невидимых объектов. Поэтому меня и не смутила бы даже тысяча разных vbo.
Просто необходимость объекты делить на чанки (кучи объектов расположенных примерно в одном месте) уже мотивирует использование разных vbo.
Если же у тебя есть одинаковые объекты расположенные в разных частях мира (стулья какие-нибудь, ящики, кусты) - тогда тебе в любом случае нужно использовать один vbo, и для разных кустов разные матрицы использовать. И да, несколько дравколлов. Сложно представить игру, где каждый стул уникальный и повторяющейся геометрии нет. Одинаковый стул из одного буфера всё ещё возможно нарисовать в разных местах одним дравколлом с использованием некоторых костылей - но они повредят как ясности кода (и возможности его изменения), так и производительности.
Можно конечно хоть вообще все данные хранить в одном буфере обновляя разные его части - но так ли тебе этот дрочь нужен ради 2% производительности? Лучше над игрой-геймплеем поработай или что ты там делаешь. Какая-то высокоуровневая оптимизация по типу отсечения по пирамиде видимости даст тебе на порядок больше, чем выбор между одним/множественными vbo и всеми другими подходами. Неверная точка приложения сил - если ты не просто учишься и экспериментируешь.
>>738155
Да я только начал учить, просто вообще непонятно что оптимально, что нет, какие бест практисес, в туториалах про время исполнения тех или иных вещей не пишут почти.
Да я только начал учить, просто вообще непонятно что оптимально, что нет, какие бест практисес, в туториалах про время исполнения тех или иных вещей не пишут почти.
>>738151
Дум3 например каждый кадр пишет все вертексы-индесы в видеопамять заново. Но это не так много, где-то пара мегабайт. Сейчас конечно модели пожирнее, но и память и шины быстрее.
Дум3 например каждый кадр пишет все вертексы-индесы в видеопамять заново. Но это не так много, где-то пара мегабайт. Сейчас конечно модели пожирнее, но и память и шины быстрее.
>>738187
Только там всего по паре буферов на вершины\индексы\юниформы. Пока один рендерится, в другой пишется.
Только там всего по паре буферов на вершины\индексы\юниформы. Пока один рендерится, в другой пишется.
>>738128
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl_VertexID.xhtml
Через юниформу передаешь какую вершину надо двигать и в шейдере сравниваешь с gl_VertexID
https://www.khronos.org/registry/OpenGL-Refpages/gl4/html/gl_VertexID.xhtml
Через юниформу передаешь какую вершину надо двигать и в шейдере сравниваешь с gl_VertexID
>>738128
Не заморачивайся сильно, от того что ты будешь буфер обновлять каждый кадр ничего ужасного не произойдет. Скорее всего будет быстрее чем всякие сложные шейдеры с бранчами.
Не заморачивайся сильно, от того что ты будешь буфер обновлять каждый кадр ничего ужасного не произойдет. Скорее всего будет быстрее чем всякие сложные шейдеры с бранчами.
Двочаны помогите, я синтаксис glsl понять не могу.
Вот у меня есть
varying vec4 v_vColour;
У v_vColour есть r g b a - это цвет и а спрайта.
Мне нужно, чтобы в той точке, где альфа единица, альфа становилось равной 0
Но если я пишу
if v_vColour.a == 1.0 v_vColour.a = 0.0;
Мне пишет синтаксическую ошибку. А в чём ошибка? Как это в glsl делается?
Вот у меня есть
varying vec4 v_vColour;
У v_vColour есть r g b a - это цвет и а спрайта.
Мне нужно, чтобы в той точке, где альфа единица, альфа становилось равной 0
Но если я пишу
if v_vColour.a == 1.0 v_vColour.a = 0.0;
Мне пишет синтаксическую ошибку. А в чём ошибка? Как это в glsl делается?
112x94Теперь я могу вырезать контур игрока на спрайте света, если источник света находится позади него.
Но теперь я хочу уменьшить этот контур на 2 пикселя, сделав тем самым освещение спрайта игрока "по краям", добавив таким образом имитацию 3д света в 2д.
Но теперь я хочу уменьшить этот контур на 2 пикселя, сделав тем самым освещение спрайта игрока "по краям", добавив таким образом имитацию 3д света в 2д.
3 Кб, 281x101>>738660
Фигурные скобки не обязательны. Обязательны круглые скобки вокруг условия, и (если что) это не только glsl, но и обычный си.
Фигурные скобки не обязательны. Обязательны круглые скобки вокруг условия, и (если что) это не только glsl, но и обычный си.
Текс, разобрался в синтаксисе и даже понял как работать с координатами текстур.
Для того, чтобы не просто вырезать спрайт игрока, мне нужно не просто уводить в 0 альфу и цвет точек, у которых альфа равна 1.
Мне нужно проверять окружающие точки, и если справа-слева сверху-снизу у точки с альфой 1 альфа не 1, то вместо увода альфы в 0 копировать на себя одну из этих точек.
Получится много if.
Насколько я понял, в шейдере нужно избегать if
Есть какие-то методы? Типа умножения вектора на булин?
Для того, чтобы не просто вырезать спрайт игрока, мне нужно не просто уводить в 0 альфу и цвет точек, у которых альфа равна 1.
Мне нужно проверять окружающие точки, и если справа-слева сверху-снизу у точки с альфой 1 альфа не 1, то вместо увода альфы в 0 копировать на себя одну из этих точек.
Получится много if.
Насколько я понял, в шейдере нужно избегать if
Есть какие-то методы? Типа умножения вектора на булин?
>>738777
Спасибо.
if (right != 1.0 || left != 1.0 || up != 1.0 || down != 1.0)
{
}
Так тоже вроде работает. Все условия скопом в скобках. По крайней мере на синтаксис не ругается.
Спасибо.
if (right != 1.0 || left != 1.0 || up != 1.0 || down != 1.0)
{
}
Так тоже вроде работает. Все условия скопом в скобках. По крайней мере на синтаксис не ругается.
11 Кб, 668x181Кстати, анончики, а есть какая-то ide для шейдеров?
Чтобы оно подсвечивало cross как встроенную функцию, а cross2sa подчёркивало красным - так как такой функции нет выше?
pycharm только типы по сути подствечивает, или простые ошибки как отсутствие скобок в if - но всё-равно можно допустить опечатку и искать её придётся вручную.
Чтобы оно подсвечивало cross как встроенную функцию, а cross2sa подчёркивало красным - так как такой функции нет выше?
pycharm только типы по сути подствечивает, или простые ошибки как отсутствие скобок в if - но всё-равно можно допустить опечатку и искать её придётся вручную.
>>738778
Считай, что у тебя во всех случаях вычисляются обе ветви if.
То есть если у тебя написан код по типу if (p<0.001) {оче медленная функция} else {быстрая функция} - то работать он будет со скоростью оче медленной функции, даже если p почти всегда больше 0.001
Я не знаю как делают нормальные люди, но я вместо очень медленной функции записывал маску пикселей, после чего запускал медленный шейдер только для нужных пикселей. Было бы интересно услышать как другие с таким справлялись.
Вот картинку погляди: >>728269
>Насколько я понял, в шейдере нужно избегать if
Считай, что у тебя во всех случаях вычисляются обе ветви if.
То есть если у тебя написан код по типу if (p<0.001) {оче медленная функция} else {быстрая функция} - то работать он будет со скоростью оче медленной функции, даже если p почти всегда больше 0.001
Я не знаю как делают нормальные люди, но я вместо очень медленной функции записывал маску пикселей, после чего запускал медленный шейдер только для нужных пикселей. Было бы интересно услышать как другие с таким справлялись.
Вот картинку погляди: >>728269
>>738786
В этом коде ты вместо того, чтобы вычислить размер текселя, испольшуешь шаг 0.0005 по иксу, что примерно соответствует размеру текселя на текстуре шириной 1920. Я уже сумел это понять
Но остальное я в твоём коде не понимаю.
Я собираюсь для каждой точки на сурфейсе, который рисуется шейдером проверять альфу.
У меня исходник пик 1. На нём свет с а<1.0 в каждой точке и силуэт игрока с a==1.0 в каждой точке.
В настоящий момент мой шейдер ifом проверяет равенство альфы единице, и если она равна, то обнуляет её, получая пик 2.
Теперь я хочу добавить спрайту игрока фейкового объёма, не делая всяких этих карт нормалей хотя может быть потом я их и сделаю, как знать, просто сделав две обводки его силуэта светом.
Здесь потребуется куча ifов
В этом коде ты вместо того, чтобы вычислить размер текселя, испольшуешь шаг 0.0005 по иксу, что примерно соответствует размеру текселя на текстуре шириной 1920. Я уже сумел это понять
Но остальное я в твоём коде не понимаю.
Я собираюсь для каждой точки на сурфейсе, который рисуется шейдером проверять альфу.
У меня исходник пик 1. На нём свет с а<1.0 в каждой точке и силуэт игрока с a==1.0 в каждой точке.
В настоящий момент мой шейдер ifом проверяет равенство альфы единице, и если она равна, то обнуляет её, получая пик 2.
Теперь я хочу добавить спрайту игрока фейкового объёма, не делая всяких этих карт нормалей хотя может быть потом я их и сделаю, как знать, просто сделав две обводки его силуэта светом.
Здесь потребуется куча ifов
101 Кб, 826x847Ну вот оно даже получилось с 5ю ifами.
На 4 пикселя в глубину спрайт игрока подсвечивается окружающим светом.
Выглядит классно, если спрайт игрока просто чёрный на самом деле зелёный контур.
Но когда я вставляю настоящий спрайт, получается коряво.
Потому что вот эту подсветку на глубину в 4 пикселя надо "размазать". Во-первых усреднить по ближайшим 4ём пикселям по цвету и альфе, а во вторых поступательно уменьшать по a по мере удаления от края спрайта.
А это ещё куча ifов.
На 4 пикселя в глубину спрайт игрока подсвечивается окружающим светом.
Выглядит классно, если спрайт игрока просто чёрный на самом деле зелёный контур.
Но когда я вставляю настоящий спрайт, получается коряво.
Потому что вот эту подсветку на глубину в 4 пикселя надо "размазать". Во-первых усреднить по ближайшим 4ём пикселям по цвету и альфе, а во вторых поступательно уменьшать по a по мере удаления от края спрайта.
А это ещё куча ifов.
>>738789
Нет, это был просто фиктивный цикл, чтобы фпс упал до низких значений.
Я не очень понял что ты делаешь, но если у тебя 2д и разумное количество спрайтов, я бы без шейдера на процессоре один раз посчитал и загрузил.
Нет бы код скинуть на пастебин какой-нибудь.
У тебя a принимает только два значения 0/1? Если да, то замени четыре нижних условия на:
texColor=texute2D(gm_BaseTexture,v_vTexcoord+4.0∙offsetx∙(-scan_rignt+scan_left)+4.0∙offsety∙(-scan_down+scan_up)) или что-то похожее.
Если нет, то всё-равно считай в четырёх условиях лишь текстурные координаты (которые v_vTexcoord+..), а потом один раз внизу вызывай texute2D с полученными координатами.
Условие на строке 20 можно переписать как texColor.a==1.0, ты же на 18 строке только что вызвал texute2D с теми же аргументами. Это настолько очевидно, что даже компилятор glsl сам может догадаться это оптимизировать.
>Я уже сумел это понять
Нет, это был просто фиктивный цикл, чтобы фпс упал до низких значений.
Я не очень понял что ты делаешь, но если у тебя 2д и разумное количество спрайтов, я бы без шейдера на процессоре один раз посчитал и загрузил.
>Ну вот оно даже получилось с 5ю ifами.
Нет бы код скинуть на пастебин какой-нибудь.
У тебя a принимает только два значения 0/1? Если да, то замени четыре нижних условия на:
texColor=texute2D(gm_BaseTexture,v_vTexcoord+4.0∙offsetx∙(-scan_rignt+scan_left)+4.0∙offsety∙(-scan_down+scan_up)) или что-то похожее.
Если нет, то всё-равно считай в четырёх условиях лишь текстурные координаты (которые v_vTexcoord+..), а потом один раз внизу вызывай texute2D с полученными координатами.
Условие на строке 20 можно переписать как texColor.a==1.0, ты же на 18 строке только что вызвал texute2D с теми же аргументами. Это настолько очевидно, что даже компилятор glsl сам может догадаться это оптимизировать.
>Я не очень понял что ты делаешь,
webm рилейтед
>Нет бы код скинуть на пастебин какой-нибудь.
Ну тут хоть какая-то разметочка есть
>texColor=texute2D(gm_BaseTexture,v_vTexcoord+4.0∙offsetx∙(-scan_rignt+scan_left)+4.0∙offsety∙(-scan_down+scan_up)) или что-то похожее.
Сейчас подумаю, как можно ifы сократить.
Пока додумался до пикрил. В шейдерах я полный нуб.
>Условие на строке 20 можно переписать как texColor.a==1.0, ты же на 18 строке только что вызвал texute2D с теми же аргументами. Это настолько очевидно, что даже компилятор glsl сам может догадаться это оптимизировать.
Да это я пока проверяю, как работать будет. Потом всё почищу-причешу. как сумею
В итоге я беру значение альфы света на расстоянии alpha_depth пикселей от пикселя с альфой 1.0 и если там прозрачно, то я этому пикселю выставляю альфу в зависимости от того, сколько прозрачных пикселей рядом с ним.
Если рядом с непрозрачным пикселем на расстоянии alpha_depth нет прозрачных пикселецй, значит пиксель не освещён и альфу ему ставлю 0.
На вебмках на тестовом спрайте глубина 4, на спрайте игрока глубина 8. Т.к. с глубиной 4 света на игроке почти не видно.
Не откажусь от советов мудрых, как сделать лучше.
>>738811
Сокращай не if, а сложность операций под if.
Вариант 1:
if (a==1.0)
color=texture2d(xy+16.0)
if (b!=1.0)
color=texture2d(xy-21.0)
--
Плохой вариант, два texture2d, две операции с xy
Вариант 2:
vec2 st;
if (a==1.0)
st=xy+16.0
if (b!=1.0)
st=xy-21.0
color=texture2d(st)
--
Лучше - две операции с xy, один texture2d
И на этом стоит остановиться.
Если у тебя а принимает только значения 1.0 и 0.0, то можно свернуть в одну строчку без условий (с использованием условного step, если у тебя float) - но это того не стоит, мне кажется. В финальной версии когда уже всё сделаешь, можешь напильником это обработать, чтобы 1% производительности получить (если он тут вообще будет) - но скорее всего будет несколько десятков более целесообразных задач в плане повышение производительности и общего качества программы.
Я бы ещё else расставил во всех местах, конечно. Ну так, на всякий случай - у тебя же значение texColor перезаписывается.
Меня люто триггерит твой код, где в случае если у тебя одновременно срабатывают alpha_up и alpha_left, результат будет такой же как просто с alpha_up, просто потому что он в коде расположен за alpha_left - при том что никаких выделенных направлений не должно быть.
Сокращай не if, а сложность операций под if.
Вариант 1:
if (a==1.0)
color=texture2d(xy+16.0)
if (b!=1.0)
color=texture2d(xy-21.0)
--
Плохой вариант, два texture2d, две операции с xy
Вариант 2:
vec2 st;
if (a==1.0)
st=xy+16.0
if (b!=1.0)
st=xy-21.0
color=texture2d(st)
--
Лучше - две операции с xy, один texture2d
И на этом стоит остановиться.
Если у тебя а принимает только значения 1.0 и 0.0, то можно свернуть в одну строчку без условий (с использованием условного step, если у тебя float) - но это того не стоит, мне кажется. В финальной версии когда уже всё сделаешь, можешь напильником это обработать, чтобы 1% производительности получить (если он тут вообще будет) - но скорее всего будет несколько десятков более целесообразных задач в плане повышение производительности и общего качества программы.
Я бы ещё else расставил во всех местах, конечно. Ну так, на всякий случай - у тебя же значение texColor перезаписывается.
Меня люто триггерит твой код, где в случае если у тебя одновременно срабатывают alpha_up и alpha_left, результат будет такой же как просто с alpha_up, просто потому что он в коде расположен за alpha_left - при том что никаких выделенных направлений не должно быть.
>>738817
Да-да, я в курсе. Прямо сейчас работаю над этим.
По идее надо суммировать свет на пикселе со всех направлений и как-то нормализовать.
И вообще брать за основу света не значение альфы в N пикселей от освещаемой точки, а усреднённую альфу в регионе рядом с ней. Иначе структура света заползает на игрока. Свет-то от фанариков вручную рисуется. Там "нормали", все дела. Когда таким светом на игрока светишь, кажется что на него попадает изображение с проектора.
>где в случае если у тебя одновременно срабатывают alpha_up и alpha_left, результат будет такой же как просто с alpha_up, просто потому что он в коде расположен за alpha_left
Да-да, я в курсе. Прямо сейчас работаю над этим.
По идее надо суммировать свет на пикселе со всех направлений и как-то нормализовать.
И вообще брать за основу света не значение альфы в N пикселей от освещаемой точки, а усреднённую альфу в регионе рядом с ней. Иначе структура света заползает на игрока. Свет-то от фанариков вручную рисуется. Там "нормали", все дела. Когда таким светом на игрока светишь, кажется что на него попадает изображение с проектора.
>>738827
Напиши конечно.
Кстати, какой цвет и a будут у пикселя, взятого по координатам за пределами текстуры? Всё по нулям? Или нужно ставить условие в цикл, чтобы за пределы текстуры не влезал?
Сейчас у меня такого условия не стоит и вроде всё работает без проблем.
Напиши конечно.
Кстати, какой цвет и a будут у пикселя, взятого по координатам за пределами текстуры? Всё по нулям? Или нужно ставить условие в цикл, чтобы за пределы текстуры не влезал?
Сейчас у меня такого условия не стоит и вроде всё работает без проблем.
>>738829
Зависит от параметров сэмплирования, никаких условий не надо ставить, кури glTexParameteri, GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T.
> какой цвет и a будут у пикселя, взятого по координатам за пределами текстуры?
Зависит от параметров сэмплирования, никаких условий не надо ставить, кури glTexParameteri, GL_TEXTURE_WRAP_S, GL_TEXTURE_WRAP_T.
>>738786
Текс, до меня только сейчас дошло, что если я буду запускать циклы внутри if, то исполняться они будут для каждого пикселя, а не только для неосвещённого.
Впрочем характерные размеры спрайта света у меня где-то 8080, с редкими исключениями до 200200.
>То есть если у тебя написан код по типу if (p<0.001) {оче медленная функция} else {быстрая функция} - то работать он будет со скоростью оче медленной функции, даже если p почти всегда больше 0.001
Текс, до меня только сейчас дошло, что если я буду запускать циклы внутри if, то исполняться они будут для каждого пикселя, а не только для неосвещённого.
Впрочем характерные размеры спрайта света у меня где-то 8080, с редкими исключениями до 200200.
>>738829
Лады, попозже вечером скину.
Тебя версия 4.5 и легаси устроит, чтобы тысячи строк не писать для того чтобы квадрат из четырёх вершин вывести и сдвинуть?
Лады, попозже вечером скину.
Тебя версия 4.5 и легаси устроит, чтобы тысячи строк не писать для того чтобы квадрат из четырёх вершин вывести и сдвинуть?
>>738841
Это что вообще? Это не под мобилки разве?
Я тогда не буду доводить до ума, потому что я кода из своих демок намешал, и у меня легаси пополам с dsa, и по идее ни то, ни другое в es не поддерживается.
Шейдер ниже. in/out - это varying, binding просто подписывает на каком текстурном юните какая текстура.
К тому же ниже скинули то же самое что пишу я - только качественнее.
Там вся сложность в том, как выбрать нормали. Если как на первой картинке - то объём не тот который хочется. А на второй слишком бублики вместо объёма - это не для всех изображений подойдёт. Я вот выбрал так, что вблизи объект освещается равномерно - а издалека только сбоку. Можно считать что источник света за объектами, и тогда нормали на границе нужно считать иначе, чтобы они освещались когда свет за объектом.
Но в любом случае стоит заранее один раз посчитать нормали, а в шейдере две текстуры юзать - шейдер очень лёгкий получается, без условий и множественных выборок из текстуры.
>GLSL ES v2
Это что вообще? Это не под мобилки разве?
Я тогда не буду доводить до ума, потому что я кода из своих демок намешал, и у меня легаси пополам с dsa, и по идее ни то, ни другое в es не поддерживается.
Шейдер ниже. in/out - это varying, binding просто подписывает на каком текстурном юните какая текстура.
К тому же ниже скинули то же самое что пишу я - только качественнее.
Там вся сложность в том, как выбрать нормали. Если как на первой картинке - то объём не тот который хочется. А на второй слишком бублики вместо объёма - это не для всех изображений подойдёт. Я вот выбрал так, что вблизи объект освещается равномерно - а издалека только сбоку. Можно считать что источник света за объектами, и тогда нормали на границе нужно считать иначе, чтобы они освещались когда свет за объектом.
Но в любом случае стоит заранее один раз посчитать нормали, а в шейдере две текстуры юзать - шейдер очень лёгкий получается, без условий и множественных выборок из текстуры.
>>739117
Так прикол в том, что у меня нет нормалей. Я как представлю, что нужно будет нарисовать нормали к полутора тысячам спрайтов, так дурно становится.
Так что я сделал просто "дешёвое" освещение которое будет применяться к редким объектам, типа игрока или NPC, подсвечивая их с краёв, как будто в игре ААА 3д свет с нормалями.
Так прикол в том, что у меня нет нормалей. Я как представлю, что нужно будет нарисовать нормали к полутора тысячам спрайтов, так дурно становится.
Так что я сделал просто "дешёвое" освещение которое будет применяться к редким объектам, типа игрока или NPC, подсвечивая их с краёв, как будто в игре ААА 3д свет с нормалями.
>>739007
Да-да-да. Я даже себе spritelamp купил. Но это дохера работы, а у нас ещё демка даже не сделана.
Да-да-да. Я даже себе spritelamp купил. Но это дохера работы, а у нас ещё демка даже не сделана.
>>739139
Так программно сгенерируй их. Это будет лучше, чем костыль в шейдере. И производительнее.
Да, не так красиво как вручную, но всё ещё ничего может быть.
Так программно сгенерируй их. Это будет лучше, чем костыль в шейдере. И производительнее.
Да, не так красиво как вручную, но всё ещё ничего может быть.
>>739157
Ну кстати да. Просто программно сделать из спрайтов "тело вращения" и нафигачить нормали на такое тело.
Может быть я так и сделаю когда-нибудь.
Ну кстати да. Просто программно сделать из спрайтов "тело вращения" и нафигачить нормали на такое тело.
Может быть я так и сделаю когда-нибудь.
Поясните за Array Texture. Это настоящий двумерный массив с текстурами, где каждый слой - текстура? Или эмуляция таким образом одной большой текстуры разбитой на тайлы?
>>739249
Это обычная трёхмерная текстура - но такая где слои по глубине не блендятся из-за фильтрации, и при создании мипмапов размерность по глубине не уменьшается.
Это обычная трёхмерная текстура - но такая где слои по глубине не блендятся из-за фильтрации, и при создании мипмапов размерность по глубине не уменьшается.
>>739250
Окей, тогда еще нубский вопрос. Есть ли возможность закинуть в шейдер штук 200-300 текстур, что бы можно было передавать через инстансированные массивы id этой текстуры и рендерить за один проход тысячи однотипных объектов с разными текстурами?
Окей, тогда еще нубский вопрос. Есть ли возможность закинуть в шейдер штук 200-300 текстур, что бы можно было передавать через инстансированные массивы id этой текстуры и рендерить за один проход тысячи однотипных объектов с разными текстурами?
>>739252
Закидываешь в UBO или SSBO список номеров слоев в текстуре-массиве и в фрагментном шейдере юзаешь. Как обратиться по номеру инстанса - встроенная переменная gl_InstanceID.
Закидываешь в UBO или SSBO список номеров слоев в текстуре-массиве и в фрагментном шейдере юзаешь. Как обратиться по номеру инстанса - встроенная переменная gl_InstanceID.
>>739252
Если они одинакового размера.
Если разного - то посмотри что такое текстурный атлас (тоже можно, сколько хочешь текстур и какого хочешь разрешения), но немного сложнее в виде кода.
Если они одинакового размера.
Если разного - то посмотри что такое текстурный атлас (тоже можно, сколько хочешь текстур и какого хочешь разрешения), но немного сложнее в виде кода.
Назрел вопрос по геометрическому шейдеру. Можно как-то в нем прочитать данные из инстансированного массива? В вертексном шейдере можно читать из него провернув финт аля layout (location = 2) in mat4 запихнув в вершинные атрибуты, что помогает избежать ограничения размера юниформ массива, но как быть с геометрическим? Неужели только через юниформ-массив?
>>739932
Передавай из вершинного в геометрический твои данные, так же как обычно передаёшь из вершинного во фрагментный цвета и текстурные координаты, когда нет геометрического?
Да чем же тебе ssbo не нравится. Можешь хоть из текстуры читать твои матрицы - там же даже есть функции распаковки пикселей во float-ы, которые прям в самых первых версиях opengl добавили как раз для таких нужд.
Передавай из вершинного в геометрический твои данные, так же как обычно передаёшь из вершинного во фрагментный цвета и текстурные координаты, когда нет геометрического?
>ограничения размера юниформ массива
Да чем же тебе ssbo не нравится. Можешь хоть из текстуры читать твои матрицы - там же даже есть функции распаковки пикселей во float-ы, которые прям в самых первых версиях opengl добавили как раз для таких нужд.
1
>>739956
SSBO может не нравиться если есть ограничения на версию API, и ограничения эти либо в голове (возможно преодолеть), либо в железе (тогда жопа).
SSBO может не нравиться если есть ограничения на версию API, и ограничения эти либо в голове (возможно преодолеть), либо в железе (тогда жопа).
>>740029
А текстура чем плоха? Можно текстуру из флоатов сделать, такое ещё во времена фреймбуферов и opengl 2.1 появилось везде, а в 3.0 вошло в стандарт - 13 лет назад.
Если доступ к текстуре нормально работает во фрагментном шейдере, то на каждую вершину по четыре вызова texelFetch (для матрицы) можно себе позволить - если по какой-то причине что-то современнее не работает.
Может быть я чего-то не понимаю...
>тогда жопа
А текстура чем плоха? Можно текстуру из флоатов сделать, такое ещё во времена фреймбуферов и opengl 2.1 появилось везде, а в 3.0 вошло в стандарт - 13 лет назад.
Если доступ к текстуре нормально работает во фрагментном шейдере, то на каждую вершину по четыре вызова texelFetch (для матрицы) можно себе позволить - если по какой-то причине что-то современнее не работает.
Может быть я чего-то не понимаю...
>>740087
По-моему "прямое" чтение из памяти должно работать быстрее чем через текстурный юнит, но это надо проверять.
По-моему "прямое" чтение из памяти должно работать быстрее чем через текстурный юнит, но это надо проверять.
Посоны, у меня есть точки на экране. Пользователь может выделить мышкой область и нужно найти все точки, которые попали в эту область. Как такое делать?
Это платина, да?
Это платина, да?
>>741186
Делаешь двухмерный массив размером с экран, куда на экране пользователь кликнул - идешь по тем координатам в массив и смотришь что там лежит. А точки, ну если их не много можно и старым опенгл ввести. Или сделать текстуру на основе массива и уже ее вывести.
Делаешь двухмерный массив размером с экран, куда на экране пользователь кликнул - идешь по тем координатам в массив и смотришь что там лежит. А точки, ну если их не много можно и старым опенгл ввести. Или сделать текстуру на основе массива и уже ее вывести.
>>741194
Сотни тысяч. Каждая точка - это наблюдение. В минуту делают 5 наблюдений, а всего наблюдения ведутся 12 лет.
Мне кажется, ты описываешь двумерный случай. А у меня трехмерный. В таком случае придется не просто брать координаты выделенной области, а куб [x0, x1]x[y0,y1]x[-1,1], после чего куб умножать на обратные матрицы (смещения, поворота итд) и получать область в пространстве точек. И потом искать, какие точки принадлежат этой области. А это дико долгая процедура, потому я надеялся, есть какие-то более умные подходы.
> если их не много
Сотни тысяч. Каждая точка - это наблюдение. В минуту делают 5 наблюдений, а всего наблюдения ведутся 12 лет.
Мне кажется, ты описываешь двумерный случай. А у меня трехмерный. В таком случае придется не просто брать координаты выделенной области, а куб [x0, x1]x[y0,y1]x[-1,1], после чего куб умножать на обратные матрицы (смещения, поворота итд) и получать область в пространстве точек. И потом искать, какие точки принадлежат этой области. А это дико долгая процедура, потому я надеялся, есть какие-то более умные подходы.
>>741197
Инстансные массивы. А выделение мышки проверяй обходом всех элементов, те что попали в выделенную область по координатам - те наши.
Инстансные массивы. А выделение мышки проверяй обходом всех элементов, те что попали в выделенную область по координатам - те наши.
>>741197
Квадратом, или произвольной линией?
Пересчитываешь все точки в 2d-координаты, и делаешь проверки x1<x<x2 для квадрата, или более сложные по линии. Если у тебя точки за спиной, учти что ещё нужно будет проверить, что глубина положительна и точка перед камерой. Обратные матрицы не нужны.
К opengl твоя задача никакого отношения не имеет.
Можно построить пирамиду видимости и смотреть пересечения с границами в трёхмерном случае (разбирается в https://pmg.org.ru/nehe/nehex2.htm) - но для точек это смысла не имеет и намного производительнее будет просто точки пересчитать, мне кажется.
Если по какой-то причине тебе нужно лютая производительность, а форма выделения произвольная - то разделяй точки на чанки по сетке (или по дереву - но это очень сложная форма выделения должна быть из тысяч сегментов, что проверка каждой точки отдельно будет тяжелее, чем построение дерева) и проверяй сначала грубо попадает ли чанк в область, а потом просчитывай отдельно точки, которые находится в чанках, которые пересекаются границей выделения.
>выделить мышкой область
Квадратом, или произвольной линией?
>А у меня трехмерный
Пересчитываешь все точки в 2d-координаты, и делаешь проверки x1<x<x2 для квадрата, или более сложные по линии. Если у тебя точки за спиной, учти что ещё нужно будет проверить, что глубина положительна и точка перед камерой. Обратные матрицы не нужны.
К opengl твоя задача никакого отношения не имеет.
Можно построить пирамиду видимости и смотреть пересечения с границами в трёхмерном случае (разбирается в https://pmg.org.ru/nehe/nehex2.htm) - но для точек это смысла не имеет и намного производительнее будет просто точки пересчитать, мне кажется.
Если по какой-то причине тебе нужно лютая производительность, а форма выделения произвольная - то разделяй точки на чанки по сетке (или по дереву - но это очень сложная форма выделения должна быть из тысяч сегментов, что проверка каждой точки отдельно будет тяжелее, чем построение дерева) и проверяй сначала грубо попадает ли чанк в область, а потом просчитывай отдельно точки, которые находится в чанках, которые пересекаются границей выделения.
>>741207
Так и не потриксили скобочки в конце ссылки.
https://pmg.org.ru/nehe/nehex2.htm
https://pmg.org.ru/nehe/nehex2.htm)
https://pmg.org.ru/nehe/nehex2.htm)
Так и не потриксили скобочки в конце ссылки.
https://pmg.org.ru/nehe/nehex2.htm
https://pmg.org.ru/nehe/nehex2.htm)
https://pmg.org.ru/nehe/nehex2.htm)
>>741207
Но ведь 2д-координаты будут зависеть от матриц (картинка не статична, ее можно вертеть и приближать-удалять).
Пока сделаю так. Всю математику из вершинного шейдера перепишу на куду, чтобы можно было получать обратно 2д-координаты точек. И для выделенной области буду проверять эти 2д-координаты.
Спасибо.
Решил научиться в визуализацию, чувствую себя героем вебмки "Не лезь, она тебя сожрет"
>Пересчитываешь все точки в 2d-координаты
Но ведь 2д-координаты будут зависеть от матриц (картинка не статична, ее можно вертеть и приближать-удалять).
Пока сделаю так. Всю математику из вершинного шейдера перепишу на куду, чтобы можно было получать обратно 2д-координаты точек. И для выделенной области буду проверять эти 2д-координаты.
Спасибо.
Решил научиться в визуализацию, чувствую себя героем вебмки "Не лезь, она тебя сожрет"
>>741207
Квадратом.
Квадратом.
>>741216
Ии? Ты выделяешь точки в один определённый кадр, в момент выделения сохраняешь список выделенных точек. Или ты одновременно двигаешь камеру и изменяешь квадрат выделения? Энивей что бы ты не имел виду обратное преобразование тоже не статично, и пирамиду придётся перестраивать.
Если квадратом - то без разницы, при пересчёте ты выполняешь 4 скалярных произведения (умножение матрицы на вектор), при отсечении по пирамиде четырьмя плоскостями тоже 4 скалярных произведения (по одному на плоскость).
Это при выделении сложной фигурой на 2d экране, многоугольником или кругом нужно пересчитывать.
Зачем? Есть вычислительный шейдер, который куда меньшими усилиями соединяется с программой на opengl, чем куда. Есть transform feedback, лол.
Ты уверен, что гонять 100к вершин каждый кадр будет быстрее, чем умножить их на процессоре (если не использовать transform feedback и считать их ещё раз)? Я не уверен. Скалярное произведение состоит только из сложений и умножений - это очень лёгкие операции на один такт.
Если ты поехавший, для тебя есть https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX2,FMA&text=mad&expand=2541,2553 - с помощью чего ты можешь ускорить вычисления в 4/8 раз, а на деле ещё сильнее за счёт совмещения умножения и сложения. А потом ещё распараллелить. Я не поверю что доступ к памяти видеокарты будет быстрее, чем самая быстрая процессорная операция.
Кстати, привет, мы знакомы с очень большой вероятностью по всем признакам.
>Но ведь 2д-координаты будут зависеть от матриц (картинка не статична, ее можно вертеть и приближать-удалять)
Ии? Ты выделяешь точки в один определённый кадр, в момент выделения сохраняешь список выделенных точек. Или ты одновременно двигаешь камеру и изменяешь квадрат выделения? Энивей что бы ты не имел виду обратное преобразование тоже не статично, и пирамиду придётся перестраивать.
Если квадратом - то без разницы, при пересчёте ты выполняешь 4 скалярных произведения (умножение матрицы на вектор), при отсечении по пирамиде четырьмя плоскостями тоже 4 скалярных произведения (по одному на плоскость).
Это при выделении сложной фигурой на 2d экране, многоугольником или кругом нужно пересчитывать.
>Всю математику из вершинного шейдера перепишу на куду
Зачем? Есть вычислительный шейдер, который куда меньшими усилиями соединяется с программой на opengl, чем куда. Есть transform feedback, лол.
Ты уверен, что гонять 100к вершин каждый кадр будет быстрее, чем умножить их на процессоре (если не использовать transform feedback и считать их ещё раз)? Я не уверен. Скалярное произведение состоит только из сложений и умножений - это очень лёгкие операции на один такт.
Если ты поехавший, для тебя есть https://software.intel.com/sites/landingpage/IntrinsicsGuide/#techs=AVX2,FMA&text=mad&expand=2541,2553 - с помощью чего ты можешь ускорить вычисления в 4/8 раз, а на деле ещё сильнее за счёт совмещения умножения и сложения. А потом ещё распараллелить. Я не поверю что доступ к памяти видеокарты будет быстрее, чем самая быстрая процессорная операция.
Кстати, привет, мы знакомы с очень большой вероятностью по всем признакам.
>>742576
потмоу, что "кубик" не отрисовывается до конца?
потмоу, что "кубик" не отрисовывается до конца?
5 Кб, 368x3519, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
0, -666.66602, -2800.00, 96.02305, 0.03937, -0.07087, 0.99213,
17, -670.8327, -2800.00, 96.21115, 0.01575, -0.04724, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
1, -666.66602, -2804.16675, 95.60873, 0.05512, -0.09449, 0.99213,
0, -666.66602, -2800.00, 96.02305, 0.03937, -0.07087, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
18, -670.8327, -2804.16675, 95.92864, 0.03937, -0.07874, 0.99213,
1, -666.66602, -2804.16675, 95.60873, 0.05512, -0.09449, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
17, -670.8327, -2800.00, 96.21115, 0.01575, -0.04724, 0.99213,
18, -670.8327, -2804.16675, 95.92864, 0.03937, -0.07874, 0.99213,
Как посчитать эти ебучии нормали? Чтобы результат был как в последней колонке.
0, -666.66602, -2800.00, 96.02305, 0.03937, -0.07087, 0.99213,
17, -670.8327, -2800.00, 96.21115, 0.01575, -0.04724, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
1, -666.66602, -2804.16675, 95.60873, 0.05512, -0.09449, 0.99213,
0, -666.66602, -2800.00, 96.02305, 0.03937, -0.07087, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
18, -670.8327, -2804.16675, 95.92864, 0.03937, -0.07874, 0.99213,
1, -666.66602, -2804.16675, 95.60873, 0.05512, -0.09449, 0.99213,
9, -668.74933, -2802.08325, 95.99379, 0.05512, -0.07874, 0.99213,
17, -670.8327, -2800.00, 96.21115, 0.01575, -0.04724, 0.99213,
18, -670.8327, -2804.16675, 95.92864, 0.03937, -0.07874, 0.99213,
Как посчитать эти ебучии нормали? Чтобы результат был как в последней колонке.
>>743256
Понятнее спрашивай, где у тебя координаты, где нормали и что это вообще (откуда ты это взял).
У треугольника одна нормаль, а не три разных в каждой вершине. Если у тебя в разных углах треугольника разные нормали - то это не нормали, а какие-то абстрактные числа одну тебе известным способом полученные.
Если считать нормаль в вершине как среднюю нормаль полигонов, в которые входит вершина, то на 9 точке получается 0.06058027 -0.0831159 0.99469683, а не то что у тебя - то есть там более сложный алгоритм сглаживания нормалей (например они зависят от других полигонов).
Понятнее спрашивай, где у тебя координаты, где нормали и что это вообще (откуда ты это взял).
У треугольника одна нормаль, а не три разных в каждой вершине. Если у тебя в разных углах треугольника разные нормали - то это не нормали, а какие-то абстрактные числа одну тебе известным способом полученные.
Если считать нормаль в вершине как среднюю нормаль полигонов, в которые входит вершина, то на 9 точке получается 0.06058027 -0.0831159 0.99469683, а не то что у тебя - то есть там более сложный алгоритм сглаживания нормалей (например они зависят от других полигонов).
>>743311
Ты ёбнутый? Ты не знаешь что нормали обычно нормализованы?
> Понятнее спрашивай, где у тебя координаты, где нормали
Ты ёбнутый? Ты не знаешь что нормали обычно нормализованы?
>>747145
Например два треугольника с полупрозрачной текстурой как часть модели юнита.
Например два треугольника с полупрозрачной текстурой как часть модели юнита.
Вопрос не по опенжл, а вообщем.
Как организовать рендеринг текста, особенно много текста, особенно динамически изменяющегося.
Какую геометрию выбрать, квады, или что то сложнее? какой формат вертекса наиболее подходящий: (позиция, uv, color)?
Чем рисовать: инстансингом мешей?
Немного хаотично, но думаю вы поняли. А то в интернетах чет нихуя не нашел бест практисес для отрисовки текста.
Как организовать рендеринг текста, особенно много текста, особенно динамически изменяющегося.
Какую геометрию выбрать, квады, или что то сложнее? какой формат вертекса наиболее подходящий: (позиция, uv, color)?
Чем рисовать: инстансингом мешей?
Немного хаотично, но думаю вы поняли. А то в интернетах чет нихуя не нашел бест практисес для отрисовки текста.
>>747386
В качестве экскремента делал рендеринг sdf single distance field шрифтов. Прикольно, конечно, можно за один вызов рисования тени нарисовать, но надо текстуру готовить, атлас. Если хочешь иметь разный размер шрифта, то возможно понадобится несколько текстур.
Посмотри freetype, правда не пробовал эту либу и подобные.
Если надо просто какой-то текст для дебага, то достаточно сделать атлас со шрифтом и всё.
Рисуй прямо так: glDrawElements( GL_TRIANGLE, 6 умножить на кол-во символов, GL_UNSIGNED_SHORT, nullptr, 0 )
Где символ состоит из 2ух треугольников { 0, 1, 2, 0, 2, 3 }
Вертекст у меня был такой vec4 (2 позиция, 2 текстурные координаты), vec4 цвет
В качестве экскремента делал рендеринг sdf single distance field шрифтов. Прикольно, конечно, можно за один вызов рисования тени нарисовать, но надо текстуру готовить, атлас. Если хочешь иметь разный размер шрифта, то возможно понадобится несколько текстур.
Посмотри freetype, правда не пробовал эту либу и подобные.
Если надо просто какой-то текст для дебага, то достаточно сделать атлас со шрифтом и всё.
Рисуй прямо так: glDrawElements( GL_TRIANGLE, 6 умножить на кол-во символов, GL_UNSIGNED_SHORT, nullptr, 0 )
Где символ состоит из 2ух треугольников { 0, 1, 2, 0, 2, 3 }
Вертекст у меня был такой vec4 (2 позиция, 2 текстурные координаты), vec4 цвет
>>747386
>>747397
Подкину еще свою ссылочку https://wdobbie.com/post/gpu-text-rendering-with-vector-textures/
>>747397
Подкину еще свою ссылочку https://wdobbie.com/post/gpu-text-rendering-with-vector-textures/
Ну что же вы, полигональные, расскажите чо хоть интересного сделали в последнее время?
Я вот - ничерта, тк всё время сжирает основная работа, вращать кубы некогда, читать Real-time Rendering 4th ed тоже. Тоска.
Я вот - ничерта, тк всё время сжирает основная работа, вращать кубы некогда, читать Real-time Rendering 4th ed тоже. Тоска.
Как можно описать портрет типичного опенгл-щика? Как вы начали заниматься кодированием графики? Что побуждает вас продолжать этим заниматься? Насколько вы задротны по технологиям и математике? Насколько вы дисциплинированы, чтобы курить кучу инфы, или вами движет естественная мотивация?
Давно хочется изучить программирование графона, начинал даже опенглтуториал, дошел до рисования нескольких разноцветных треугольников. Один раз даже было дело кодил рейтрейсер и оптимизировал его бинарным деревом (хотя там совсем не реалтайм был, и выводилось все в бмп файл).
Математику в общем-то знаю, геометрию люблю, кодить могу, в архитектуре цпу/гпу немного кумекаю. Только вот собраться и укуриться опенглом, шейдерами и прочим никак не получается.
Наверное потому что у меня нет какой-то конкретной цели, нет хотения писать свой 3д движок с невъебенными эффектами и быстродействием, и все в таком духе.
Скорее всего я чем-то не тем занимаюсь, и опенгл мне никакой не нужен, это просто красивая идея, что круто было бы разбираться в такой технологии...
Давно хочется изучить программирование графона, начинал даже опенглтуториал, дошел до рисования нескольких разноцветных треугольников. Один раз даже было дело кодил рейтрейсер и оптимизировал его бинарным деревом (хотя там совсем не реалтайм был, и выводилось все в бмп файл).
Математику в общем-то знаю, геометрию люблю, кодить могу, в архитектуре цпу/гпу немного кумекаю. Только вот собраться и укуриться опенглом, шейдерами и прочим никак не получается.
Наверное потому что у меня нет какой-то конкретной цели, нет хотения писать свой 3д движок с невъебенными эффектами и быстродействием, и все в таком духе.
Скорее всего я чем-то не тем занимаюсь, и опенгл мне никакой не нужен, это просто красивая идея, что круто было бы разбираться в такой технологии...
>>749760
Прост интересы.
Вот тут вон чуваки вообще свой собственный OpenGL изобретают
https://github.com/C-Chads/tinygl
и ничего. Вроде бы оно и бесполезно, не имеет никакого смысла. А вроде бы оно и интересно
Прост интересы.
Вот тут вон чуваки вообще свой собственный OpenGL изобретают
https://github.com/C-Chads/tinygl
и ничего. Вроде бы оно и бесполезно, не имеет никакого смысла. А вроде бы оно и интересно
>>749763
Типа того, личный бзик. Кодить само по себе - не великое удовольствие, поэтому без доп стимулов бывает тяжело. А если понимаешь, что ты вот нормалечку тут распаковываешь или френельчика приблизительно рассчитываешь, то как-то сразу и на душе теплее и проебы при кодировании пережить легче.
Но вот этот >>749760 анон в чём-то прав, вполне допускаю, что это заниматься этим мне не сильно и нужно - иначе уже давно бы как-то перекатился бы в сферу. Но нет, я просто страдаю, что времени не хватает, а когда оно появляется - ничерта толкового всё равно родить не могу. Уже сколько месяцев планирую переделать рендеринг от накопленного прямого вызова а-ля onRender к формированию очередей. Такое себе.
С другой стороны унылее телекома только финансы и ебля с базами.
Типа того, личный бзик. Кодить само по себе - не великое удовольствие, поэтому без доп стимулов бывает тяжело. А если понимаешь, что ты вот нормалечку тут распаковываешь или френельчика приблизительно рассчитываешь, то как-то сразу и на душе теплее и проебы при кодировании пережить легче.
Но вот этот >>749760 анон в чём-то прав, вполне допускаю, что это заниматься этим мне не сильно и нужно - иначе уже давно бы как-то перекатился бы в сферу. Но нет, я просто страдаю, что времени не хватает, а когда оно появляется - ничерта толкового всё равно родить не могу. Уже сколько месяцев планирую переделать рендеринг от накопленного прямого вызова а-ля onRender к формированию очередей. Такое себе.
С другой стороны унылее телекома только финансы и ебля с базами.
>>749847
Почему тогда не выбрал что-то более высокоуровневое для так называемого криэйтив кодинга, типа процессинга, токсиклибс, опенфреймворкс?
Почему тогда не выбрал что-то более высокоуровневое для так называемого криэйтив кодинга, типа процессинга, токсиклибс, опенфреймворкс?
265 Кб, 1920x1080>>749913
Скажем так, личная история. Это второе моё место работы после госорга, где я кис почти 10 лет. Выкатился через чудом подвернувшуюся работу на околодвижковую тему - мечта прям, но не вытянул, всё же болотные корни сказались. Понятно, что после такого не до выбора было особо. Хотелось, чтобы платили и не говно контора была. В принципе, так и оказалось - грех жаловаться на условия. По деньгам уже в 2,5 раза вырос, коллеги норм, менеджеры не достают, плюсы 17ые вот местами подвезли даже. Но чёртовы кубы сидят в подкорке и шепчут.
Скажем так, личная история. Это второе моё место работы после госорга, где я кис почти 10 лет. Выкатился через чудом подвернувшуюся работу на околодвижковую тему - мечта прям, но не вытянул, всё же болотные корни сказались. Понятно, что после такого не до выбора было особо. Хотелось, чтобы платили и не говно контора была. В принципе, так и оказалось - грех жаловаться на условия. По деньгам уже в 2,5 раза вырос, коллеги норм, менеджеры не достают, плюсы 17ые вот местами подвезли даже. Но чёртовы кубы сидят в подкорке и шепчут.
>>749913
Не так тебя понял, поскольку даже и не знаком оказался с предложенным тобой контекстом. Пойду просвещаться.
Не так тебя понял, поскольку даже и не знаком оказался с предложенным тобой контекстом. Пойду просвещаться.
Аноны, очень нужна ваша помощь. Прямо жизнь от вас зависит. Нужно написать программу на опенгл, которая открывает 2д изображение и позволяет его вращать. В опенгл я полный ноль, не знаю даже в какую сторону копать.
>>753422
Если ты не мог даже шапку открыть и прочитать несколько уроков с сайтом то тебе, ебанату тупому, ничего не поможет.
Если ты не мог даже шапку открыть и прочитать несколько уроков с сайтом то тебе, ебанату тупому, ничего не поможет.
>>759296
Макс, заебал, у тебя докер образ под центось до сих пор не готов, а ещё что-то пиздишь.
Макс, заебал, у тебя докер образ под центось до сих пор не готов, а ещё что-то пиздишь.
Аноны, привет. Надеюсь, вы еще живы. Вопрос глупый, но надеюсь, вы сможете пояснить мне что к чему.
В чем преимущество OpenGL над Vulkan? Ведь по сути Vulkan это более улучшенный OpenGL. Просто вижу, что в основном все до сих пор используют именно OpenGL. С чем это может быть связано? С непонятным API и его дрочкой или все же есть более весомые причины?
Спасибо!
В чем преимущество OpenGL над Vulkan? Ведь по сути Vulkan это более улучшенный OpenGL. Просто вижу, что в основном все до сих пор используют именно OpenGL. С чем это может быть связано? С непонятным API и его дрочкой или все же есть более весомые причины?
Спасибо!
>>761973
Преимущество только в более простом API и, возможно, более широкой поддержке на старых устройствах.
На огле, чтобы написать вращение кубов достаточно одного дня, если начинаешь совсем с нуля. В вулкане - сложно сказать, ведь сначала надо продраться через всю программную модель, управление ресурсами, написать весьма объёмный бойлерплейт, обернуть его в удачные абстракции для удобства.
Ну и в итоге, если ты рендеришь относительно скромные сцены, не генерируешь очереди отрисовки в куче потоков - ебаться с таким уровнем сложности нахой надо.
Преимущество только в более простом API и, возможно, более широкой поддержке на старых устройствах.
На огле, чтобы написать вращение кубов достаточно одного дня, если начинаешь совсем с нуля. В вулкане - сложно сказать, ведь сначала надо продраться через всю программную модель, управление ресурсами, написать весьма объёмный бойлерплейт, обернуть его в удачные абстракции для удобства.
Ну и в итоге, если ты рендеришь относительно скромные сцены, не генерируешь очереди отрисовки в куче потоков - ебаться с таким уровнем сложности нахой надо.
34 Кб, 419x950>>761973
Никакой весомой причины.
А обратный вопрос, в чем лучше vulkan?
На нём мои 103 куба и 17 треугольников быстрее рисоваться будут? Или такой же шейдер как на opengl внезапно станет работать в два раза быстрее, потому что у карточки внезапно частота в два раза увеличится? Может быть больше документации и примеров в сети?
Да вроде нет ничего подобного. То есть даже если откинуть, что opengl я использую 10 лет - если бы я начинал с нуля, я бы скорее снова выбрал opengl с достаточно большой вероятностью.
Вот скриншот туториала по вулкану. Какая-то хуета про физические устройства и другой мусор - зачем мне это нужно, если 98% кода я буду копировать из раза в раз, и меняться будет только место, где я вершины и шейдеры указываю? И рядом есть opengl, где можно написать glBegin и нарисовать треугольник. И даже если не glBegin - я всё-равно указываю буфер с вершинами - и код рисовки занимает больше места, чем код инициализации, который занимает 10 строчек, а с каким-то sfml/glut или что там - вовсе 1-3.
Да, проблема в этом. Нет мотивации этим заниматься в вулкане, если есть возможность этим не заниматься вообще. И пока не появится какая-то легковесная фигня, которая произведёт всю нужную инициализацию в пару строк, или пока не появится каких-то нужных вещей, которых не будет в opengl - то vulkan выглядит достаточно непривлекательно.
Никакой весомой причины.
А обратный вопрос, в чем лучше vulkan?
На нём мои 103 куба и 17 треугольников быстрее рисоваться будут? Или такой же шейдер как на opengl внезапно станет работать в два раза быстрее, потому что у карточки внезапно частота в два раза увеличится? Может быть больше документации и примеров в сети?
Да вроде нет ничего подобного. То есть даже если откинуть, что opengl я использую 10 лет - если бы я начинал с нуля, я бы скорее снова выбрал opengl с достаточно большой вероятностью.
>С непонятным API и его дрочкой
Вот скриншот туториала по вулкану. Какая-то хуета про физические устройства и другой мусор - зачем мне это нужно, если 98% кода я буду копировать из раза в раз, и меняться будет только место, где я вершины и шейдеры указываю? И рядом есть opengl, где можно написать glBegin и нарисовать треугольник. И даже если не glBegin - я всё-равно указываю буфер с вершинами - и код рисовки занимает больше места, чем код инициализации, который занимает 10 строчек, а с каким-то sfml/glut или что там - вовсе 1-3.
Да, проблема в этом. Нет мотивации этим заниматься в вулкане, если есть возможность этим не заниматься вообще. И пока не появится какая-то легковесная фигня, которая произведёт всю нужную инициализацию в пару строк, или пока не появится каких-то нужных вещей, которых не будет в opengl - то vulkan выглядит достаточно непривлекательно.
>>762424
>>762849
Спасибо за разъяснения!
Да, Vulkan поддерживается на более новых железках. У меня второй комп с Nvidia 820M - она как раз не может в Vulkan. В то время OpenGL существует на более старых железках вполне себе спокойно.
Насколько я знаю, Vulkan получает больше контроля над GPU. Наверное, на этом все преимущества и заканчиваются. Жалко, что ни одно API не является опенсурс, мы бы могли посмотреть на функции у двух API и сравнить их реализацию.
Реально огромный стаж, круто! Что сможешь посоветовать и как вкатиться по-человечески, анонче?
Будем надеятся, что будущие разработчики будут пытаться делать что-то более оптимизированное в плане структуры, ну и функций соответственно.
Спасибо!
>>762849
Спасибо за разъяснения!
>более широкой поддержке на старых устройствах
Да, Vulkan поддерживается на более новых железках. У меня второй комп с Nvidia 820M - она как раз не может в Vulkan. В то время OpenGL существует на более старых железках вполне себе спокойно.
>А обратный вопрос, в чем лучше vulkan?
>Или такой же шейдер как на opengl внезапно станет работать в два раза быстрее, потому что у карточки внезапно частота в два раза увеличится?
Насколько я знаю, Vulkan получает больше контроля над GPU. Наверное, на этом все преимущества и заканчиваются. Жалко, что ни одно API не является опенсурс, мы бы могли посмотреть на функции у двух API и сравнить их реализацию.
>opengl я использую 10 лет
Реально огромный стаж, круто! Что сможешь посоветовать и как вкатиться по-человечески, анонче?
>И пока не появится какая-то легковесная фигня, которая произведёт всю нужную инициализацию в пару строк
Будем надеятся, что будущие разработчики будут пытаться делать что-то более оптимизированное в плане структуры, ну и функций соответственно.
Спасибо!
>>762867
А он тебе нужен? Ты будешь его использовать? У тебя какая-то игра с феноменальными требования к производительности, и потому тебе нужно запариваться ради +10% или даже меньшего? Сейчас вроде все кладут на это, мол карточки скушают любое говно. Нет смысла дрочить производительность, потому что успех игры очень слабо с ней связан и логичнее делать упор на другие аспекты, если у игры нет прям совсем жёстких проблем с производительностью.
>Vulkan получает больше контроля над GPU.
А он тебе нужен? Ты будешь его использовать? У тебя какая-то игра с феноменальными требования к производительности, и потому тебе нужно запариваться ради +10% или даже меньшего? Сейчас вроде все кладут на это, мол карточки скушают любое говно. Нет смысла дрочить производительность, потому что успех игры очень слабо с ней связан и логичнее делать упор на другие аспекты, если у игры нет прям совсем жёстких проблем с производительностью.
>>762867
На собесе такое не ляпни только, лiл. API на то и API, что это не более чем интерфейс к железке, точнее к драйверному уровню. Поэтому в самом вулкане или огле нечего смотреть и сравнивать, имплементация зависит от вендора и является смесью кода и аппаратных особенностей.
> ни одно API не является опенсурс, мы бы могли посмотреть на функции у двух API и сравнить их реализацию.
На собесе такое не ляпни только, лiл. API на то и API, что это не более чем интерфейс к железке, точнее к драйверному уровню. Поэтому в самом вулкане или огле нечего смотреть и сравнивать, имплементация зависит от вендора и является смесью кода и аппаратных особенностей.
>>762874
>>762875
Я просто люблю рыться в подобном говне, реверсер по жизни, лул.
Нет, конечно, для моих скромных проектов это не пригодится на данный момент, это просто к слову о преимуществах было. Использовать или не использовать - немного другой вопрос, как по мне.
Моя оговорка, да.
>>762875
>А он тебе нужен?
Я просто люблю рыться в подобном говне, реверсер по жизни, лул.
Нет, конечно, для моих скромных проектов это не пригодится на данный момент, это просто к слову о преимуществах было. Использовать или не использовать - немного другой вопрос, как по мне.
>На собесе такое не ляпни только, лiл
Моя оговорка, да.
Сап. Сегодня на паре по программированию дед задал дичь, типа там молекулы, связи и прочее. Нужно будет в вводить все картонкой, и соответственно использовать OpenGL, типа в 3х мерном пространстве и чтоб крутить модно было. Что ожидать? Сложно ли вкатиться?
>>762874
Реально вулкан лучше тупо качеством реализации в драйверах, пушо на опенгл при фичах > 3.3 пики точеные и хуи дроченые практически гарантированы.
Реально вулкан лучше тупо качеством реализации в драйверах, пушо на опенгл при фичах > 3.3 пики точеные и хуи дроченые практически гарантированы.
>>769420
Если просто молекул поделать, то легче изучить рейтресинг/реймаршинг и набросать шейдер.
Если просто молекул поделать, то легче изучить рейтресинг/реймаршинг и набросать шейдер.
>>678945 (OP)
Есть кулстори кто как вкатывался в погромисты графики? Как оно вообще работается?
Если я весь лёрн опенгл прочитаю и выполню упражнения, этого достаточно будет для устройства на работку?
Знаю в какой-то степени с++, алгоритмы и структуры данных более-менее норм, немного кумекаю в параллельном программировании, и том что к этой теме причастно.
Дохуя придется задрачивать/изучать по новой?
Сейчас на текущей работке заканчивается проект, есть варик либо там же остаться, но переключиться на компуктер вижен. Но во влажных мечтах хочется работать с графонием, геометрией, математикой и всем таким хотя я туповат, матан в универе сдавал на тройки, не хватало усидчивости все задрочить
Есть кулстори кто как вкатывался в погромисты графики? Как оно вообще работается?
Если я весь лёрн опенгл прочитаю и выполню упражнения, этого достаточно будет для устройства на работку?
Знаю в какой-то степени с++, алгоритмы и структуры данных более-менее норм, немного кумекаю в параллельном программировании, и том что к этой теме причастно.
Дохуя придется задрачивать/изучать по новой?
Сейчас на текущей работке заканчивается проект, есть варик либо там же остаться, но переключиться на компуктер вижен. Но во влажных мечтах хочется работать с графонием, геометрией, математикой и всем таким хотя я туповат, матан в универе сдавал на тройки, не хватало усидчивости все задрочить
>>772146
Знакомый просто студентом ходил на стажировки всякие в гемдев кампании, так и попал на джуна
ну а требования лучше всего в самих вакансиях смотреть
Знакомый просто студентом ходил на стажировки всякие в гемдев кампании, так и попал на джуна
ну а требования лучше всего в самих вакансиях смотреть
видя то что он там делает, он в особо тяжёлую Математику и геометрию не лез никогда, чисто в движке ковыряется и всякие баги чинит
>>772146
Есть история неудачного вката.
Депрессовал, работал в нии, лечил голову. Как больменее полегчало - решил пора бежать. Наудачу закинул письмо в одну из немногих местных контор, пилящих графен. Ни на что не рассчитывал, тк с самооценкой и так плохо + понятно, что такое работа в НИИ. Но мне ответили, отсобесили, готовы были брать вотпрямщас. Я знатно подохуел - думал во попёрло то.
Но всё быстро встало на свои места, когда первым делом надо было быстренько запилить игровой мини-проект на основе собственного продукта. Конечно же я всрал всё проверки на производительность, да и ai хоть сколько-нибудь интересный не написал. Ну и код говнистый вышел.
Короче, вежливо попросили.
В принципе негатива не осталось, всё чинно прошло, даже всё выплатили по отработанному времени. Но веры в себя, кончено, не добавило.
Теперь сижу в унылых телекомах за х2 от того, что тогда просил и не отсвечиваю, ковыряю лениво опенжл и вулканчик в меру своих возможностей.
Есть история неудачного вката.
Депрессовал, работал в нии, лечил голову. Как больменее полегчало - решил пора бежать. Наудачу закинул письмо в одну из немногих местных контор, пилящих графен. Ни на что не рассчитывал, тк с самооценкой и так плохо + понятно, что такое работа в НИИ. Но мне ответили, отсобесили, готовы были брать вотпрямщас. Я знатно подохуел - думал во попёрло то.
Но всё быстро встало на свои места, когда первым делом надо было быстренько запилить игровой мини-проект на основе собственного продукта. Конечно же я всрал всё проверки на производительность, да и ai хоть сколько-нибудь интересный не написал. Ну и код говнистый вышел.
Короче, вежливо попросили.
В принципе негатива не осталось, всё чинно прошло, даже всё выплатили по отработанному времени. Но веры в себя, кончено, не добавило.
Теперь сижу в унылых телекомах за х2 от того, что тогда просил и не отсвечиваю, ковыряю лениво опенжл и вулканчик в меру своих возможностей.
>>772522
Да просто ясно и без экивоков сказали, что нет возможности натаскивать меня, нужен более сильный специалист. Пишем по собственному и расходимся. Всё культурно.
Да просто ясно и без экивоков сказали, что нет возможности натаскивать меня, нужен более сильный специалист. Пишем по собственному и расходимся. Всё культурно.
>>772576
Ты один на проекте весь графоний тянул? Твои работодатели сами какие-то неопытные получается. Они на собесе должны были понять твой уровень, потом посмотреть на тебя на тестовом, потом пустить тебя в проект под присмотром старшего, а потом уже давать самостоятельности. А они возложили всю ответственность за графоний на новичка, который никогда профессионально этим графонием не занимался.
Ты один на проекте весь графоний тянул? Твои работодатели сами какие-то неопытные получается. Они на собесе должны были понять твой уровень, потом посмотреть на тебя на тестовом, потом пустить тебя в проект под присмотром старшего, а потом уже давать самостоятельности. А они возложили всю ответственность за графоний на новичка, который никогда профессионально этим графонием не занимался.
>>772514
Так они графенщика хотели, или мастера на все руки?
>Наудачу закинул письмо в одну из немногих местных контор, пилящих графен.
>надо было быстренько запилить игровой мини-проект на основе собственного продукта
Так они графенщика хотели, или мастера на все руки?
>>772623
>>772627
Вероятно, сумбурно описал суть. Это было а-ля тестовое задание, не кусок чего-то продового или целого проекта. И это была позиция не на ковырятеля движка, а именно под тулзы и проекты на его основе. Графоний там не был под вопросом практически.
Да, потом пришло осознание, что тестовое можно было бы и заранее дать, даже если объёмное - по сути ведь они мне его оплатили. С другой стороны, это помогло мне уйти из госнии и кратно повысить доход. С третьей стороны у меня теперь столько работы, что о вкате в околографику, считай, можно забыть. Да и не то, чтобы был особый выбор на рынке.
>>772627
Вероятно, сумбурно описал суть. Это было а-ля тестовое задание, не кусок чего-то продового или целого проекта. И это была позиция не на ковырятеля движка, а именно под тулзы и проекты на его основе. Графоний там не был под вопросом практически.
Да, потом пришло осознание, что тестовое можно было бы и заранее дать, даже если объёмное - по сути ведь они мне его оплатили. С другой стороны, это помогло мне уйти из госнии и кратно повысить доход. С третьей стороны у меня теперь столько работы, что о вкате в околографику, считай, можно забыть. Да и не то, чтобы был особый выбор на рынке.
Объясните пожалуйста доступным языком, для чего нужны библиотеки типа glad, glew и и.д.?
>>773649
Это разве не работа компановщика?
Это разве не работа компановщика?
>>773649
или они в рантайме подгружаются?
или они в рантайме подгружаются?
>>>678945
Сап. Колупаю опенгл и попутно пилю арканоид.
Почему при спавне нового астеройда, меняют форму все? Как фиксить?
В интернетах советают использовать glpushmatrix и glpopmatrix, но чет не помогает
>>775503
Хотел сеачала на современном гл писать, но там чет сложна. Хочу со старья начать
Хотел сеачала на современном гл писать, но там чет сложна. Хочу со старья начать
>>710377
Какая годнота
Какая годнота
>>775699
>>775688
Нет
Всю жизнь любительски занимался OpenGL, графоном и математикой, со школы ещё. Игрушки делал свои, чужие модифицировал. Потом принял участие в разработке графического движка в вебе уже на полностью коммерческой основе, но в довольно парашной конторе, хотя коллеги там были охуенные, я б с ними ещё поработал. Оттуда меня просто захантили и выдернули пилить убийцу Юнити за многаденег. Там много очень проектов я веду, но везде, как рендер инженер. Все связаны либо с прямой графикой, либо с обратной.
Самое смешное, что меня не взяли делать движок для тридэ трусов в магазине белья, мол, опыта мало, а через полгода захантили на более сочное место. Примерно тогда же, через полгода, пытались всякие Варгейминги к себе рендер инженером утащить, но, очевидно, предложили меньше, раз я не там.
>>775688
> Размещаешь на страничке трёхмерные трусы для рекламы магазина белья?
Нет
Всю жизнь любительски занимался OpenGL, графоном и математикой, со школы ещё. Игрушки делал свои, чужие модифицировал. Потом принял участие в разработке графического движка в вебе уже на полностью коммерческой основе, но в довольно парашной конторе, хотя коллеги там были охуенные, я б с ними ещё поработал. Оттуда меня просто захантили и выдернули пилить убийцу Юнити за многаденег. Там много очень проектов я веду, но везде, как рендер инженер. Все связаны либо с прямой графикой, либо с обратной.
Самое смешное, что меня не взяли делать движок для тридэ трусов в магазине белья, мол, опыта мало, а через полгода захантили на более сочное место. Примерно тогда же, через полгода, пытались всякие Варгейминги к себе рендер инженером утащить, но, очевидно, предложили меньше, раз я не там.
>>775756
Успешный человек итт, завидую белой завистью.
Кстати, чего думаешь о webgpu, готовы ли подсаживаться в будущем на него?
Успешный человек итт, завидую белой завистью.
Кстати, чего думаешь о webgpu, готовы ли подсаживаться в будущем на него?
>>775776
Вообще, мне очень нравятся все поползновения в сторону унификации процессов на видеокарте. Просто буферы, просто операции над числами. Так проще делать и графон, и физику, и всякие другие вкусности на видюхе.
Проблема только в поддерживаемости этих штук на разных устройствах. Если будет так, что бизнесу не выгодно переходить на webgpu, потому что устройства части пользователей не потянут, мне зелёный свет не дадут. Плюс библиотеки желательно иметь. Нет библиотек для работы с картами на webgpu, а игровой движок, например, уже есть, в октябре, вот, портировали Вавилон. Соответственно, переползать частично уже можно.
Свои штуки пока что пилю на WebGL2, хватает для моих нужд, но я книжек начитался, во всякие Pulling Vertices умею, то есть без всяких геометрических шейдеров обойтись могу, например.
Вообще, мне очень нравятся все поползновения в сторону унификации процессов на видеокарте. Просто буферы, просто операции над числами. Так проще делать и графон, и физику, и всякие другие вкусности на видюхе.
Проблема только в поддерживаемости этих штук на разных устройствах. Если будет так, что бизнесу не выгодно переходить на webgpu, потому что устройства части пользователей не потянут, мне зелёный свет не дадут. Плюс библиотеки желательно иметь. Нет библиотек для работы с картами на webgpu, а игровой движок, например, уже есть, в октябре, вот, портировали Вавилон. Соответственно, переползать частично уже можно.
Свои штуки пока что пилю на WebGL2, хватает для моих нужд, но я книжек начитался, во всякие Pulling Vertices умею, то есть без всяких геометрических шейдеров обойтись могу, например.
>>775794
А ещё добавлю, что важно не забывать про всякие разные применения графона помимо гейдева. Заработать на этом можно, главное не плеваться, когда предлагают другие сферы. ГИС, медицина и прочие мультимедиа.
А ещё добавлю, что важно не забывать про всякие разные применения графона помимо гейдева. Заработать на этом можно, главное не плеваться, когда предлагают другие сферы. ГИС, медицина и прочие мультимедиа.
>>775795
А какой минимум надо знать, чтобы претендовать на заработок, что бы ты на собесе спрашивал?
А какой минимум надо знать, чтобы претендовать на заработок, что бы ты на собесе спрашивал?
>>775797
В идеале портфолио. Потому что графон лучше видно на картинке, очевидно. Вопрос, который можно считать классикой, это вопрос про то, что такое ортогональная матрица. Если на него не ответить, и портфолио нет, можно особо не рассчитывать тогда. Я не знаю, почему так сложилось, но такой вот прикол заметил. Если хочется именно в гейдев, знать базовые штуки, вроде PBR, HDR, подповерхностное рассеивание, отложенный рендер, отражения, переходы между пространствами. Касательное пространство, мировое, локальное, видовое, клип спейс. Вообще, знать пайплайн отрисовки обязательно. Если что-то из этого ручками не делал, но знаешь термины, где посмотреть, сможешь по гайдам базовую реализацию сделать, то уже хорошо. Морфинг, скелетная анимация, иногда инверсная кинематика.
Если нет цели делать или переделывать движки, то достаточно представлять, что это такое и как с этим работать. 7 лет назад даже на английском не было особо литературы на эти темы, сейчас есть даже на русском. Учи сколько влезет.
Если уместить это в одно предложение, то достаточно шарить в математике 10-11 класса, линейную алгебру знать на уровне первого курса технического универа. Все остальное это уже применение этих знаний.
Ну, про то, что надо уметь писать код, я умолчу, это и так понятно. Могут спросить алгоритмы, структуры данных, но это, скорее, убедиться, что ты не овощ. Можем списаться в телеге, обсудим подробнее.
marco.franchpu.etti ANUSySI9a PUNCTUMr`k^u
В идеале портфолио. Потому что графон лучше видно на картинке, очевидно. Вопрос, который можно считать классикой, это вопрос про то, что такое ортогональная матрица. Если на него не ответить, и портфолио нет, можно особо не рассчитывать тогда. Я не знаю, почему так сложилось, но такой вот прикол заметил. Если хочется именно в гейдев, знать базовые штуки, вроде PBR, HDR, подповерхностное рассеивание, отложенный рендер, отражения, переходы между пространствами. Касательное пространство, мировое, локальное, видовое, клип спейс. Вообще, знать пайплайн отрисовки обязательно. Если что-то из этого ручками не делал, но знаешь термины, где посмотреть, сможешь по гайдам базовую реализацию сделать, то уже хорошо. Морфинг, скелетная анимация, иногда инверсная кинематика.
Если нет цели делать или переделывать движки, то достаточно представлять, что это такое и как с этим работать. 7 лет назад даже на английском не было особо литературы на эти темы, сейчас есть даже на русском. Учи сколько влезет.
Если уместить это в одно предложение, то достаточно шарить в математике 10-11 класса, линейную алгебру знать на уровне первого курса технического универа. Все остальное это уже применение этих знаний.
Ну, про то, что надо уметь писать код, я умолчу, это и так понятно. Могут спросить алгоритмы, структуры данных, но это, скорее, убедиться, что ты не овощ. Можем списаться в телеге, обсудим подробнее.
>>775799
Сейчас у меня знания только по школьной программе, основам линала и немного по шейдерам, простенький софт рендениринг писал по туториалам. Думаю, стоит ли вкатываться, вот начну сейчас опенгл учить и лет через 5 только смогу на джуна претендовать. Как у тебя так получается, со школы выбрать тему и продолжать долбить ее? Меня вот все метало, то рисовать хотел, то 3д моделить, то пиксельарт, то геймдизайнить, то графику прогать.
Сейчас у меня знания только по школьной программе, основам линала и немного по шейдерам, простенький софт рендениринг писал по туториалам. Думаю, стоит ли вкатываться, вот начну сейчас опенгл учить и лет через 5 только смогу на джуна претендовать. Как у тебя так получается, со школы выбрать тему и продолжать долбить ее? Меня вот все метало, то рисовать хотел, то 3д моделить, то пиксельарт, то геймдизайнить, то графику прогать.
>>775803
У меня с пяти лет ясность и понимание того, что хочу. В пять лет понял, что хочу быть погромистом и делать игры, в седьмом классе начал делать игры, в десятом классе понял, что в играх больше всего нравится делать графику, после универа это стало монетизированным хобби.
5 лет учить это не придется, можно вкатиться так же быстро, как и в любой другой нормальный кодинг, за год-полтора. Нет, не месяц или два, за такое короткое время ящитаю не вкатишься
Единственное, математику знать и понимать нужно, но это для любых технических профессий, вроде как, мастхэв, так что можно особо не учитывать.
Ну, а ещё если есть, кому учить тебя, то совсем просто становится. Я-то сам шишки набивал, а ты сейчас можешь кучу гайдов посмотреть.
Но, как и в любом деле, практика важна. Если ты пять лет реально кодить будешь, а не курсы от скиллбокса на фоне слушать, то спокойно станешь сеньором за это время.
У меня с пяти лет ясность и понимание того, что хочу. В пять лет понял, что хочу быть погромистом и делать игры, в седьмом классе начал делать игры, в десятом классе понял, что в играх больше всего нравится делать графику, после универа это стало монетизированным хобби.
5 лет учить это не придется, можно вкатиться так же быстро, как и в любой другой нормальный кодинг, за год-полтора. Нет, не месяц или два, за такое короткое время ящитаю не вкатишься
Единственное, математику знать и понимать нужно, но это для любых технических профессий, вроде как, мастхэв, так что можно особо не учитывать.
Ну, а ещё если есть, кому учить тебя, то совсем просто становится. Я-то сам шишки набивал, а ты сейчас можешь кучу гайдов посмотреть.
Но, как и в любом деле, практика важна. Если ты пять лет реально кодить будешь, а не курсы от скиллбокса на фоне слушать, то спокойно станешь сеньором за это время.
>>775815
:3
:3
>>775756
Что такое "обратная графика"? Распознавание изображений?
>либо с прямой графикой, либо с обратной.
Что такое "обратная графика"? Распознавание изображений?
>>775836
В узком смысле да. В широком она в себя включает распознавание изображений, но не только его.
В узком смысле да. В широком она в себя включает распознавание изображений, но не только его.
>>775849
Где можно почитать? Не нахожу такого термина в гугле - "обратная графика". По каким ключевым словам искать?
Где можно почитать? Не нахожу такого термина в гугле - "обратная графика". По каким ключевым словам искать?
>>775850
Уф, начинай с компьютерного зрения. Возможно, мой термин не самый правильный. Он у нас с коллегами устоялся, но не факт, что он общепринятый.
Уф, начинай с компьютерного зрения. Возможно, мой термин не самый правильный. Он у нас с коллегами устоялся, но не факт, что он общепринятый.
>>775814
Тут и плюсы и минусы. Информации море, не понятно что, в какой последовательности и до какой степени глубины изучать. Можно обложиться десятью учебниками линала, которые за 2 года не прочитаешь, а до практического программирования так и не дойти. А вот трансуха Freya Holmér за 10 лет карьеры в геймдеве не знает, как матрицы умножать, но написала визуальный редактор шейдеров для юнити, который неплохо продался и позволил ей уйти с работы по найму.
>Я-то сам шишки набивал, а ты сейчас можешь кучу гайдов посмотреть
Тут и плюсы и минусы. Информации море, не понятно что, в какой последовательности и до какой степени глубины изучать. Можно обложиться десятью учебниками линала, которые за 2 года не прочитаешь, а до практического программирования так и не дойти. А вот трансуха Freya Holmér за 10 лет карьеры в геймдеве не знает, как матрицы умножать, но написала визуальный редактор шейдеров для юнити, который неплохо продался и позволил ей уйти с работы по найму.
>>776120
Так написать нодовый редактор шейдеров это пара вечеров. Там не нужно знание математики, не нужно знание самой графики, это просто кодогенератор из графа. Фишка в том, что это была новинка, никто такого раньше не делал, а не в каком-то мега навыке или узких знаниях.
Так написать нодовый редактор шейдеров это пара вечеров. Там не нужно знание математики, не нужно знание самой графики, это просто кодогенератор из графа. Фишка в том, что это была новинка, никто такого раньше не делал, а не в каком-то мега навыке или узких знаниях.
>>776122
Нужно хотя бы умение программировать шейдеры. Я не говорю о том, что это сложно. Я о том, что она видимо отучилась в каком-то геймдев ПТУ, где ее за ручку провели в индустрию, давали исключительно практические и актуальные навыки/методики, не особо углубляясь в теорию. А если бы она обучалась сама, хаотически, могла бы, например, копать линал до каких-нибудь проективных модулей.
Нужно хотя бы умение программировать шейдеры. Я не говорю о том, что это сложно. Я о том, что она видимо отучилась в каком-то геймдев ПТУ, где ее за ручку провели в индустрию, давали исключительно практические и актуальные навыки/методики, не особо углубляясь в теорию. А если бы она обучалась сама, хаотически, могла бы, например, копать линал до каких-нибудь проективных модулей.
>>776127
Хз, редкий человек сам так раскопает линал, а основам cgi в любом техническом вузе учат без углубления во все тонкости. Простейший шейдер и базовый пайплайн отрисовки расскажут.
Хз, редкий человек сам так раскопает линал, а основам cgi в любом техническом вузе учат без углубления во все тонкости. Простейший шейдер и базовый пайплайн отрисовки расскажут.
Что по modern opengl почитать? Тыкал раньше во времена glBegin, дисплей листов и прочего такого. Хочу простенькое 2д порисовать, вроде немного оверкилл конечно.
>>776144
Потому что я аутист Хочется попердолиться на низкому уровне, может еще разобраться с современными профайлерами.
Потому что я аутист Хочется попердолиться на низкому уровне, может еще разобраться с современными профайлерами.
>>776151
Это на самом деле звучит жутко интересно, и вулкан изучить с нуля и в драйвере mesa на прыщах поковыряться. Только на это нужно какое-то нездоровое количество времени. А меня только на 2д-хуиту со своим движком чувствую хватит.
Это на самом деле звучит жутко интересно, и вулкан изучить с нуля и в драйвере mesa на прыщах поковыряться. Только на это нужно какое-то нездоровое количество времени. А меня только на 2д-хуиту со своим движком чувствую хватит.
Пытался написать объемные облака на шейдертое и отвалилась видюха. Бывает такое или графика не мое?
>>776328
Сложно себе такое представить. Может, ты просто не переключил дефолтную видюху с интегрированной на дискретную. Считай, решил гвозди позабивать киянкой, а нужен для этого молоток.
Сложно себе такое представить. Может, ты просто не переключил дефолтную видюху с интегрированной на дискретную. Считай, решил гвозди позабивать киянкой, а нужен для этого молоток.
Сижу на линухе, решил попробовать нарисовать треугольник с помощью OpenGL, по гайду как на learnopengl.com, столкнулся с проблемой. #include <glad/glad.h> пишет "Директория/Файл не найдены"
Не нравится мне что glad нужно в папку с исходным кодом кидать, ох если бы он был в /usr/lib
Подскажите аноны, что можно сделать? Мне сейчас чисто по гайду бы glad. потом может и перейду на что другое. Пока в плюсах новичок
Не нравится мне что glad нужно в папку с исходным кодом кидать, ох если бы он был в /usr/lib
Подскажите аноны, что можно сделать? Мне сейчас чисто по гайду бы glad. потом может и перейду на что другое. Пока в плюсах новичок
>>781819
Ставь glew, он везде должен быть в репах.
1) Везде в модулях где юзаешь OpenGL пишешь только #include <GL/glew.h>
2) перед самым первым обращением к OpenGL делаешь инициализацию glew, у меня например так:
GLenum glewResult = glewInit();
if ( glewResult != GLEW_OK ) {
printf( "GLEW Error: %s\n.", glewGetErrorString( glewResult ) );
return false;
}
Я даже поставил это после SDL_GL_CreateContext, и работает норм.
3) в настройках сборки проекта в своей среде пишешь в список библиотек GLEW и GL.
4) PROFIT!
Единственное, если правильно помню, когда будешь собирать проект под cygwin/mingw/msys, надо будет дополнительно рядом с экзешником положить дллку от glew, ну там вообще собрать redistributable - немного повозиться с ldd.
Ставь glew, он везде должен быть в репах.
1) Везде в модулях где юзаешь OpenGL пишешь только #include <GL/glew.h>
2) перед самым первым обращением к OpenGL делаешь инициализацию glew, у меня например так:
GLenum glewResult = glewInit();
if ( glewResult != GLEW_OK ) {
printf( "GLEW Error: %s\n.", glewGetErrorString( glewResult ) );
return false;
}
Я даже поставил это после SDL_GL_CreateContext, и работает норм.
3) в настройках сборки проекта в своей среде пишешь в список библиотек GLEW и GL.
4) PROFIT!
Единственное, если правильно помню, когда будешь собирать проект под cygwin/mingw/msys, надо будет дополнительно рядом с экзешником положить дллку от glew, ну там вообще собрать redistributable - немного повозиться с ldd.
>>781837
Макаба ибаная, табы в коде в \t превратила, ну ты понел.
Макаба ибаная, табы в коде в \t превратила, ну ты понел.
>>781837
За glew спасибо, сейчас попробовал glut (нашёл его раньше). окно спокойно запустилось.
Какая меж ними разница? Смогу ли я потом легко перейти на glew?
Чёт меня поражает что есть куча подобных либ, ещё попробуй пойми что к чему.
За glew спасибо, сейчас попробовал glut (нашёл его раньше). окно спокойно запустилось.
Какая меж ними разница? Смогу ли я потом легко перейти на glew?
Чёт меня поражает что есть куча подобных либ, ещё попробуй пойми что к чему.
>>781844
Glew и glut - это две большие разницы. Glew - это чтоб легко и просто подключить функционал OpenGL выше 1.1 (#include <GL/gl.h> даст только старую версию API). Советую glut выбросить и забыть, eсли тебе нужно чем-то создавать окна, а потом еще и обрабатывать ввод - бери SDL, он уже в ряде движков давно используется именно для этих целей.
Дохрена уроков с glu и glut болтается в интернетах, но они устарели чуть более чем полностью, выкинь их. Например функции типа gluProject - для установки проекционной матрицы при использовании fixed pipeline, это было 15 лет назад актуально, а после выхода OpenGL 3.0 стало говном мамонта, сегодня ты сам отвечаешь за матричную арифметику, сам запихиваешь все в шейдеры.
Glew и glut - это две большие разницы. Glew - это чтоб легко и просто подключить функционал OpenGL выше 1.1 (#include <GL/gl.h> даст только старую версию API). Советую glut выбросить и забыть, eсли тебе нужно чем-то создавать окна, а потом еще и обрабатывать ввод - бери SDL, он уже в ряде движков давно используется именно для этих целей.
Дохрена уроков с glu и glut болтается в интернетах, но они устарели чуть более чем полностью, выкинь их. Например функции типа gluProject - для установки проекционной матрицы при использовании fixed pipeline, это было 15 лет назад актуально, а после выхода OpenGL 3.0 стало говном мамонта, сегодня ты сам отвечаешь за матричную арифметику, сам запихиваешь все в шейдеры.
Насколько реально использовать векторную графику на 3д объектах/полигонах. Есть ли примеры?
>>782513
Будешь ты "HD" картинку делать только из полигонов?
Я имею в виду проекцию векторной текстуры на полигон, что бы при увеличении не было как с растровой графикой. Я понимаю что векторная приносит свои ограничения, но для Low Poly с текстурированием, очень даже зайдёт. Однако если использовать растровую графику, можно будет увидеть отдельные пиксели, независимо от размера холста (при увеличении). Да и грузить дохуя большое изображение для текстуры это расход памяти. При растровых текстурах ты сможешь увидеть только собственные пиксели экрана, увеличивай сколько хочешь. Ну думаю ты знаешь.
Будешь ты "HD" картинку делать только из полигонов?
Я имею в виду проекцию векторной текстуры на полигон, что бы при увеличении не было как с растровой графикой. Я понимаю что векторная приносит свои ограничения, но для Low Poly с текстурированием, очень даже зайдёт. Однако если использовать растровую графику, можно будет увидеть отдельные пиксели, независимо от размера холста (при увеличении). Да и грузить дохуя большое изображение для текстуры это расход памяти. При растровых текстурах ты сможешь увидеть только собственные пиксели экрана, увеличивай сколько хочешь. Ну думаю ты знаешь.
>>782515
Видел статью про векторные текстуры от чуваков из Apple и Intel. но там вроде фпс был в районе 20.
Видел статью про векторные текстуры от чуваков из Apple и Intel. но там вроде фпс был в районе 20.
>>782520
Грустно. Что ж, спасибо за инфу, поищу
Грустно. Что ж, спасибо за инфу, поищу
>>782515
Вот пропустил ты слово "текстуры" - и стало нихуя непонятно, что ты имел в виду.
Если текстура монохромная, либо тебе достаточно небольшого числа цветов, то я бы попробовал SDF. На самом деле это растр, но хитрый. Качество может быть и не как у реального векторного изображения, но думаю, что это лучшее, что можно получить балансируя между расходом памяти и производительности.
Вот пропустил ты слово "текстуры" - и стало нихуя непонятно, что ты имел в виду.
Если текстура монохромная, либо тебе достаточно небольшого числа цветов, то я бы попробовал SDF. На самом деле это растр, но хитрый. Качество может быть и не как у реального векторного изображения, но думаю, что это лучшее, что можно получить балансируя между расходом памяти и производительности.
>>776120
Даже любопытно стало, можешь скинуть таймкод там где она не умеет матрицы умножать, наоборот казалось, что она в видео объясняла какую-то совсем простую базу.
Даже любопытно стало, можешь скинуть таймкод там где она не умеет матрицы умножать, наоборот казалось, что она в видео объясняла какую-то совсем простую базу.
>>784824
Путается, как составить матрицу трансформации
https://youtu.be/XiwEyopOMqg?t=6737
Говорит, что догадывается, как умножать матрицу на вектор, но не уверена. А как искать обратную матрицу вообще не знает.
https://youtu.be/XiwEyopOMqg?t=7264
Наверно можно пользоваться исключительно библиотечными функциями, но я думал, графический программист не должен плавать в этих вопросах, это же база.
Путается, как составить матрицу трансформации
https://youtu.be/XiwEyopOMqg?t=6737
Говорит, что догадывается, как умножать матрицу на вектор, но не уверена. А как искать обратную матрицу вообще не знает.
https://youtu.be/XiwEyopOMqg?t=7264
Наверно можно пользоваться исключительно библиотечными функциями, но я думал, графический программист не должен плавать в этих вопросах, это же база.
>>784879
Спасибо!
Есть еще вопросик, наверняка платина для этого треда. Что почитать-посмотреть что бы раз и навсегда разобраться с матрицами, векторами и операциями над ними в рамках изучения opengl? Лучше, конечно, что-то доступное, короткое. Этого хватит? https://learnopengl.com/Getting-started/Transformations или пойти дальше по ссылкам, которые автор в статье приводит. Предпочтительно русский, но смогу и с источниками на английском. Да и в целом что там еще понадобится из линейной алгебры?
Спасибо!
Есть еще вопросик, наверняка платина для этого треда. Что почитать-посмотреть что бы раз и навсегда разобраться с матрицами, векторами и операциями над ними в рамках изучения opengl? Лучше, конечно, что-то доступное, короткое. Этого хватит? https://learnopengl.com/Getting-started/Transformations или пойти дальше по ссылкам, которые автор в статье приводит. Предпочтительно русский, но смогу и с источниками на английском. Да и в целом что там еще понадобится из линейной алгебры?
>>784881
Хочу уточнить, что я ее не осуждаю. Может и правильно, что надо не глубоко копать в теорию, а в первую очередь осваивать практические навыки. Вся линейная алгебра - это перебор, а источника, где объяснялось бы все что надо подробно и при этом без лишнего, я не знаю.
Хочу уточнить, что я ее не осуждаю. Может и правильно, что надо не глубоко копать в теорию, а в первую очередь осваивать практические навыки. Вся линейная алгебра - это перебор, а источника, где объяснялось бы все что надо подробно и при этом без лишнего, я не знаю.
>>784879
Посмотрел на превью видео, у неё там ещё зелёный с красным перепутаны.
Обычно люди обозначают ось X красным, ось Y зелёным, а Z синим. Ладно уже борьбу, что Y или Z — высота, но цвета-то лучше правильно изображать.
Либо она так и обозначила, но система координат в другую сторону закручена. Видео не смотрел, мог ощибиться.
Посмотрел на превью видео, у неё там ещё зелёный с красным перепутаны.
Обычно люди обозначают ось X красным, ось Y зелёным, а Z синим. Ладно уже борьбу, что Y или Z — высота, но цвета-то лучше правильно изображать.
Либо она так и обозначила, но система координат в другую сторону закручена. Видео не смотрел, мог ощибиться.
>>784990
Если ты откроешь КАД для карапей, 3дмакс и анрыль, то ты в первую очередь заинтересуешься тем, что системы там разные, а цвета уж дело десятое.
Если ты откроешь КАД для карапей, 3дмакс и анрыль, то ты в первую очередь заинтересуешься тем, что системы там разные, а цвета уж дело десятое.
>>784990
Что не так с пальцами на превью? Большой (X) - красный, указательный (Y) - зеленый, средний (Z) - синий. Показывает левой рукой, система координат левая, как в юнити.
Что не так с пальцами на превью? Большой (X) - красный, указательный (Y) - зеленый, средний (Z) - синий. Показывает левой рукой, система координат левая, как в юнити.
Ну что, рисователи треугольников, нашли свое призвание в графикс софтвер инжиниринге?
https://habr.com/ru/post/599575/
https://habr.com/ru/post/599575/
>>785088
Хмм, и правда, моя ошибка.
Я думал, что Годот плохой с его обозначением высоты через Y. Но я не думал, что Юнити вообще с левой системой координат.
Хмм, и правда, моя ошибка.
Я думал, что Годот плохой с его обозначением высоты через Y. Но я не думал, что Юнити вообще с левой системой координат.
27 Кб, 648x150Юзаю библиотеку glm
Чёт там за фигня с матрицами?
В гайдах сначала translate потом rotate, но разве должно быть не наоборот?
Попробовал после этого ещё и размер изменить
выходит в glm порядок обратный, так что ли?
Зачем это сделано?
Чёт там за фигня с матрицами?
В гайдах сначала translate потом rotate, но разве должно быть не наоборот?
Попробовал после этого ещё и размер изменить
выходит в glm порядок обратный, так что ли?
Зачем это сделано?
>>785428
Ну в шейдере у тебя будет TRS*vertex. Порядок применения как раз как надо: масштаб, поворот, перенос.
Ну в шейдере у тебя будет TRS*vertex. Порядок применения как раз как надо: масштаб, поворот, перенос.
>>785460
Дело не в шейдере, в шейдер у меня поступают уже готовые матрицы
model
view
projection
Но, мне интересно почему в glm я сначало создаю еденичную матрицу, потом делаю перенос, поворот, масштаб.
Дело не в шейдере, в шейдер у меня поступают уже готовые матрицы
model
view
projection
Но, мне интересно почему в glm я сначало создаю еденичную матрицу, потом делаю перенос, поворот, масштаб.
>>785460
Ладно, может я туплю, в glm мы оперируем матрицами, а не вектором, так что может там и есть смысл в таком порядке,
Но уже в шейдере это выглядит как T R S vertex
Просто меня сильно запутало это, то что в программе я должен создавать матрицу модели, но применять действия в обратном порядке
Если всё же кто-то сможет мне объяснить, буду благодарен
Ладно, может я туплю, в glm мы оперируем матрицами, а не вектором, так что может там и есть смысл в таком порядке,
Но уже в шейдере это выглядит как T R S vertex
Просто меня сильно запутало это, то что в программе я должен создавать матрицу модели, но применять действия в обратном порядке
Если всё же кто-то сможет мне объяснить, буду благодарен
>>785462
Ещё раз, итоговая матрица у тебя есть комбинация в следующем порядке T x R x S. Так ты передашь в шейдер. Поскольку в огл матрицы считаются column-major, то матрица ставится слева от преобразуемой вершины. Именно поэтому в коде у тебя порядок конкатенации обратный.
Ещё раз, итоговая матрица у тебя есть комбинация в следующем порядке T x R x S. Так ты передашь в шейдер. Поскольку в огл матрицы считаются column-major, то матрица ставится слева от преобразуемой вершины. Именно поэтому в коде у тебя порядок конкатенации обратный.
>>787272
dynamic shadows
dynamic shadows
>>787272
Как вообще тени рисуют? Есть два основных алгоритма: теневые карты и теневые объемы. В первом случае ты рендеришь буфер глубины для всего, что попадает поле зрения источника света - теневую карту, затем при рендере тени в буфере кадра ты сравниваешь значения в теневой карте и расстояния от фрагментов до источника. Во втором случае ты ебешься с геометрией, которая попадает в поле зрения источника, чтобы создать новый геометрический объект, и при рендере кадра затемняешь то, что попадает внутрь этого объекта. И так каждый кадр. Если у тебя дисплейсмент - значит ты должен его воспроизводить и при рендере теневой карты, и при создании теневого объема. Никакой магии, только ебля.
Как вообще тени рисуют? Есть два основных алгоритма: теневые карты и теневые объемы. В первом случае ты рендеришь буфер глубины для всего, что попадает поле зрения источника света - теневую карту, затем при рендере тени в буфере кадра ты сравниваешь значения в теневой карте и расстояния от фрагментов до источника. Во втором случае ты ебешься с геометрией, которая попадает в поле зрения источника, чтобы создать новый геометрический объект, и при рендере кадра затемняешь то, что попадает внутрь этого объекта. И так каждый кадр. Если у тебя дисплейсмент - значит ты должен его воспроизводить и при рендере теневой карты, и при создании теневого объема. Никакой магии, только ебля.
>>787294
Уже считай нету - я по крайне мере за последние лет десять не видел нигде, вот в играх 2005 часто замечал, что там именно объёмы. Слишком сложная технология, зачем это нужно - если можно просто карту теней достаточного разрешения зафигачить? Да ещё и мягкие тени через теневые объёмы делать по идее только если постобработкой можно и выглядить это может не очень. А если у тебя есть растительность/сетка/что_угодно_ещё, где форма листьев передана текстурой, то - ну ты понял что будет с тенью - а буферу до фени, альфа-тест при заполнении буфера тени очень быстры, если не обрабатывать освещение и остальные каналы.
>и теневые объемы
Уже считай нету - я по крайне мере за последние лет десять не видел нигде, вот в играх 2005 часто замечал, что там именно объёмы. Слишком сложная технология, зачем это нужно - если можно просто карту теней достаточного разрешения зафигачить? Да ещё и мягкие тени через теневые объёмы делать по идее только если постобработкой можно и выглядить это может не очень. А если у тебя есть растительность/сетка/что_угодно_ещё, где форма листьев передана текстурой, то - ну ты понял что будет с тенью - а буферу до фени, альфа-тест при заполнении буфера тени очень быстры, если не обрабатывать освещение и остальные каналы.
>>787379
Ну, я рассказал то что знаю.
Касательно теневых карт ебля тоже немалая есть, одни только алгоритмы фильтрации чего стоят, или техника с моментами. А уж каскадные по-моему вообще на грани добра и зла, потому что либо они используются для камеры с прибитым гвоздями ракурсом и только для теней от солнца, либо что-то не покрывается тенями (ГТА5 страдала этим). И вроде их пихали даже в какие-то коридорные шутеры.
Какого угодно разрешения ты теневые карты не сделаешь, потому тебе их может быть нужно больше одной штуки, а видеопамять не резиновая, и свопаться как оперативка не умеет (на самом деле немного умеет с помощью драйвера, но лучше в рамках своего приложения на это не рассчитывать, и экономить память, а перезагрузку ресурсов делать самому). Да, еще надо генерировать после каждого рендера карты новые мип-уровни, иначе у тебя тени в далеких от камеры фрагментах будут мерцать, а для теневой карты фильтрация не такая, как для обычной текстуры, там надо не усреднять пиксели, а брать максимум или минимум в зависимости от того, в какой системе у тебя глубина пишется (z или 1/z - есть такие приколы). И вообще при любом текстурировании чем меньше разрешение текстуры, тем меньше кеш-промахов, меньше обращений текстурных юнитов к видеопамяти - быстрее рендер.
Ах да, у нас уже RTX 20 и RTX 30 есть, и на подходе RTX 40, ну так там все условно просто: пустили пучок лучей от фрагмента в источник света (пучок - потому что источник не точечный в 99.9% случаев, какой бы мелкий он ни был), сколько лучей долетело - такая доля освещения от источника придет во фрагмент. Далее ебля с оптимизацией, потому что пускать тысячи лучей в реалтайме - слайдшоу получится, а источников редко бывает одна штука на всю сцену, и еще вторичное освещение надо считать, фотонную карту держать для него или что-то в этом роде. И это тоже не все развлечения в процессе.
Ну, я рассказал то что знаю.
Касательно теневых карт ебля тоже немалая есть, одни только алгоритмы фильтрации чего стоят, или техника с моментами. А уж каскадные по-моему вообще на грани добра и зла, потому что либо они используются для камеры с прибитым гвоздями ракурсом и только для теней от солнца, либо что-то не покрывается тенями (ГТА5 страдала этим). И вроде их пихали даже в какие-то коридорные шутеры.
Какого угодно разрешения ты теневые карты не сделаешь, потому тебе их может быть нужно больше одной штуки, а видеопамять не резиновая, и свопаться как оперативка не умеет (на самом деле немного умеет с помощью драйвера, но лучше в рамках своего приложения на это не рассчитывать, и экономить память, а перезагрузку ресурсов делать самому). Да, еще надо генерировать после каждого рендера карты новые мип-уровни, иначе у тебя тени в далеких от камеры фрагментах будут мерцать, а для теневой карты фильтрация не такая, как для обычной текстуры, там надо не усреднять пиксели, а брать максимум или минимум в зависимости от того, в какой системе у тебя глубина пишется (z или 1/z - есть такие приколы). И вообще при любом текстурировании чем меньше разрешение текстуры, тем меньше кеш-промахов, меньше обращений текстурных юнитов к видеопамяти - быстрее рендер.
Ах да, у нас уже RTX 20 и RTX 30 есть, и на подходе RTX 40, ну так там все условно просто: пустили пучок лучей от фрагмента в источник света (пучок - потому что источник не точечный в 99.9% случаев, какой бы мелкий он ни был), сколько лучей долетело - такая доля освещения от источника придет во фрагмент. Далее ебля с оптимизацией, потому что пускать тысячи лучей в реалтайме - слайдшоу получится, а источников редко бывает одна штука на всю сцену, и еще вторичное освещение надо считать, фотонную карту держать для него или что-то в этом роде. И это тоже не все развлечения в процессе.
>>787381
Точно? Я ни разу не видел, чтобы размер текстуры хоть в одной игре влиял на что-то кроме времени загрузки. Там же выборка из текстуры для конкретного пикселя никак не связана с размером текстуры.
> И вообще при любом текстурировании чем меньше разрешение текстуры
Точно? Я ни разу не видел, чтобы размер текстуры хоть в одной игре влиял на что-то кроме времени загрузки. Там же выборка из текстуры для конкретного пикселя никак не связана с размером текстуры.
>>787514
Это только означает что производительность не упирается именно в чтение из текстур - и это в какой-то степени хорошо.
Связана, особенно когда не одна-единственная отдельная выборка. Чем больше выборок делается в шейдере, и чем дальше они разнесены - тем больше чтений из глобальной памяти должен сделать текстурный юнит и передать конкретному ядру, а остальные в этот момент - постоят в очереди, текстурных юнитов на всех не хватит. Посмотри на развитие алгоритмов блюра, как там хитрят, чтобы уменьшить количество выборок относительно финального пикселя. Еще допустим у тебя анизотропная фильтрация в 16 выборок вместо одной. Опять же в настройках графики у игр нередко это идет как опция, а не стандарт.
>Я ни разу не видел, чтобы размер текстуры хоть в одной игре влиял на что-то кроме времени загрузки.
Это только означает что производительность не упирается именно в чтение из текстур - и это в какой-то степени хорошо.
>выборка из текстуры для конкретного пикселя никак не связана с размером текстуры
Связана, особенно когда не одна-единственная отдельная выборка. Чем больше выборок делается в шейдере, и чем дальше они разнесены - тем больше чтений из глобальной памяти должен сделать текстурный юнит и передать конкретному ядру, а остальные в этот момент - постоят в очереди, текстурных юнитов на всех не хватит. Посмотри на развитие алгоритмов блюра, как там хитрят, чтобы уменьшить количество выборок относительно финального пикселя. Еще допустим у тебя анизотропная фильтрация в 16 выборок вместо одной. Опять же в настройках графики у игр нередко это идет как опция, а не стандарт.
>>787555
Это в теории. А можешь описать какую демку мне составить, чтобы была разница между текстурой 256х256 и 8192х8192, или между х1 и х16 анизотропной фильтрацией? Или в какой игре подобное приводит к изменению производительности?
Так там стараются уменьшить количество выборок. А при изменении размера текстуры количество выборок остаётся таким же, просто они делаются из текстуры другого размера. И предположу что анизотропная х16 тоже на аппаратном уровне исполнена, и выполняется за такое же время как и обычная х1.
>ем больше чтений из глобальной памяти должен сделать
Это в теории. А можешь описать какую демку мне составить, чтобы была разница между текстурой 256х256 и 8192х8192, или между х1 и х16 анизотропной фильтрацией? Или в какой игре подобное приводит к изменению производительности?
>на развитие алгоритмов блюра
Так там стараются уменьшить количество выборок. А при изменении размера текстуры количество выборок остаётся таким же, просто они делаются из текстуры другого размера. И предположу что анизотропная х16 тоже на аппаратном уровне исполнена, и выполняется за такое же время как и обычная х1.
>>787628
В Скачи@Мочи приводит к изменению производительности. Вообще, сложно представить, как скачки по большему куску оперативы могут не повлиять на производительность.
В Скачи@Мочи приводит к изменению производительности. Вообще, сложно представить, как скачки по большему куску оперативы могут не повлиять на производительность.
Можно ли получить список текущих стейтов? То есть что там сейчас включено/выключено в стейт машине огла?
>>790851
Намного легче
Намного легче
>>792104
Добро пожаловать в обработку ошибок в чистом С
Добро пожаловать в обработку ошибок в чистом С
>>792104
можно отключить эту хуиту - нужно выкинуть из проекта sdlmain.lib и перед включением SDL поставить дефайн
#define SDL_MAIN_HANDLED
Ну и перед вызовом инициализации SDL взывать SDL_SetMainReady
Вот пример
https://wiki.libsdl.org/SDL_SetMainReady
----------------------------------------------
Да, ебаная наркомания, тоже ненавижу программистов которые наворачивают какую-то хуиту на ровном месте, там где это нихуя ничего не дает (даже если посмотреть код sdl main - то там нихуя не делается серьзного и важного - именно такого что нужно SDL).
>Отдельный привет чувакам из SDL, которые дефайнят main.
можно отключить эту хуиту - нужно выкинуть из проекта sdlmain.lib и перед включением SDL поставить дефайн
#define SDL_MAIN_HANDLED
Ну и перед вызовом инициализации SDL взывать SDL_SetMainReady
Вот пример
https://wiki.libsdl.org/SDL_SetMainReady
----------------------------------------------
Да, ебаная наркомания, тоже ненавижу программистов которые наворачивают какую-то хуиту на ровном месте, там где это нихуя ничего не дает (даже если посмотреть код sdl main - то там нихуя не делается серьзного и важного - именно такого что нужно SDL).
Есть OpenGL 4.3 и код вида:
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, texture_id1);
ну и для каждой следующей просто меняются GL_TEXTUREn,
можно ли с данной версией это сделать через цикл?
Вроде эту команду можно было бы заменить:
glBindTextureUnit(n, texture_id);
Но у меня версия 4.3
glActiveTexture(GL_TEXTURE1);
glBindTexture(GL_TEXTURE_2D, texture_id1);
ну и для каждой следующей просто меняются GL_TEXTUREn,
можно ли с данной версией это сделать через цикл?
Вроде эту команду можно было бы заменить:
glBindTextureUnit(n, texture_id);
Но у меня версия 4.3
>>790851
Потому что очередное поделие кроноса из жопы, мало того что сложно, так блядь оно и работает как говно.
Очень напоминает эпоху OpenGL 2.1 - напоминаю что тогда тоже раскочегарились и давай лепить миллион и одно расширение, которые конечно же работали только на паре видеокарт и через жопу (я даже еще помню как видеокарты покупали как раз проверяя - есть ли там нужные расширения)....
Короче, 99% геймдева поклало болт на OGL и писало игры на DX9-10-11, потому что Microsoft очень жестко ограничивала фантазию вендоров, Direct3D гарантировал что твоя игра будет работать везде где есть винда.
OpenGL вообще нихуя не гарантировал (кстати, попробуй сейчас позапускать демки с 2.1 - вангую что больше половины уже не рабочие... Я тут как раз пишу типа олдскулпроект, много рою старого кода, почти никакие демо не работают как должны были)
Потом пришел OpenGL 3.3 и наконец-то наступила стабильность. Наконец-то не нужно было делать хаки чтобы оно работало на всяких AMD или интел-встройках. В таком же виде оно ушло и на мобилы в виде GLES, где тоже удивительно стабильно.
И вот вулкан - первоначально-то они учитывали этот печальный опыт... А потом снова и опять. К примеру у меня где-то половина демок на вулкане не работает (из крупного например не работает рендер вулкана в bgfx, и разраб до сих пор не смог починить. и не в том плане что какая-то фича - он просто даже не может создать Instance с теми параметрами которые указал разраб bgfx)
Короче, через десять лет будет актуально. Сейчас это только для ААА разработчиков (ну вот как в свое время Кармак писал на старом OGL и у него одного до сих пор все работает в квайках)
>Чому не Vulkan?
Потому что очередное поделие кроноса из жопы, мало того что сложно, так блядь оно и работает как говно.
Очень напоминает эпоху OpenGL 2.1 - напоминаю что тогда тоже раскочегарились и давай лепить миллион и одно расширение, которые конечно же работали только на паре видеокарт и через жопу (я даже еще помню как видеокарты покупали как раз проверяя - есть ли там нужные расширения)....
Короче, 99% геймдева поклало болт на OGL и писало игры на DX9-10-11, потому что Microsoft очень жестко ограничивала фантазию вендоров, Direct3D гарантировал что твоя игра будет работать везде где есть винда.
OpenGL вообще нихуя не гарантировал (кстати, попробуй сейчас позапускать демки с 2.1 - вангую что больше половины уже не рабочие... Я тут как раз пишу типа олдскулпроект, много рою старого кода, почти никакие демо не работают как должны были)
Потом пришел OpenGL 3.3 и наконец-то наступила стабильность. Наконец-то не нужно было делать хаки чтобы оно работало на всяких AMD или интел-встройках. В таком же виде оно ушло и на мобилы в виде GLES, где тоже удивительно стабильно.
И вот вулкан - первоначально-то они учитывали этот печальный опыт... А потом снова и опять. К примеру у меня где-то половина демок на вулкане не работает (из крупного например не работает рендер вулкана в bgfx, и разраб до сих пор не смог починить. и не в том плане что какая-то фича - он просто даже не может создать Instance с теми параметрами которые указал разраб bgfx)
Короче, через десять лет будет актуально. Сейчас это только для ААА разработчиков (ну вот как в свое время Кармак писал на старом OGL и у него одного до сих пор все работает в квайках)
>>798585
Да, именно так и делают (мне кстати интересно что на это пишет стандарт - есть ли гарантия что GL_TEXTURE0 +1 равно GL_TEXTURE1, GL_TEXTURE0 +2 равно GL_TEXTURE2 и т.д.... Но наверное похер, OpenGL менять уже не будут, а так все делают.
>>792104
Создавай debug context (но нужна поддержка 4.1), там можно обрабатывать каждую ошибку. glGetError бесполезная хуита
>>792104
Походу тогда все употребляли одно и тоже. Такой же алгоритм обработки ошибок и в WinAPI к примеру (который со времен доса не меняется), и даже вроде в си-шных либах
Да, именно так и делают (мне кстати интересно что на это пишет стандарт - есть ли гарантия что GL_TEXTURE0 +1 равно GL_TEXTURE1, GL_TEXTURE0 +2 равно GL_TEXTURE2 и т.д.... Но наверное похер, OpenGL менять уже не будут, а так все делают.
>>792104
Создавай debug context (но нужна поддержка 4.1), там можно обрабатывать каждую ошибку. glGetError бесполезная хуита
>>792104
>У меня только один вопрос - что употреблял человек, который это придумал?
Походу тогда все употребляли одно и тоже. Такой же алгоритм обработки ошибок и в WinAPI к примеру (который со времен доса не меняется), и даже вроде в си-шных либах
>>798620
А OpenGL сейчас какой самый актуальный и надёжный, последний или предпоследний, или ES?
А OpenGL сейчас какой самый актуальный и надёжный, последний или предпоследний, или ES?
>>798639
С 1.
0 - это сброс стейта в бинде текстуры (и других ресурсов). Можешь считать ошибкой если вернуло ноль
>>798636
4.6 самый последний, больше не будет
4.2-4.4 возможно можно юзать не боясь что где-то не будет работать
но не выше 4.3 на маках, так как эпл отказалось поддерживать огл дальше
3.3 самый стабильный и простой и точно будет на всех рабочих пк пригодных для игр.
ES - это мобилки, и оно плюс-минус равно 3.3
С 1.
0 - это сброс стейта в бинде текстуры (и других ресурсов). Можешь считать ошибкой если вернуло ноль
>>798636
>самый актуальный
4.6 самый последний, больше не будет
4.2-4.4 возможно можно юзать не боясь что где-то не будет работать
но не выше 4.3 на маках, так как эпл отказалось поддерживать огл дальше
3.3 самый стабильный и простой и точно будет на всех рабочих пк пригодных для игр.
ES - это мобилки, и оно плюс-минус равно 3.3
И мне нужно что бы они работали сo swing.
P.S.- хочу сделать интро для моего проекта...
P.S.- хочу сделать интро для моего проекта...
>>824629
jogl, java3d это что очень древнее, не пробовал ни разую А вот lwjgl3 отличный + в контексте этого проекта развивается еще много крутых либ и оберток от этого же автора. Для джавы тут как бы без вариантов. В свинг не пробовал встраивать, но вроде это не проблема.
jogl, java3d это что очень древнее, не пробовал ни разую А вот lwjgl3 отличный + в контексте этого проекта развивается еще много крутых либ и оберток от этого же автора. Для джавы тут как бы без вариантов. В свинг не пробовал встраивать, но вроде это не проблема.
>>824662
Блин, теперь стоит проблема в выборе между jogl и lwjgl3 ._.
Блин, теперь стоит проблема в выборе между jogl и lwjgl3 ._.
>>824662
JOGL более прост в использовании нежели lwjgl, или мне не удалось найти годные туториалы...
JOGL более прост в использовании нежели lwjgl, или мне не удалось найти годные туториалы...
>>824677
Глянул хелоуворлд, jogl более абстрактная обертка. Сразу и класс шейдера, текстура, вместо glfw окно похожее на свинг, рендер текста из коробки.
lwjgl тут выходит более хардкорным и близким к оригиналу. Из туторов я вот это читал https://lwjglgamedev.gitbooks.io/3d-game-development-with-lwjgl/content/ https://github.com/LWJGL/lwjgl3-wiki/wiki
Глянул хелоуворлд, jogl более абстрактная обертка. Сразу и класс шейдера, текстура, вместо glfw окно похожее на свинг, рендер текста из коробки.
lwjgl тут выходит более хардкорным и близким к оригиналу. Из туторов я вот это читал https://lwjglgamedev.gitbooks.io/3d-game-development-with-lwjgl/content/ https://github.com/LWJGL/lwjgl3-wiki/wiki
174 Кб, 983x344>>824662
А вот здесь сказано что JOGL лучше чем lwjgl !
Ресурс - https://www.tutorialspoint.com/jogl/jogl_overview.htm#
Перевод: Почему именно JOGL?
Он предоставляет полный доступ к API OpenGL (версии 1.0, 4.3, ES 1, ES 2 и ES 3), а также почти ко всем расширениям производителей. Таким образом, все возможности OpenGL включены в JOGL.
JOGL интегрируется с AWT, Swing и Standard Widget Toolkit (SWT). Он также включает свой собственный инструментарий Native Windowing Toolkit (NEWT). Таким образом, он обеспечивает полную поддержку окон.
А вот здесь сказано что JOGL лучше чем lwjgl !
Ресурс - https://www.tutorialspoint.com/jogl/jogl_overview.htm#
Перевод: Почему именно JOGL?
Он предоставляет полный доступ к API OpenGL (версии 1.0, 4.3, ES 1, ES 2 и ES 3), а также почти ко всем расширениям производителей. Таким образом, все возможности OpenGL включены в JOGL.
JOGL интегрируется с AWT, Swing и Standard Widget Toolkit (SWT). Он также включает свой собственный инструментарий Native Windowing Toolkit (NEWT). Таким образом, он обеспечивает полную поддержку окон.
Слушайте а если я хочу чтоб мое приложение запускалось на максимальном количестве устройств, в том числе на всяком старом говне, я должен использовать какую-нибудь лохматую версию opengl? ну типа 2.1 или типа того? или даже на древних устройствах на современных драйверах есть поддержка скажем 3.3?
>>835809
Ориентируйся на возможности WebGL1.0, оно есть почти везде, там специально выбрали самый минимум для широты поддержки железа. Вообще дело не в версии OpenGL, а в возможностях конкретной видюхи, которая может уметь через расширения больше, чем позволяет поддерживаемая версия OpenGL. Часто бывает, наоборот, какие-то возможности драйвер поддерживает, а по факту, например геометрические шейдеры считаются на проце, видюха их не умеет.
Ориентируйся на возможности WebGL1.0, оно есть почти везде, там специально выбрали самый минимум для широты поддержки железа. Вообще дело не в версии OpenGL, а в возможностях конкретной видюхи, которая может уметь через расширения больше, чем позволяет поддерживаемая версия OpenGL. Часто бывает, наоборот, какие-то возможности драйвер поддерживает, а по факту, например геометрические шейдеры считаются на проце, видюха их не умеет.
>>835809
Я не помню деталей, да и не особо я программист, но олдфаги в своё время бугуртили, что раньше всё рисовалсь под старое железо, в котором fixed pipeline, а теперь программируемые шейдерные ядра, ЪУЪ!
https://www.khronos.org/opengl/wiki/Legacy_OpenGL
https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline
Я не помню деталей, да и не особо я программист, но олдфаги в своё время бугуртили, что раньше всё рисовалсь под старое железо, в котором fixed pipeline, а теперь программируемые шейдерные ядра, ЪУЪ!
https://www.khronos.org/opengl/wiki/Legacy_OpenGL
https://www.khronos.org/opengl/wiki/Fixed_Function_Pipeline
>>835809
ну знаешь, 486 процессоры до сих пор работают и наверняка у пары дедов еще работают. А на ламповых компах и опенгл то не было
Ты уж определись какой именно уровень старого хлама тебе нужен.
А если под реальные задачи - то OpenGL 3.3, да. Это уровень DX 10 видеокарт. Либо 4.0 - оно вышло в один год
А вот даунгрейдить под 2.1 или 1.6 и ниже вообще не советую. Так как велик шанс что твое приложение не будет работать на НОВЫХ устройствах.
Драйвера под этот хлам никто не пишет. Да и в большинстве случаев оно сейчас эмулируется, что добавляет еще кучу новых багов к непофикшенным старым.
>на максимальном количестве устройств, в том числе на всяком старом говне
ну знаешь, 486 процессоры до сих пор работают и наверняка у пары дедов еще работают. А на ламповых компах и опенгл то не было
Ты уж определись какой именно уровень старого хлама тебе нужен.
А если под реальные задачи - то OpenGL 3.3, да. Это уровень DX 10 видеокарт. Либо 4.0 - оно вышло в один год
А вот даунгрейдить под 2.1 или 1.6 и ниже вообще не советую. Так как велик шанс что твое приложение не будет работать на НОВЫХ устройствах.
Драйвера под этот хлам никто не пишет. Да и в большинстве случаев оно сейчас эмулируется, что добавляет еще кучу новых багов к непофикшенным старым.
>>835931
заебешься так делать, так как придется делать под все тысячи моделей видеокарт. Конечно же эти тысячи моделей должны лежать на столе физически - прелесть разработки тех времен, что документация не гарантировала работоспособность реальной железки (поэтому в нулевые годы многие игры работали никак). а еще ведь и разные версии драйверов....
Прелесть мажорных версий в том что либо видеокарта полностью поддерживает все функции, либо считается что она не умеет (даже если нет одной функции из пятиста)
> в возможностях конкретной видюхи
заебешься так делать, так как придется делать под все тысячи моделей видеокарт. Конечно же эти тысячи моделей должны лежать на столе физически - прелесть разработки тех времен, что документация не гарантировала работоспособность реальной железки (поэтому в нулевые годы многие игры работали никак). а еще ведь и разные версии драйверов....
Прелесть мажорных версий в том что либо видеокарта полностью поддерживает все функции, либо считается что она не умеет (даже если нет одной функции из пятиста)
>>835967
Кстати на виндовсе в браузерах даже современный WebGL транслируется в Direct3D через прослойку ANGLE, чтобы не полагаться на кривые драйвера OpenGL.
https://en.wikipedia.org/wiki/ANGLE_(software)
>Да и в большинстве случаев оно сейчас эмулируется
Кстати на виндовсе в браузерах даже современный WebGL транслируется в Direct3D через прослойку ANGLE, чтобы не полагаться на кривые драйвера OpenGL.
https://en.wikipedia.org/wiki/ANGLE_(software)
>>835967
Будет без проблем. Тупо потому что этот код в дровах не меняется. Для мобилок больше 2.0 (ES) не нужно. Это уровень DX9, условно второго крузиса. Вряд ли у него будет рендер лучше.
>А вот даунгрейдить под 2.1 или 1.6 и ниже вообще не советую. Так как велик шанс что твое приложение не будет работать на НОВЫХ устройствах.
Будет без проблем. Тупо потому что этот код в дровах не меняется. Для мобилок больше 2.0 (ES) не нужно. Это уровень DX9, условно второго крузиса. Вряд ли у него будет рендер лучше.
Вот я колеблю вершины флага в вершинном шейдере. А чтобы нормали найти, пришлось считать производные по формуле из википедии. Их можно было бы посчитать, имея доступ к соседним вершинам той же грани, но как я понимают это невозможно в glsl? И как быть, если вершины двигать по какой-то аццки сложной формуле, что даже производную не посчитать?
>>836961
Почему не посчитать? Численно всегда можно: считай позицию вершины в p0: f(u,v) и потом еще две позиции p1: f(u+du, v), p2: f(u, v+dv), где du, dv - малые приращения, возьми 0,001, например. Тогда нормаль будет n = normalize( cross( p1 - p0, p2 - p0 ) ).
Не думаю, что формула сложная, там синусы-косинусы с интерполяцией скорее всего, просто ты алгебру забыл.
Это в принципе невозможно на видяхе, треугольники считаются параллельно, и соседние вершины еще могут быть не готовы. Можно считать нормали в пиксельном шейдере, но там сглаживания между треугольниками не будет.
>И как быть, если вершины двигать по какой-то аццки сложной формуле, что даже производную не посчитать?
Почему не посчитать? Численно всегда можно: считай позицию вершины в p0: f(u,v) и потом еще две позиции p1: f(u+du, v), p2: f(u, v+dv), где du, dv - малые приращения, возьми 0,001, например. Тогда нормаль будет n = normalize( cross( p1 - p0, p2 - p0 ) ).
Не думаю, что формула сложная, там синусы-косинусы с интерполяцией скорее всего, просто ты алгебру забыл.
>но как я понимают это невозможно в glsl?
Это в принципе невозможно на видяхе, треугольники считаются параллельно, и соседние вершины еще могут быть не готовы. Можно считать нормали в пиксельном шейдере, но там сглаживания между треугольниками не будет.
2,5 Мб, 3000x4000>>837293
Да, я ступил, не подумал, что для численного рассчёта не обязательно прям реальные соседние вершины брать, а можно любые 2 точки по близости рассчитать
Для флажка то мне моих школьных знаний хватило, но всего два синуса и smoothstep заняли страницу расчетов. Вот я и говорю, что для более сложного случая формулы на много листов расписывать не охота.
Да, я ступил, не подумал, что для численного рассчёта не обязательно прям реальные соседние вершины брать, а можно любые 2 точки по близости рассчитать
>Не думаю, что формула сложная, там синусы-косинусы с интерполяцией скорее всего, просто ты алгебру забыл
Для флажка то мне моих школьных знаний хватило, но всего два синуса и smoothstep заняли страницу расчетов. Вот я и говорю, что для более сложного случая формулы на много листов расписывать не охота.
>>837306
Поставь матлаб какой-нибудь или максиму. Это быстрее, чем считать на листочке.
>Вот я и говорю, что для более сложного случая формулы на много листов расписывать не охота.
Поставь матлаб какой-нибудь или максиму. Это быстрее, чем считать на листочке.
>>837333
В два прохода. Сначала заполняешь позиции в одном буфере, потом читаешь этот буфер, и пишешь в другой нормали.
>А в компьют шейдере можно?
В два прохода. Сначала заполняешь позиции в одном буфере, потом читаешь этот буфер, и пишешь в другой нормали.
202 Кб, 1408x590>>836961
А точно все так сложно должно быть?
Вот например из туториала годота, нормаль считается усредненной суммой векторов в этом случае карты высот, иными словами, зачем тебе производная, когда можно просто взять непосредственно значения f(x-step), f(x), f(x+step)? А то, что она перпендикулярна, считается, кажется, cross - можно посмотреть в шейдерах воды, кстати там наверняка тоже считаются нормали от волны.
А точно все так сложно должно быть?
Вот например из туториала годота, нормаль считается усредненной суммой векторов в этом случае карты высот, иными словами, зачем тебе производная, когда можно просто взять непосредственно значения f(x-step), f(x), f(x+step)? А то, что она перпендикулярна, считается, кажется, cross - можно посмотреть в шейдерах воды, кстати там наверняка тоже считаются нормали от волны.
>>837358
Да, для флага бы подошло. Но в общем тут только для поверхностей описываемых формулой y=f(x,z), то есть как плоская карта высот. А если поверхность изогнется еще и вокруг оси X, например, то надо уже будет по честному векторное произведение считать, я так понимаю.
Да, для флага бы подошло. Но в общем тут только для поверхностей описываемых формулой y=f(x,z), то есть как плоская карта высот. А если поверхность изогнется еще и вокруг оси X, например, то надо уже будет по честному векторное произведение считать, я так понимаю.
>>837426
Идея больше в том, что ты же все равно как то каждую вершину высчитываешь. А значит, можешь повторить вычисления для соседних и использовать для вычисления нормали.
Идея больше в том, что ты же все равно как то каждую вершину высчитываешь. А значит, можешь повторить вычисления для соседних и использовать для вычисления нормали.
>>837434
Основную эту идею я теперь понял.
Основную эту идею я теперь понял.
Привет. Мне для топдауна нужна перспектива, которая была бы преувеличенной относительно высоты. То есть чем выше объект, тем больше его колбасит. Увеличение FOV это не то.
Для вершин это тривиально. Надо в нужный момент увеличить x/y по функции от z. В пример пикрелейтед.
Для простоты берём только x потому что можно не учитывать вертикальный угол камеры. Сейчас я это делаю после перемножения вершины с матрицей вида и перспективы.
Это работает, и даёт нужный мне эффект. вон объёмные кусты на пик2
Но из-за этого текстуры искажаются, если они отрисовываются не в горизонтальной плоскости пик3 в качестве примера как ведёт себя текстура. потом спрайты персонажей будут отрисовываться без перспективы. Я знаю, почему они искажаются affine texture mapping, но как это задёшево исправить в таком контексте?
Извините, если косо изъясняюсь.
Для вершин это тривиально. Надо в нужный момент увеличить x/y по функции от z. В пример пикрелейтед.
Для простоты берём только x потому что можно не учитывать вертикальный угол камеры. Сейчас я это делаю после перемножения вершины с матрицей вида и перспективы.
Это работает, и даёт нужный мне эффект. вон объёмные кусты на пик2
Но из-за этого текстуры искажаются, если они отрисовываются не в горизонтальной плоскости пик3 в качестве примера как ведёт себя текстура. потом спрайты персонажей будут отрисовываться без перспективы. Я знаю, почему они искажаются affine texture mapping, но как это задёшево исправить в таком контексте?
Извините, если косо изъясняюсь.
>>838635
Не знаю какая конкретно у тебя техника. Очевидно что если у тебя получается трапеция вместо квадрата, то всегда будут искажения. То есть тебе стоит держать все спрайты параллельно экрана, хз как ты будешь это считать, например по одной точке (левому верхнему углу) считать остальные точки.
Слышал про технику, не знаю ее точное название, или Sprite stacing, или fake 3d in 2d, или sprite layering. При ней все спрайты всегда параллельны экрану. Но конечно могут быть на разной высоте и двигаться с разной скоростью , давая параллакс.
https://www.youtube.com/watch?v=OYcLS1v5Bx8
Не знаю какая конкретно у тебя техника. Очевидно что если у тебя получается трапеция вместо квадрата, то всегда будут искажения. То есть тебе стоит держать все спрайты параллельно экрана, хз как ты будешь это считать, например по одной точке (левому верхнему углу) считать остальные точки.
Слышал про технику, не знаю ее точное название, или Sprite stacing, или fake 3d in 2d, или sprite layering. При ней все спрайты всегда параллельны экрану. Но конечно могут быть на разной высоте и двигаться с разной скоростью , давая параллакс.
https://www.youtube.com/watch?v=OYcLS1v5Bx8
>>838635
Решение такое: не насиловать мозг и рисовать всё в честном 3D через шейдёр, вместо ручного преобразования координат каждой точки.
Решение такое: не насиловать мозг и рисовать всё в честном 3D через шейдёр, вместо ручного преобразования координат каждой точки.
>>838655
У меня как раз честное обычное триде. Просто с дополнительными трюками а-ля пик2. Вот ещё хочу усиленную перспективу. Она поверх обычного триде идет.
>>838646
Я стакинг как раз на кустах использую. Но мне нужны будут вертикальные стены, и лучше бы их в один заход отрисовывать.
Возможно, на моём скриншоте это было плохо видно, но моя проблема в пике 3б. Пока я использую обычное триде её не возникает (наклон как в зельде тоже проблем не вызывает, он не создаёт трапеции). Начинаю раздвигать ось - появляется эффект пс1. Может это можно как-то во фрагментном шейдере компенсировать?
У меня как раз честное обычное триде. Просто с дополнительными трюками а-ля пик2. Вот ещё хочу усиленную перспективу. Она поверх обычного триде идет.
>>838646
Я стакинг как раз на кустах использую. Но мне нужны будут вертикальные стены, и лучше бы их в один заход отрисовывать.
Возможно, на моём скриншоте это было плохо видно, но моя проблема в пике 3б. Пока я использую обычное триде её не возникает (наклон как в зельде тоже проблем не вызывает, он не создаёт трапеции). Начинаю раздвигать ось - появляется эффект пс1. Может это можно как-то во фрагментном шейдере компенсировать?
>>838635
Если все вершины лежат в одной плоскости, то искажений не должно быть. Очевидно, ты где-то с расчетом z проебался, и вершины уезжают. В вершинном шейдере однородные (проективные) координаты xyzw, а не xyz. У тебя w скорее всего уезжает.
>Я знаю, почему они искажаются affine texture mapping
Если все вершины лежат в одной плоскости, то искажений не должно быть. Очевидно, ты где-то с расчетом z проебался, и вершины уезжают. В вершинном шейдере однородные (проективные) координаты xyzw, а не xyz. У тебя w скорее всего уезжает.
>>838849
Ты это в мировых координатах делаешь или после трансформации в экранные?
>transformed.x *= distortion.
Ты это в мировых координатах делаешь или после трансформации в экранные?
>>838853
Сейчас после трансформации так оно быстрее всего вставляется.
Но если в мировых делать, то то же самое искажение получается, я проверял.
Сейчас после трансформации так оно быстрее всего вставляется.
Но если в мировых делать, то то же самое искажение получается, я проверял.
>>838858
Думаю, можно поиграться с матрицей проекции тогда. Увеличивать FOV одновременно с масштабированием сцены.
Думаю, можно поиграться с матрицей проекции тогда. Увеличивать FOV одновременно с масштабированием сцены.
Я, как мне кажется, решил проблему творчески.
Во-первых, я обнаружил, что мне не хватало объёма, потому что я пока делал зельда-эффект излишне сжимал z. Но это не относится к проблеме.
Вместо того, чтобы раздвигать x, я теперь сжимаю y, а x занимается перспектива. Искажения, если они есть, теперь будут не на стенах, которые стоят лицом к камере, а на боковых стенах, где их никто никогда не заметит. Надо только коэффициент сжатия подобрать, чтобы при перемещении камеры не выглядело странно.
Теперь всё выглядит как мне нужно.
Во-первых, я обнаружил, что мне не хватало объёма, потому что я пока делал зельда-эффект излишне сжимал z. Но это не относится к проблеме.
Вместо того, чтобы раздвигать x, я теперь сжимаю y, а x занимается перспектива. Искажения, если они есть, теперь будут не на стенах, которые стоят лицом к камере, а на боковых стенах, где их никто никогда не заметит. Надо только коэффициент сжатия подобрать, чтобы при перемещении камеры не выглядело странно.
Теперь всё выглядит как мне нужно.
>>678945 (OP)
Поч в glm странно поворот с помощью квартениона выглядит?
в теории p' = q p inverse(q)
в glm p' = q * p
Поч в glm странно поворот с помощью квартениона выглядит?
в теории p' = q p inverse(q)
в glm p' = q * p
Запускаю проект libgdx с помощью gradle, выбрасывает ошибку:
Could not resolve lwjgl-3.3.1-natives-windows-x86.jar (org.lwjgl:lwjgl:3.3.1)
Подскажите как исправить пожалуйста !
Could not resolve lwjgl-3.3.1-natives-windows-x86.jar (org.lwjgl:lwjgl:3.3.1)
Подскажите как исправить пожалуйста !
>>872634
Почитай тут чет пишут
https://github.com/libgdx/libgdx/issues/6878
В крации, если у тебя его нет локально, он должен скачаться из mavenCentral, попробуй убрать mavenLocal временно
Почитай тут чет пишут
https://github.com/libgdx/libgdx/issues/6878
В крации, если у тебя его нет локально, он должен скачаться из mavenCentral, попробуй убрать mavenLocal временно
>>872648
Спасибо за помощь. Там директория пользователя была на русском, а нужно на английском.
Спасибо за помощь. Там директория пользователя была на русском, а нужно на английском.
Почему в ApplicationListener при загрузке и установке изображения, оно отображается вверх ногами ? В ApplicationAdapter всё ок.
Как изменить цвет фона плавно ? Например от 255,255,255 до 0 ?
Пытаюсь с помощью for, но всё зависает... В дочернем потоке когда запускаю, компилятор ругается, что нужно менять интерфейс только в главном.
Пытаюсь с помощью for, но всё зависает... В дочернем потоке когда запускаю, компилятор ругается, что нужно менять интерфейс только в главном.
32 Кб, 704x398>>873624
Вот здесь на 1 секунду зависает приложение, а затем сразу черный цвет устанавливается, без установки белого.
Вот здесь на 1 секунду зависает приложение, а затем сразу черный цвет устанавливается, без установки белого.
>>873680
Значит поток рендера нельзя усыплять.
Я же намекаю - заведи отдельную переменную. В рендере проверяй ее или ставь в цвет, если нужно плавное. В основном потоке (игровом) меняй.
Значит поток рендера нельзя усыплять.
Я же намекаю - заведи отдельную переменную. В рендере проверяй ее или ставь в цвет, если нужно плавное. В основном потоке (игровом) меняй.
>>678945 (OP)
Хочу понизить разрешение рендера, без уменьшения экрана, как это сделать можно? Как в геймдеве делают?
Условно экран 600х600, а рендериться и масштабируется картинка на в разрешении 300х300
В голову только приходит идея рендерить в текстурку и растягивать квадратик с этой текстуркой на весь экран
Хочу понизить разрешение рендера, без уменьшения экрана, как это сделать можно? Как в геймдеве делают?
Условно экран 600х600, а рендериться и масштабируется картинка на в разрешении 300х300
В голову только приходит идея рендерить в текстурку и растягивать квадратик с этой текстуркой на весь экран
>>873716
так и делают ) точней вешают квад с шейдером который правильно самплит текстурку куда ты отрендерил сцену
так и делают ) точней вешают квад с шейдером который правильно самплит текстурку куда ты отрендерил сцену
>>873716
Скорее всего это единственный способ. Другой был бы на стороне создания окна, типа создаешь окно 600х600 но фреймбуффер только 300х300, но я смотрю многие либы так не умеют делать и рендерят только 1:1.
Скорее всего это единственный способ. Другой был бы на стороне создания окна, типа создаешь окно 600х600 но фреймбуффер только 300х300, но я смотрю многие либы так не умеют делать и рендерят только 1:1.
>>873737
Нет, не могу. Ты игру сделал? Саму игру, где спрайт какой-нибудь двигается? Игра не зависает, когда координата меняется каждый кадр? Как ты его двигаешь, так же и цвет фона "двигай".
Нет, не могу. Ты игру сделал? Саму игру, где спрайт какой-нибудь двигается? Игра не зависает, когда координата меняется каждый кадр? Как ты его двигаешь, так же и цвет фона "двигай".
50 Кб, 1302x579>>873740
Дошло ! Только, почему когда значение переменной равно 47, экран уже белый ? Должно ведь 255 быть...
Дошло ! Только, почему когда значение переменной равно 47, экран уже белый ? Должно ведь 255 быть...
>>873752
Ты пишешь число inc, а выставляешь цвет inc * getDeltaTime, в этом может быть дело.
Ты пишешь число inc, а выставляешь цвет inc * getDeltaTime, в этом может быть дело.
>>874102
Вариант А
Вектор гравитации, который повернуть на угол, это если его надо поменять
Вариант Б
Просто вычитание вертикальной координаты у объекта, который движется в горизонтальном направлении
Вариант А
Вектор гравитации, который повернуть на угол, это если его надо поменять
Вариант Б
Просто вычитание вертикальной координаты у объекта, который движется в горизонтальном направлении
Как создать скин для TextField ?
Создаю с помощью skin composer, пытаюсь взять его, а мне бросает эксепшен Error reading file: textfield/text.json
Caused by: com.badlogic.gdx.utils.reflect.ReflectionException: Class not found: atlasData
Создаю с помощью skin composer, пытаюсь взять его, а мне бросает эксепшен Error reading file: textfield/text.json
Caused by: com.badlogic.gdx.utils.reflect.ReflectionException: Class not found: atlasData
>>875075
Получилось, нужно было нажимать кнопку export вместо save в skin composer...
Получилось, нужно было нажимать кнопку export вместо save в skin composer...
дарова, у мя матеша на 9 класса, что после школьной матеши изучать, чтоб тож треуголники да квадраты рисовать, мб книги какие нибудь, есть у кого нибудь гайдик что и куда дальше изучать?
>>875176
Красная книга опенгл
Можешь попробовать посмотреть Udemy Modern OpenGL, но тебе придётся искать 18 урок, так как его нету, там про камеру, вполне исчерпывающе, на англицком
Красная книга опенгл
Можешь попробовать посмотреть Udemy Modern OpenGL, но тебе придётся искать 18 урок, так как его нету, там про камеру, вполне исчерпывающе, на англицком
>>876525
Да.
Да.
Как отрисовывать раз в несколько секунд одну текстуру с помощью SpriteBatch ?
Хочу написать клон нойты на плюсах
какой движок мне выбрать? или придется все пилить с нуля, если с нуля то посоветуйте гайдов
Много раз тыкал OpenGL
но понимания как должна быть устроена вся система нету конечно
какой движок мне выбрать? или придется все пилить с нуля, если с нуля то посоветуйте гайдов
Много раз тыкал OpenGL
но понимания как должна быть устроена вся система нету конечно
Как указать размеры OrthographicCamera так, что-бы на всех андроид аппаратах картинка была одинакового размера ?
>>878085
Проекция не зависит от размера, только от аспекта.
> Как указать размеры OrthographicCamera так, что-бы на всех андроид аппаратах картинка была одинакового размера ?
Проекция не зависит от размера, только от аспекта.
Антоны, нид хелп.
Не понимаю что происходит.
Делаю туторы на лерн опенжл, остановился на трансформациях https://learnopengl.com/Getting-started/Transformations
Сделал эти трансформации, все работает, да только вот текстурные координаты по пизде пошли.
Даже если никаких трансформаций не делаю, т.е. передаю единичную матрицу - все равно хрень получается.
Как только убираю умножение трансформации на вершины (все остальное остается как есть), то картинка снова рисуется как я задумал.
В чем дело? В туторе об этом ничего не говорится, и в коде никаких дополнительных действий нет.
Код шейдеров https://pastebin.com/Qu4x5LaA
Пикчи прикрепил
UPD. Текстуры как будто меняются местами, сейчас проверил, при биндинге текстур поменял их местами - картинка стала "как надо". Почему так нахуй?
Не понимаю что происходит.
Делаю туторы на лерн опенжл, остановился на трансформациях https://learnopengl.com/Getting-started/Transformations
Сделал эти трансформации, все работает, да только вот текстурные координаты по пизде пошли.
Даже если никаких трансформаций не делаю, т.е. передаю единичную матрицу - все равно хрень получается.
Как только убираю умножение трансформации на вершины (все остальное остается как есть), то картинка снова рисуется как я задумал.
В чем дело? В туторе об этом ничего не говорится, и в коде никаких дополнительных действий нет.
Код шейдеров https://pastebin.com/Qu4x5LaA
Пикчи прикрепил
UPD. Текстуры как будто меняются местами, сейчас проверил, при биндинге текстур поменял их местами - картинка стала "как надо". Почему так нахуй?
>>884155
Сделал еще тест.
Если написать в вертексном шейдере так
vec4 t = {0.1f, 0.1f, 0.1f, 0.f};
gl_Position = t + vec4(aPos, 1.0f);
то все заебись рисуется, просто со смещением.
Если же написать так
vec4 t = {0.1f, 0.1f, 0.1f, 0.f};
t = transform;
gl_Position = vec4(aPos, 1.0f);*
(трансформация только к новому вектору применяется, а к позиции нет)
то происходит чепуха то ли с текстурами, то ли с текстурными координатами.
Какого гуя задействование униформы с трансформацией может влиять на текстуры/координаты?
Сделал еще тест.
Если написать в вертексном шейдере так
vec4 t = {0.1f, 0.1f, 0.1f, 0.f};
gl_Position = t + vec4(aPos, 1.0f);
то все заебись рисуется, просто со смещением.
Если же написать так
vec4 t = {0.1f, 0.1f, 0.1f, 0.f};
t = transform;
gl_Position = vec4(aPos, 1.0f);*
(трансформация только к новому вектору применяется, а к позиции нет)
то происходит чепуха то ли с текстурами, то ли с текстурными координатами.
Какого гуя задействование униформы с трансформацией может влиять на текстуры/координаты?
>>884197
То есть, когда в gl_Position ты записываешь aPos без трансформации, изображение становится темным, как на второй картинке, или какая-то другая чепуха?
То есть, когда в gl_Position ты записываешь aPos без трансформации, изображение становится темным, как на второй картинке, или какая-то другая чепуха?
>>884442
Так, только наоборот, без трансформации светлая картинка (как я хочу), с трансформацией становится темная. Картинка со смайликом имеет черный фон, поэтому больше черного блендится в выходной пиксель.
Но на самом деле даже не обязательно в gl_Position использовать трансформацию - если я временный вектор создам и на нем применю трансформацию, а в gl_Position запишу просто aPos, будет внезапно темная картинка.
Или же если в самом шейдере создать матрицу трансформации, и ее умножить на aPos, а униформу нигде не использовать - тогда будет нормальная светлая картинка.
Моих знаний хватает только на то, чтобы предположить, что если в шейдере не используется transform переменная, то она оптимизируется и выкидывается компилятором. Но как само наличие этой переменной может влиять на текстуры - я допереть не могу.
Так, только наоборот, без трансформации светлая картинка (как я хочу), с трансформацией становится темная. Картинка со смайликом имеет черный фон, поэтому больше черного блендится в выходной пиксель.
Но на самом деле даже не обязательно в gl_Position использовать трансформацию - если я временный вектор создам и на нем применю трансформацию, а в gl_Position запишу просто aPos, будет внезапно темная картинка.
Или же если в самом шейдере создать матрицу трансформации, и ее умножить на aPos, а униформу нигде не использовать - тогда будет нормальная светлая картинка.
Моих знаний хватает только на то, чтобы предположить, что если в шейдере не используется transform переменная, то она оптимизируется и выкидывается компилятором. Но как само наличие этой переменной может влиять на текстуры - я допереть не могу.
>>884469
Билять, так и знал, что какая-то дебильная опечатка будет. Все буферы-хуюферы проверил, а шейдерные проги не проверил.
Короче, я униформы текстур задавал для одной проги, а униформу трансформации для другой.
Было типа так
Теперь все норм, всем спасибо.
Но как оно вообще рисовало хоть что-то, я все равно не допираю. Если для шейдера униформа не задана, не должна ли она рисовать пустоту или какой-то рандом? Или оно берет первые попавшиеся данные?
Билять, так и знал, что какая-то дебильная опечатка будет. Все буферы-хуюферы проверил, а шейдерные проги не проверил.
Короче, я униформы текстур задавал для одной проги, а униформу трансформации для другой.
Было типа так
>glUniform1i(glGetUniformLocation(textureShaderProgram.getID(), "ourTexture"), 0);
>glUniform1i(glGetUniformLocation(textureShaderProgram.getID(), "ourTexture2"), 1);
>glUniformMatrix4fv(glGetUniformLocation(transformShaderProgram.getID(), "transform"), 1, GL_FALSE, glm::value_ptr(trans));
Теперь все норм, всем спасибо.
Но как оно вообще рисовало хоть что-то, я все равно не допираю. Если для шейдера униформа не задана, не должна ли она рисовать пустоту или какой-то рандом? Или оно берет первые попавшиеся данные?
>>884478
Да я уже нашел проблему, униформы текстур не были заданы по сути. Только каким-то чудом оно рисовало что-то.
Шейдеры как тут: https://pastebin.com/Qu4x5LaA
Основной говнокод такого рода: https://pastebin.com/bzhNB3ur
Немудрено в нем запутаться. Сейчас рефакторить стал, чтобы более-менее внятный пайплайн получить.
Да я уже нашел проблему, униформы текстур не были заданы по сути. Только каким-то чудом оно рисовало что-то.
Шейдеры как тут: https://pastebin.com/Qu4x5LaA
Основной говнокод такого рода: https://pastebin.com/bzhNB3ur
Немудрено в нем запутаться. Сейчас рефакторить стал, чтобы более-менее внятный пайплайн получить.
>>710982
На самом деле ресурсы проще обернуть в shared_ptr он не будет копировать оригинал а просто увеличит счетчик, а при удалении вызовет деструктор который все почистит
На самом деле ресурсы проще обернуть в shared_ptr он не будет копировать оригинал а просто увеличит счетчик, а при удалении вызовет деструктор который все почистит
1 Мб, 1200x675всем ку!
Хочу сделать как домашний проектик полную копию карты CK3
то есть отрендерить результат как на пике
Как добиться такого же результата?
Примерно понятно как отрисовывать heightmap
Но вот как делать текстуринг? Можно ли его делать процедурно с точно таким же результатом? (чтобы он получился таким же мультяшно няшным)
Как делать проекцию карты? (там не меркатор а что то другое)
Есть шейдер воды, но непонятно как его присобачить к карте
Хочу сделать как домашний проектик полную копию карты CK3
то есть отрендерить результат как на пике
Как добиться такого же результата?
Примерно понятно как отрисовывать heightmap
Но вот как делать текстуринг? Можно ли его делать процедурно с точно таким же результатом? (чтобы он получился таким же мультяшно няшным)
Как делать проекцию карты? (там не меркатор а что то другое)
Есть шейдер воды, но непонятно как его присобачить к карте
>>885215
Ты хочешь свой движочек писать, чтобы изучать опенгл, или тебе просто техники нужны, чтобы раскрашивать 3д?
Так-то с процедурной генерацией можно дохера всего замутить
https://www.youtube.com/watch?v=BFld4EBO2RE
Ты хочешь свой движочек писать, чтобы изучать опенгл, или тебе просто техники нужны, чтобы раскрашивать 3д?
Так-то с процедурной генерацией можно дохера всего замутить
https://www.youtube.com/watch?v=BFld4EBO2RE
>>885225
на данном этапе хочу просто повторить то что вкинул на пике
но может из этого потом и образуется чего нибудь
на данном этапе хочу просто повторить то что вкинул на пике
но может из этого потом и образуется чего нибудь
>>885235
Ну так вопрос на чем ты будешь делать и какие знания у тебя уже есть.
Судя по вопросам о проекции карты и шейдере воды, тебе еще многое предстоит узнать.
Скорее всего без базы по опенглу не обойтись.
Карту тебе так или иначе надо в какую-то текстуру нарисовать и эту текстуру уже отображать как хочешь.
Для воды у тебя будет один меш, его рисуешь одним шейдером, для карты у тебя будет другой меш, ее рисуешь другим шейдером.
Ну так вопрос на чем ты будешь делать и какие знания у тебя уже есть.
Судя по вопросам о проекции карты и шейдере воды, тебе еще многое предстоит узнать.
Скорее всего без базы по опенглу не обойтись.
Карту тебе так или иначе надо в какую-то текстуру нарисовать и эту текстуру уже отображать как хочешь.
Для воды у тебя будет один меш, его рисуешь одним шейдером, для карты у тебя будет другой меш, ее рисуешь другим шейдером.
>>885242
Для правдоподобного текстуринга нужны правдоподобные текстуры.
Свет там по-моему самый обычный, по Фонгу.
В рендеринге нет 100% однозначных решений как сделать заебись, каждый выкручивается как может, отталкиваясь от базовых алгоритмов.
Для правдоподобного текстуринга нужны правдоподобные текстуры.
Свет там по-моему самый обычный, по Фонгу.
В рендеринге нет 100% однозначных решений как сделать заебись, каждый выкручивается как может, отталкиваясь от базовых алгоритмов.
42 Кб, 176x220А в движкосраче треде сказали, что вулкан можно выучить за 2 месяца. Но что-то это напоминает известный мем.
Почитал the book of shaders, поигрался с шейдерами на shadertoy, прикольно, мне понравилось. Решил основательнее сесть за графику; открыл http://www.learnopengl.com/, а там всё на c++. А я не знаю c++. Зато немного знаю c#. Есть вариант делать графику на c#?
>>885277
Смотря что ты понимаешь под изучением. Если ты уже понимаешь что такое программирование и как должен работать рендер - тебе даже учить ничего не нужно, просто гуглишь конкретные функции вулкана, а потом читать статьи про оптимизацию рендер пайплайна.
Смотря что ты понимаешь под изучением. Если ты уже понимаешь что такое программирование и как должен работать рендер - тебе даже учить ничего не нужно, просто гуглишь конкретные функции вулкана, а потом читать статьи про оптимизацию рендер пайплайна.
>>886201
Пиши на си, там учить ничего не нужно и никаких классов нет. Из с++ просто копируешь все функции и делаешь свои структуры.
Пиши на си, там учить ничего не нужно и никаких классов нет. Из с++ просто копируешь все функции и делаешь свои структуры.
>>886201
Качай юнити
Есть добротный сайт с разными туторами https://catlikecoding.com/unity/tutorials/
Качай юнити
Есть добротный сайт с разными туторами https://catlikecoding.com/unity/tutorials/
1,4 Мб, 1400x800Здравствуйте, Аноны.
Как сделать так, чтобы объекты "смотрели" на определённую точку?
Это как, например, спрайты в DooM, но должно работать с объёмными мешами.
Как сделать так, чтобы объекты "смотрели" на определённую точку?
Это как, например, спрайты в DooM, но должно работать с объёмными мешами.
>>887315
*знаю
*знаю
542 Кб, 961x517Здрасьте, Мужчины.
Есть ли смысл в создании мешей методом тесселяции из текстур, хранящих вершины (то есть, например, берётся куб, и он превращается, условно, в машину) ?
Или лучше использовать другие методы создания уровней детализации?
Как я понял, это хорошо работает с ландшафтом, но можно ли такой метод использовать повсеместно?
https://www.rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/
Есть ли смысл в создании мешей методом тесселяции из текстур, хранящих вершины (то есть, например, берётся куб, и он превращается, условно, в машину) ?
Или лучше использовать другие методы создания уровней детализации?
Как я понял, это хорошо работает с ландшафтом, но можно ли такой метод использовать повсеместно?
https://www.rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/
>>887315
Ты туп? От же по русски скпзал
Очевидно это что это сорт оф оси 3х мернвх коордига х у з.
Ты туп? От же по русски скпзал
> строишь тройку ...
Очевидно это что это сорт оф оси 3х мернвх коордига х у з.
bump
>>889727
Только если ты Майкрософт с миллионом докторов наук в штате, которые напишут рабочий алгоритм. Построить хайполи из лоуполи и текстуры бампа без артефактов для нетривиальной геометрии - очень нетривиальная задача. Тема для диссертации.
>Есть ли смысл в создании мешей методом тесселяции из текстур, хранящих вершины
Только если ты Майкрософт с миллионом докторов наук в штате, которые напишут рабочий алгоритм. Построить хайполи из лоуполи и текстуры бампа без артефактов для нетривиальной геометрии - очень нетривиальная задача. Тема для диссертации.
>>894199
ясно.
ясно.
503 Кб, 640x640Стоит ли избегать лишних вызовов смены шейдерных программ, или это не так уж и критично?
То есть: надо ли сортировать отрисовку мешей по шейдеру? И если надо, то как естесно я использую ECS ?
То есть: надо ли сортировать отрисовку мешей по шейдеру? И если надо, то как естесно я использую ECS ?
>>895641
Конечно. У них же разные атрибуты, разные буфферы и данные.
Смотря что за ecs у тебя и как происходит рендер. Просто делаешь разные рендер-компоненты под каждый шейдер, хуле тут особо думать. Системы сначала разобрались с одними компонентами и отправили на видяху одни данные в шейдер, потом проходят другие системы от другого шейдера.
>То есть: надо ли сортировать отрисовку мешей по шейдеру?
Конечно. У них же разные атрибуты, разные буфферы и данные.
>И если надо, то как естесно я использую ECS ?
Смотря что за ecs у тебя и как происходит рендер. Просто делаешь разные рендер-компоненты под каждый шейдер, хуле тут особо думать. Системы сначала разобрались с одними компонентами и отправили на видяху одни данные в шейдер, потом проходят другие системы от другого шейдера.
Цвета шахматки генерятся в шейдере. Есть ли какой-нибудь способ убрать этот ебучий шум и сделать заебись как при текстурной анизотропии?
131 Кб, 1562x167>>896086
Чего бухтеть-то? Надо реализовать эту фильтрацию в шейдере, взяв ваш текущий выходной цвет фрагмента в качестве входных данных функции фильтрации.
Чекни эту ссылку:
https://habr.com/ru/articles/331618/
Это я про обработку полигонов.
Если у тебя рендеринг излучением (ray marching, ray tracing, ray casting), то решение твоей проблемы можно запросто найти в ру ютубе: https://youtu.be/H-RCv-bbfa8?si=XjpIs6s8tmmOywOH
>Есть ли какой-нибудь способ
Чего бухтеть-то? Надо реализовать эту фильтрацию в шейдере, взяв ваш текущий выходной цвет фрагмента в качестве входных данных функции фильтрации.
Чекни эту ссылку:
https://habr.com/ru/articles/331618/
Это я про обработку полигонов.
Если у тебя рендеринг излучением (ray marching, ray tracing, ray casting), то решение твоей проблемы можно запросто найти в ру ютубе: https://youtu.be/H-RCv-bbfa8?si=XjpIs6s8tmmOywOH
984 Кб, 2019x1118>>896100
Там такая же залупа с искажениями. Нужна функция от dot(view, norm), с сглаживанием для углов близких к 90. Только хуй его знает что сглаживать.
Там такая же залупа с искажениями. Нужна функция от dot(view, norm), с сглаживанием для углов близких к 90. Только хуй его знает что сглаживать.
126 Кб, 1080x922>>896115
Ну тогда мужайся самостоятельно, чел. Я так-то сам не гуру графического программирования.
Если у тебя неполигональная графика, то полазь на https://www.shadertoy.com/ и поищи там шейдеры по запросам"ray marching" и "ray tracing". Также про эти темы есть много как обычной инфы, так и уроков в виде статей и ютуба.
Иначе просто реализуй анизотроп. фильтрацию в шейдере или включи это какой-то командой OGL/Vulkan (в ogl оно вроде расширением включается, а в vk наверно есть изначально), и почитай спойлер ниже.
Попробуй шахматное поле сохранить в текстуре, к которой потом применишь анизотропную фильтрацию.
>dot(view, norm), с сглаживанием для углов близких к 90
Скалярное произведение единичных векторов равно косинусу. Косинус углов, близких к 90, приближается к нулю. Может ли точность этого произведения так заметно влиять на качество?
А лучше прислушиваться ко мне в последнюю очередь.
Ну тогда мужайся самостоятельно, чел. Я так-то сам не гуру графического программирования.
Если у тебя неполигональная графика, то полазь на https://www.shadertoy.com/ и поищи там шейдеры по запросам"ray marching" и "ray tracing". Также про эти темы есть много как обычной инфы, так и уроков в виде статей и ютуба.
Иначе просто реализуй анизотроп. фильтрацию в шейдере или включи это какой-то командой OGL/Vulkan (в ogl оно вроде расширением включается, а в vk наверно есть изначально), и почитай спойлер ниже.
Попробуй шахматное поле сохранить в текстуре, к которой потом применишь анизотропную фильтрацию.
>dot(view, norm), с сглаживанием для углов близких к 90
Скалярное произведение единичных векторов равно косинусу. Косинус углов, близких к 90, приближается к нулю. Может ли точность этого произведения так заметно влиять на качество?
А лучше прислушиваться ко мне в последнюю очередь.
>>896115
Так там нихуя не делали сглаживание. Там только уход в горизонт сделали. Если внимательно присмотришься на 1080р, там зазубрины повсюду.
Единственный варик избавляться от сортов алиасинга - это сорта анти-алиасинга.
Такшо, по сути цвета и надо сглаживать. В простейшем виде просто блюр делать, блюр съедает детали, поэтому лишнего говняка не появляется.
Так там нихуя не делали сглаживание. Там только уход в горизонт сделали. Если внимательно присмотришься на 1080р, там зазубрины повсюду.
Единственный варик избавляться от сортов алиасинга - это сорта анти-алиасинга.
Такшо, по сути цвета и надо сглаживать. В простейшем виде просто блюр делать, блюр съедает детали, поэтому лишнего говняка не появляется.
104 Кб, 637x637>>896086
Туман или подобное
Туман или подобное
ХОЧУ СТАТЬ УВАЖАЕМЫМ ЧЕЛОВЕКОМ В МИРЕ КОМПЬЮТЕРНОЙ ГРАФИКИ
Знаю как вычислить определитель, что такое линейная зависимость и базис.
Какие умные книжки читать?
Перенес из /math/, там мне ответили дефолтное «не математика»
Знаю как вычислить определитель, что такое линейная зависимость и базис.
Какие умные книжки читать?
Перенес из /math/, там мне ответили дефолтное «не математика»
>>896890
К чему готов? Если я в резюме напишу, что знаю синусы, косинусы и кватернионы, на работу возьмут движкописей?
К чему готов? Если я в резюме напишу, что знаю синусы, косинусы и кватернионы, на работу возьмут движкописей?
>>896899
А ты что, решил в резуме расписывать все свои математические знания?
Ну или кто то на собесе жеско линал спрашивает?
А ты что, решил в резуме расписывать все свои математические знания?
Ну или кто то на собесе жеско линал спрашивает?
648 Кб, 720x720>>896908
Алгоритмы, навыки управления ГП и ЦП, умения использовать математику, компуктер сайнс, обычные вопросы по программированию.
Алгоритмы, навыки управления ГП и ЦП, умения использовать математику, компуктер сайнс, обычные вопросы по программированию.
>>896956
Только прочитав точно не устроишься
А вот если еще что то путное напишешь, хотя бы простой рендер движок, то уже хоть куда то
Только прочитав точно не устроишься
А вот если еще что то путное напишешь, хотя бы простой рендер движок, то уже хоть куда то
>>896973
Простой рендер движок - это куб вращающийся? Или какой минимальный функционал у него должен быть?
Простой рендер движок - это куб вращающийся? Или какой минимальный функционал у него должен быть?
>>896995
Чем больше - тем лучше.
Ты же понимаешь, что потенциально конкурировать будешь с задротами, которые уже в 3 года написали реалтаймовый рейтрейсер с нуля?
Представь приходишь ты к челам, говоришь "я могу накодить графику", тебе говорят "покажи". И показываешь два треугольника. Принял бы ты сам себя на работу на их месте? Офк, прежде всего это от запросов компании зависит.
Если ты на нуба графики идешь, скорее от тебя будут ждать, что ты расскажешь как весь этот рендер работает, ну и желательно подкрепишь на деле свои слова. Если на кого-то постарше, то скорее спросят за реализованные проекты и что ты в них делал.
На хабре было пару статеек про собесы на графиста, там вопросики есть.
мимо
Чем больше - тем лучше.
Ты же понимаешь, что потенциально конкурировать будешь с задротами, которые уже в 3 года написали реалтаймовый рейтрейсер с нуля?
Представь приходишь ты к челам, говоришь "я могу накодить графику", тебе говорят "покажи". И показываешь два треугольника. Принял бы ты сам себя на работу на их месте? Офк, прежде всего это от запросов компании зависит.
Если ты на нуба графики идешь, скорее от тебя будут ждать, что ты расскажешь как весь этот рендер работает, ну и желательно подкрепишь на деле свои слова. Если на кого-то постарше, то скорее спросят за реализованные проекты и что ты в них делал.
На хабре было пару статеек про собесы на графиста, там вопросики есть.
мимо
Подскажите какой сейчас самый модный алгоритм для сглаживания шедоумапов? Знаю pcf и variance, но это было уже лет 10 назад. Что сейчас юзают в попсовых движках типа анрила?
123 Кб, 1026x587>>897264
Первое, что нашёл:
https://developer.nvidia.com/gpugems/gpugems/part-ii-lighting-and-shadows/chapter-11-shadow-map-antialiasing
https://www.comp.nus.edu.sg/~tants/tsm/tsm.pdf
https://docs.unrealengine.com/5.0/en-US/virtual-shadow-maps-in-unreal-engine/
В пятом анриле, как я только что узнал, для карт теней используется виртуальная текстура (в движках Джона Кармака чуть расширенная версия этого звалась мегатекстурой) теней.
https://ru.wikipedia.org/wiki/Clipmapping
https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B3%D0%B0%D1%82%D0%B5%D0%BA%D1%81%D1%82%D1%83%D1%80%D0%B0
Первое, что нашёл:
https://developer.nvidia.com/gpugems/gpugems/part-ii-lighting-and-shadows/chapter-11-shadow-map-antialiasing
https://www.comp.nus.edu.sg/~tants/tsm/tsm.pdf
https://docs.unrealengine.com/5.0/en-US/virtual-shadow-maps-in-unreal-engine/
В пятом анриле, как я только что узнал, для карт теней используется виртуальная текстура (в движках Джона Кармака чуть расширенная версия этого звалась мегатекстурой) теней.
https://ru.wikipedia.org/wiki/Clipmapping
https://ru.wikipedia.org/wiki/%D0%9C%D0%B5%D0%B3%D0%B0%D1%82%D0%B5%D0%BA%D1%81%D1%82%D1%83%D1%80%D0%B0
937 Кб, 2545x1378>>897349
Это хуйня придумана укропами нужна для оптимизации. Закулить непопадающие в фрустум камеры тайлы у спарсед шадоумапы. Я спрашивал про сглаживание. В принципе vsm все еще топчик по качество\перф.
Это хуйня придумана укропами нужна для оптимизации. Закулить непопадающие в фрустум камеры тайлы у спарсед шадоумапы. Я спрашивал про сглаживание. В принципе vsm все еще топчик по качество\перф.
>>902680
Что за тулза такая на скрине?
Что за тулза такая на скрине?
Перевод на ravesli.com уроков с learnopengl нормального качества, проверял кто? Вроде даже все уроки переведены, кроме самых новых
>>907673
Хз, посмотри пару уроков и оцени. Если там будет какая-нибудь хуйня вроде точечных продуктов dot product, то дроп сразу.
Вообще на хабре был перевод, возможно там под присмотром народа лучше отредачено.
А так, я бы советовал сразу к англюсику привыкать, ибо половина терминов все равно заморские и не переводятся нормально.
Хз, посмотри пару уроков и оцени. Если там будет какая-нибудь хуйня вроде точечных продуктов dot product, то дроп сразу.
Вообще на хабре был перевод, возможно там под присмотром народа лучше отредачено.
А так, я бы советовал сразу к англюсику привыкать, ибо половина терминов все равно заморские и не переводятся нормально.
Вызываю перерисовку в новый тред
>>907734 (OP)
>>907734 (OP)
>>907734 (OP)
https://2ch.hk/gd/res/907734.html (
М)
>>907734 (OP)
>>907734 (OP)
>>907734 (OP)
https://2ch.hk/gd/res/907734.html (
М)