99 ответов в теме

[Garret]

Просто OpenGL - это стандарт. OpenGL есть везде, он везде одинаковый и всегда работает.

Чушь. Расширения OpenGL, без использования которых серьезный проект не обходится - не переносимы относительно аппаратуры (nVidia/ATI). Причем расширения EXT, а не вендоров определенных даже. Например, glClampColorEXT, который отключает клэмпинг цветов (что ОЧЕНЬ нужно именно в СЕРЬЕЗНОЙ визуализации) не работает под ATI. И методов решения этой проблемы под ATI, скорее всего, нету.
В плане железа DirectX - это переносимый стандарт, а расширения OpenGL - полная жесть. OpenGL без расширений - не жилец.

И через 5 и через 10 лет ты программу с OpenGL собрать сможешь. OpenGL - для серьезной научной визуализации. DX - для игр.

AFAIK, 3я версия OpenGL несовместима со 2ой.

Работает только под виндами, новые версии только под новыми виндами но новом железе, разные версии между собой не совместимы, старые версии никто не поддерживает.

10 и 11 DX совместимы.

Таким образом DX для серьезной визуализации не пригоден. На мой взгляд системные требования начинающиеся с "Windows" - тупизм т.к. сейчас написать программу, которая будет работать везде лишь чуть-чуть сложнее, чем программу, которая работает только на компьютере у разработчика, проверено. Это не относится к очень старым программам, завызанням на старые технологии.

Оч спорно. DirectX основан на объектно-ориентированной структуре и контекстах. OpenGL - на абсолютно небезопасных целочисленных дескрипторах, которые можно передавать куда угодно и кому угодно.
Средства отладки в DX мощнее не в пример.
Опять же, ошибки работы расширений OpenGL, без которых никуда, - нативными средствами OpenGL не ловятся НИКАК.
Так что наоборот - OpenGL - это когда нужно кубик на экране нарисовать. А когда нужен мощный движок с HDR-пайплайном, с Image-Space эффектами и прочим - только DX.

[KiberGus]

Чушь. Расширения OpenGL, без использования которых серьезный проект не обходится - не переносимы относительно аппаратуры (nVidia/ATI). Причем расширения EXT, а не вендоров определенных даже. Например, glClampColorEXT, который отключает клэмпинг цветов (что ОЧЕНЬ нужно именно в СЕРЬЕЗНОЙ визуализации) не работает под ATI. И методов решения этой проблемы под ATI, скорее всего, нету.
В плане железа DirectX - это переносимый стандарт, а расширения OpenGL - полная жесть. OpenGL без расширений - не жилец.

На том уровне, на котором графика нужна лицеистам им особо расширения не нужны. Я согласен, что для красивой графики dx лучше, впрочем dx приложения, отрендереннные через OpenGL смотрятся весьма неплохо. Кстаи, блики и hdr можно реализовать и в рамках стандарта. Через зад, но можно.
P.S. Ты аккуратнее слова употребляй, а то я пока гуглил много интересного нашел, теперь спам мне не страшен.

DirectX не обладает переносимостью по железу. DX работает только под ОС windows, а windows абсолютно непереносимая по железу система. Более того, x86 архитектура на сегодняшний день даже не является наиболее популярной. Так что если ты готов купить железо, дорогое новое железо, совершенно конкретных производителей, и софт, дорогой новый софт от MS, для того, чтобы запускать программы под DX - да все здорово. Если не готов - не будет работать вообще. В случае OpenGL - пока ты в рамках стандарта - оно будет работать везде. Будет работаь не так хорошо, но некий минимум (причем не такой уж и маленький) тебе гарантируется.

На самом деле ты просто неправильно меня понял. Под серьезными графическими приложениями я имел в виду science visualization, а не красивые реалистичные картинки. А в области научной визуализации в OGL намного лучше, чем DX.

[Meshok]

В лицейских работах, на мой взгляд, лучше полностью инкапсулировать визуализацию в отдельный класс, который принимает нужные для визуализации переменные, и сам делает всю работу. Это сильно повышает читабельность (потому что иначе зачастую получается код расчётов вперемешку с визуализацией) и даёт возможность быстро портировать диплом на другой GAPI или полностью поменять стиль визуализации.

