- innuendo
- Постоялец
MrShoor
оке, отпишись на чьей видюшке.
SDC
> оке, отпишись на чьей видюшке.
Это будет NVidia GTX 980
viennahd
> Даже фильмо-мейкеры делают фильмы не на трассировке, а на вполне штатной
> растеризации.
А зачем им ждать физически более правильный рэй-трэйс-рендер когда можно получить почти такую же картинку(хоть и фейковую) но значительно быстрее, дешевле, энергоэффективнее?
И вообще - трассировка лучей это (по крайней мере в моем случае) растеризация наоборот. Работает на дискретном уровне. Его нужно так или иначе преобразовать в аналоговый, и с этим могут быть проблемы. Тот же например 4K.
Для реальной (настоящей) растеризации на деле не так много проблем с 4K и т.д. Настоящая боль - количество полигонов и текстуры.
Так мне сказала разум GLaDOS.
snake32
> получить почти такую же картинку(хоть и фейковую) но значительно быстрее,
> дешевле, энергоэффективнее?
Ну это пока. Проэцирование не то чтобы очень эффективное, просто аппаратную архитектуру раскочегарили именно на проецирование, потому что когдаато оно было эффективнее. Если сэмулировать грфический конвеер на том же OpenCL то производительность я думаю будет печальная.
А в сторону рейтрейсинга пока еще сильно не копали, но я думаю начнут (сейчас вон уже тени начали рейтресить, дальше еще что-ниб прдумают). И вот тогда он выстрелит во второй раз.
MrShoor
> Чтобы не гадать, что же пошло не так?
Я имел кучу ситуации, когда что-то пошло не так, а DX Debug молчит как партизан
> > Чтобы школьники-студенты зашипили свои крайзисы ?
> Почему бы и да.
А GL не для школьников-студентов, которые не могут прочитать доки
innuendo
> Я имел кучу ситуации, когда что-то пошло не так, а DX Debug молчит как партизан
В OpenGL это поведение по дефолту. :)
MrShoor
> В OpenGL это поведение по дефолту.
Зато появилось целое поколение, которое без DXDebug не может разобраться в СВОЁМ коде :)
MrShoor
> В OpenGL это поведение по дефолту. :)
> Я имел кучу ситуации, когда что-то пошло не так, а DX Debug молчит как партизан
Тут нужно понимать что при разработки в области 3D графики есть ошибки двух типов: Грубые ошибки и есть ошибки логические. Первые могут приводят к крашам, зависаниям и неверному отображению данных. На первый тип реагирует DXDebug. На вторые он не обязан реагировать, если это так, то ошибка комплексная и является так-же первым типом. OpenGL по умолчанию не реагирует не на 1 тип. Появилось целое поколение демкописателей/фанатов OpenGL работающих на готовых движках и даже там не могут разобраться в коде и возможно поимели ошибку СТРОГО второго типа и думаю почему-же DXDebug молчит, значит он ни чем не лучше OpenGL.
Andrey
> . Появилось целое поколение демкописателей/фанатов OpenGL работающих на готовых
> движках и даже там не могут разобраться в коде и
Мне публично рассказать как кто-то по каждому чиху смотрел в DXDebug ?
> Грубые ошибки
Да, есть грубая ошибка - нужно СНАЧАЛА прочитать как работает HOQ, а потом уже писать код :)
> Появилось целое поколение демкописателей/фанатов OpenGL работающих
Появилось целое поколение, которое сначала оптимизирует, а потом уже разбирается, правильно ли написан код...
Andrey
> фанатов OpenGL
Ты зачем пишешь на GL под *nix/mac/ мобилках, скрытый фанат ? :)
Andrey
> и думаю почему-же DXDebug молчит, значит он ни чем не лучше OpenGL.
Публично напомнить про DoF шейдер ?
Andrey
> Первые могут приводят к крашам, зависаниям и неверному отображению данных. На
> первый тип реагирует DXDebug.
Да что ты говоришь... Была тема с крашем, когда забыли отключить HS/DS шейдер. А что ты понимаешь под не верным отображением ?
SDC
твой VK = ~455 FPS
мой OGL = ~455 FPS
мой DX11 = ~500 FPS
Andrey
> Тут нужно понимать что при разработки в области 3D графики есть ошибки двух
> типов: Грубые ошибки и есть ошибки логические. Первые могут приводят к крашам,
> зависаниям и неверному отображению данных. На первый тип реагирует DXDebug
Три примера из твоей практики в студию или тро-ло-ло и бла-бла-бла ?
Тема в архиве.