Под Windows (а может и под Linux тоже) использование OpenGL с ATI опасно для нервов. Говорят, раз в пару выпусков драйверов добавляются новые баги и исправляется часть старых, для которых ты уже написал код, обходящий их. Вот тут есть про это подробней: http://www.gamedev.r...id=85723&page=3 , http://www.gamedev.r...forum/?id=74984. Например: "в некоторых случаях безобидная работа glClear(GL_COLOR_BUFFER_BIT) при активном FBO может убить FPS к нулю". FBO может использоваться в научных приложениях для сохранения визуализации в файл.

Изменено: Meshok, 07 Ноябрь 2008 - 21:37

[Денис]

А вот еще последний-сто-первый про статистику с трансляций :-) Сегодня зашел в Google Analytics и заметил, что есть же еще и статистика просмотров страниц 104/105 аудиторий. Так вот оно: 449/306, 104я оказалась более просматриваемой :-)

[Mozay]

Ну есть одна маленькая тонкость, C# плохо работает с OpenGL. Народ жалуется, что куча проблем при подключении. А с DX он из коробки дружит. Просто OpenGL - это стандарт. OpenGL есть везде, он везде одинаковый и всегда работает. И через 5 и через 10 лет ты программу с OpenGL собрать сможешь. OpenGL - для серьезной научной визуализации. DX - для игр. Работает только под виндами, новые версии только под новыми виндами но новом железе, разные версии между собой не совместимы, старые версии никто не поддерживает. Таким образом DX для серьезной визуализации не пригоден. На мой взгляд системные требования начинающиеся с "Windows" - тупизм т.к. сейчас написать программу, которая будет работать везде лишь чуть-чуть сложнее, чем программу, которая работает только на компьютере у разработчика, проверено. Это не относится к очень старым программам, завызанням на старые технологии.

На самом же деле все иначе . Что для игр, что для научной визуализации, если же они действительно серьезные, пишется графический движок. Это в свою очередь позволяет использовать программу как вместе с OpenGL, так и с DirectX, причем OpenGL делает программу кроссплатформенной, создание своего графического движка на основе существующих открытых билблиотек позволяет облечить процесс объединения модулей программы, например, физики и визуализации в нашем случае, существует огромное количество таких бесплатных движков, как для DotNET так и для MFC, проблема заключается только в том, что для некоторых из них нет подробной документации, поэтому я выбрал DirectX. Что же до OpenGL - это штука исключительно проста и приятна в использовании только на MFC(С++) и Delphi (не наши случаи)... Не существует конкретных способов подключения OpenGL к DotNET (C# и другие), я не отрицаю, что этих способов нет, есть небольшое количество библиотек, принцип работы которых заключается в DLLIMPORTе... Т.е. хочу этим сказать, что подключить OpenGL к С# не сложно, но просто не нужно только потому, что полное удобство и функционал этой библиотеки мы не получим, как ни крути.

[Garret]

На том уровне, на котором графика нужна лицеистам им особо расширения не нужны.

ну не знаю... неужто никто даже в текстуру не рендерит?

Я согласен, что для красивой графики dx лучше, впрочем dx приложения, отрендереннные через OpenGL смотрятся весьма неплохо.

Качество рендеринга и там и там одинаковое, это ж апи, а не движок, ясен байт.

Кстаи, блики и hdr можно реализовать и в рамках стандарта. Через зад, но можно.

Скорость? Точность?

DirectX не обладает переносимостью по железу. DX работает только под ОС windows, а windows абсолютно непереносимая по железу система. Более того, x86 архитектура на сегодняшний день даже не является наиболее популярной. Так что если ты готов купить железо, дорогое новое железо, совершенно конкретных производителей, и софт, дорогой новый софт от MS, для того, чтобы запускать программы под DX - да все здорово. Если не готов - не будет работать вообще. В случае OpenGL - пока ты в рамках стандарта - оно будет работать везде. Будет работаь не так хорошо, но некий минимум (причем не такой уж и маленький) тебе гарантируется.

Если указано - наша железяка саппортит DirectX XX.YY - значит, она его саппортит. Если написано - наша железяка саппортит OpenGL X.Y - то я еще должен поинтересоваться, какие именно расширения она у него саппортит.
Про конкретных производителей не надо байки. DX10 поддерживают все современные вендоры: ATI, nVidia, S3. У которых лоу-кост продуктов - как грязи.
От стандарта OpenGL меня, честно говоря, воротит. Там чайник текстурированный нарисовать - верх совершенства. Шаг влево, шаг вправо - уже расширение.

На самом деле ты просто неправильно меня понял. Под серьезными графическими приложениями я имел в виду science visualization, а не красивые реалистичные картинки. А в области научной визуализации в OGL намного лучше, чем DX.

Чем лучше-то? Только тем, что можно под любимыми линухами писать?

[Garret]

Не существует конкретных способов подключения OpenGL к DotNET (C# и другие), я не отрицаю, что этих способов нет, есть небольшое количество библиотек, принцип работы которых заключается в DLLIMPORTе... Т.е. хочу этим сказать, что подключить OpenGL к С# не сложно, но просто не нужно только потому, что полное удобство и функционал этой библиотеки мы не получим, как ни крути.

В любой графике на C# смысла нет. Что C#, что Java - слишком медленные для графики (все эти замечательные boxing-unboxing). В крайнем случае, графическое ядро отдельно на ++ пишется, и уже само по себе подключается к основному движку.

[KiberGus]

ну не знаю... неужто никто даже в текстуру не рендерит?

В этом году никто.

Скорость? Точность?

Не пробовал.

Если указано - наша железяка саппортит DirectX XX.YY - значит, она его саппортит. Если написано - наша железяка саппортит OpenGL X.Y - то я еще должен поинтересоваться, какие именно расширения она у него саппортит.
Про конкретных производителей не надо байки. DX10 поддерживают все современные вендоры: ATI, nVidia, S3. У которых лоу-кост продуктов - как грязи.
От стандарта OpenGL меня, честно говоря, воротит. Там чайник текстурированный нарисовать - верх совершенства. Шаг влево, шаг вправо - уже расширение.

Хм, а на power, arm архитектурах оно тоже его поддерживает? А 64битные архитектуры поддерживаются? Насколько я знаю, windows до сих пор 32битная, ну не будет никогда у microsoft честной 64битной ОС. Пользователь туп и не знает скольки битный у него процессор, поэтому весь софт должен быть 32битным. Аналогично, зачем выкладывать драйвера под 32бита и под 64 бита. Пользователь путаться будет, давайте вылодим 32битную версию. А нормальную систему установки, как в unix системах, microsoft не осилит.

Чем лучше-то? Только тем, что можно под любимыми линухами писать?

На мой взгляд, закрытые технологии ущербны по определению. Зачем мне DX, если я не могу взять и запустить приложение, которое его использует? Почему DX приложения запускаются только под платной и неудобной средой? Для меня удобство работы с ОС в целом выше удобства работы с 3D подсистемой.

[Garret]

Хм, а на power, arm архитектурах оно тоже его поддерживает? А 64битные архитектуры поддерживаются? Насколько я знаю, windows до сих пор 32битная, ну не будет никогда у microsoft честной 64битной ОС. Пользователь туп и не знает скольки битный у него процессор, поэтому весь софт должен быть 32битным. Аналогично, зачем выкладывать драйвера под 32бита и под 64 бита. Пользователь путаться будет, давайте вылодим 32битную версию. А нормальную систему установки, как в unix системах, microsoft не осилит.

Ты гонишь. Что XP, что Vista 64-битные сто лет как есть.

[KiberGus]

Ты гонишь. Что XP, что Vista 64-битные сто лет как есть.

Винды есть, приложений под них нет. И с драйверами проблема.
P.S. Помимо линукса еще есть MacOS и еще есть PlayStation3. Под первой DX нет т.к. не MS, а вторая как раз представитель семейстав power, где винды даже работать не умеют. Графика и там и там только OGL.

[Meshok]

В любой графике на C# смысла нет. Что C#, что Java - слишком медленные для графики (все эти замечательные boxing-unboxing). В крайнем случае, графическое ядро отдельно на ++ пишется, и уже само по себе подключается к основному движку.

Странно, я всегда думал, что управляемые языки не подходят для графических движков из-за непредсказуемого garbage collection (игра будет иногда приостанавливаться на полсекунды для сбора мусора). Зачем в C# и Java с поддержкой generics делать boxing-unboxing?

[Garret]

P.S. Помимо линукса еще есть MacOS и еще есть PlayStation3. Под первой DX нет т.к. не MS, а вторая как раз представитель семейстав power, где винды даже работать не умеют. Графика и там и там только OGL.

И чего? А есть еще денди, нинтендо и сега сатурн.
PS - гораздо менее популярна X-BOX, особенно в нашей стране.
Мы сейчас с вопроса удобности API съехали на вопрос "какая ось лучше")))

[koraalex]

Буду отвечать на один пункт за раз, а то мысли разбегутся. 2.3 Внимательно пересмотрел запись. Картина там действительно изменилась, причём так же, как на скриншоте. Действительно изменилась немножко и очень неудачно, я даже разглядел порядки величин - предположение о слишком малой заданной циркуляции верно. Но самое главное - на скриншоте разбиваемая телом линия тока идёт чётко прямо, а не прогибается, как ты, Дима, утверждал. Не тот скриншот?

[Deimos]

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

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

Ох... Там дело в том, что мы всё-таки смотрим на поле скоростей, а не на линию тока... У меня сейчас под рукой дипломной работы своей нет, но, как-только она мне попадётся, сделаю расстояния в этой сетке точек поменьше, и тогда, надеюсь, будет видно. Хотя я уже, честно говоря, ни в чём не уверен).

[koraalex]

Там дело в том, что мы всё-таки смотрим на поле скоростей, а не на линию тока...

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

Изменено: koraalex, 12 Ноябрь 2008 - 13:57

[Catherine]

А где-нибудь выложены фотографии с защит? Или я что-то проглядела?(ссылку например))

[Денис]

Не проглядела ;-)
Как раз ночью сделал свои фотографии, то, что снимали ребята на мою камеру. Фотографии не очень, но все же.
http://photo.dsumin....08/lit-diploma/

[Catherine]

Спасибо!) Очень забавные фотографии!) Прям хочется под многими из них подписать мысли запечатленного человека)

[koraalex]

Простите, что возвращаюсь к старой теме.

Сначала хотел дописать-таки (кому оно теперь нужно?) Егору: беда у вас была с моделью, с ней без старших не разобраться. А если бы движок работал, делать графику было бы легче.

Диме:
3.2 Про травинку, продолжение. Скорость в струе больше по середине, а давление там меньше. Если травинка отклонится от "форватера", давление с его стороны окажется меньше, чем с внешнего борта, и её опять туда затянет. Однако, у плавающих объектов есть другие свойства и характеристики, поэтому в немного другой ситуации поведение окажется не таким.
1.2 В начале XX века, когда возникла потребность в практических результатах аэрогидродинамики, разработанная теория оказалась слишком сложной для аналитического решения технических задач, а их численное решение не представлялось возможным из-за гигантского объёма счёта. Тогда стали активно развиваться экспериментальные методы исследования. Понятно, что метод проб и ошибок очень трудоёмок, и лучше, когда возможно, упрощать каждый его этап. Вот - было давно известно, что большой корабль плывёт примерно так же, как его уменьшенная модель, эти знания применялись в кораблестроении. Теоретические изыскания показали: движение сплошной среды подчиняется некоторым законам подобия, так что можно выявить критерии подобия двух течений. Для этого необходимо сопоставить свойства обтекаемого тела с физическими параметрами текущей жидкости.
Вот, простейший параметр тела - характерный размер, как-то померянная длина тела. Если мы берём вдвое большее тело такой же формы, размер будет вдвое больше, значит, чтобы соблюсти подобие, вдвое должны отличаться какие-то параметры течения. Если мы берём тело другой формы, нужно применить тот же способ обмера. Точного подобия не будет, - естественно. Тем не менее, условия обтекания будут похожими, результат испытаний - технически пригодным. Но если тела имеют совсем разную форму, как куб и тонкий обруч, подобие используют только для классового сравнения режимов течения. Более того, для схожести двух картин течения не нужно строгого соответствия параметров, поэтому модель самолёта, который летает при критерии Re~10^6, продувают в аэродинамической трубе, где реализуется Re~10^5.
Подобие не всегда подразумевает масштабирование и не всегда учитывает характерный размер. Например, острый клин могут заменить более тупым. Воздух могут заменить другой газовой смесью. Могут рассматривать частичное подобие, - при той же продувке в аэродинамической трубе некоторые характеристики плохо совпадают с реальными характеристиками самолёта.

Редакция.

Изменено: koraalex, 03 Март 2009 - 18:31

[koraalex]

Опять правлю.