Моя программа рисует молекулы; когда я начинал её писать, мне не хотелось разбираться с OpenGL/Direct3D, и вместо этого я сделал своё рисование по точкам (в Delphi). Чтобы нарисовать картинку на bitmap-е, берутся scanline-ы этого битмапа, и дальше с ними программа работает как с обычным двумерным массивом. Для каждой точки этого массива, если например рисуется сфера, просчитывается цвет (по данным о наклоне поверхности этой точки, направлению и цвету источника света и т.д.). Сферы рисуются как набор горизонтальных линий, цилиндры – как набор линий произвольного направления. Плюс реализовано много приёмов оптимизации, главный из которых – нарисовать что-то один раз в отдельном массиве и потом просто перерисовывать на картинку. Получилась такая графика:
У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K>Моя программа рисует молекулы; когда я начинал её писать, мне не хотелось разбираться с OpenGL/Direct3D, и вместо этого я сделал своё рисование по точкам (в Delphi). Чтобы нарисовать картинку на bitmap-е, берутся scanline-ы этого битмапа, и дальше с ними программа работает как с обычным двумерным массивом.
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
Хочешь сказать, что тебе на Delphi/bitmap скорости хватает? А покрутить молекулу из 1000 атомов сможешь без рывков?
Здравствуйте, Khimik, Вы писали:
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
M>>Хочешь сказать, что тебе на Delphi/bitmap скорости хватает? А покрутить молекулу из 1000 атомов сможешь без рывков?
K>Да.
Круто. А какова загруженность процессора будет?
>>Насчёт Java — там точно хватает скорости: http://jmol.sourceforge.net/technotes/
K>Хочу уточнить, Java — это интерпретируемый язык?
Нет. Компиляция по ходу исполнения.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Khimik, Вы писали:
M>>>Хочешь сказать, что тебе на Delphi/bitmap скорости хватает? А покрутить молекулу из 1000 атомов сможешь без рывков?
K>>Да.
M>Круто. А какова загруженность процессора будет?
Я не смотрел, помню что на компьютерах с Pentium 200 уже была нормальная скорость для средних молекул (если без теней).
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d
На них всех можно реализовать, но зачем? В этом нет никакого смысла, кроме онанизма.
K>(или там не хватит скорости)?
Скорость понятие относительное.
Здравствуйте, Khimik, Вы писали:
K> Я не смотрел, помню что на компьютерах с Pentium 200 уже была нормальная скорость для средних молекул (если без теней).
Это что же, пост "20 лет спустя"? А вообще запрашиваю демо в студию.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
K>> Я не смотрел, помню что на компьютерах с Pentium 200 уже была нормальная скорость для средних молекул (если без теней).
VTT>Это что же, пост "20 лет спустя"? А вообще запрашиваю демо в студию.
Занятное приложение. Достаточно шустро рисует даже при разворачивании окна на весь экран, хоть и рывками. Причем это в одном потоке. А рендеринг так и просит себя распараллелить.
Что же касается первоначального вопроса, то в C# и Java скорость при работе с простыми массивами чисел вряд ли будут радикально отличаться от тех же Delphi. Flash — это уже почти история. А Unity3d — это уже готовый фреймворк, причем заточенный именно на комфортное использование аппаратного ускорения видеокарты через высокоуровневые абстракции или даже визуальное программирование в редакторе.
Наверное вам стоит посмотреть в сторону GPGPU решений, допустим DirectCompute, Cuda, OpenCL и т.д. Если алгоритм отрисовки ляжет хорошо, то прирост в скорости будет в несколько порядков.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
У меня вопрос. Ты этот 3D, включая освещение, тени, отражения, проекции, z-order всё своими силами сделал? Это конечно нереально круто если это так, но не проще ли этот чимлаб было сделать сразу на OpenGL, там же это все пишется элементарно, да и открытого кода с божескими лицензиями хоть попой ешь, визуализацией химических моделей кто только не занимается.
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
Можно, можно и на голом Web-е(CEF+WebGL) это сделать, всё летает замечательно.
Здравствуйте, peterbes, Вы писали:
P>Здравствуйте, Khimik, Вы писали:
P>У меня вопрос. Ты этот 3D, включая освещение, тени, отражения, проекции, z-order всё своими силами сделал?
Да, мне нравилось разбираться со всякой математикой и алгоритмами.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
ЕМНИП, юнити использует C++ для бэкенда и биндится к шарпу, джаве для фронтенда. Т.е. ты берёшь юнити и пишешь скрипты на шарпе. По поводу производительности, посмотри на Kerbal Space Program он как раз на юнити сделан.
Здравствуйте, Mazay, Вы писали:
M>Здравствуйте, Khimik, Вы писали:
K>>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
M>Насчёт Java — там точно хватает скорости: http://jmol.sourceforge.net/technotes/
Когда требуется отобразить молекулу из очень большого количества атомов (например тысяча), возникают другие тормоза – например, чтобы определить связи между атомами в молекуле, нужно выполнить два или три вложенных цикла по количеству атомов (например простой алгоритм – перебрать все межатомные расстояния, там где расстояние меньше порогового, значит есть связь). При переходе с Delphi на Java скорость таких алгоритмов сильно снизится?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
M>>Насчёт Java — там точно хватает скорости: http://jmol.sourceforge.net/technotes/
K>Когда требуется отобразить молекулу из очень большого количества атомов (например тысяча), возникают другие тормоза – например, чтобы определить связи между атомами в молекуле, нужно выполнить два или три вложенных цикла по количеству атомов (например простой алгоритм – перебрать все межатомные расстояния, там где расстояние меньше порогового, значит есть связь). При переходе с Delphi на Java скорость таких алгоритмов сильно снизится?
Здравствуйте, Khimik, Вы писали:
K>Когда требуется отобразить молекулу из очень большого количества атомов (например тысяча), возникают другие тормоза – например, чтобы определить связи между атомами в молекуле, нужно выполнить два или три вложенных цикла по количеству атомов (например простой алгоритм – перебрать все межатомные расстояния, там где расстояние меньше порогового, значит есть связь).
А зачем ты каждую с каждой проверяешь?
Замечаем что dist(P1, P2) >= abs(dist(P0, P1) — dist(P0, P2))
Берёшь первый атом.
Считаешь расстояние от него до каждого атома.
Сортируешь атомы по расстоянию.
Теперь нам нужно сравнивать не до конца массива, а только пока разница расстояний между текущим атомом и сравниваемым меньше пороговой величины.
... << RSDN@Home 1.2.0 alpha 5 rev. 62>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Khimik, Вы писали:
K>Моя программа рисует молекулы; когда я начинал её писать, мне не хотелось разбираться с OpenGL/Direct3D, и вместо этого я сделал своё рисование по точкам (в Delphi). Чтобы нарисовать картинку на bitmap-е, берутся scanline-ы этого битмапа, и дальше с ними программа работает как с обычным двумерным массивом. Для каждой точки этого массива, если например рисуется сфера, просчитывается цвет (по данным о наклоне поверхности этой точки, направлению и цвету источника света и т.д.). Сферы рисуются как набор горизонтальных линий, цилиндры – как набор линий произвольного направления. Плюс реализовано много приёмов оптимизации, главный из которых – нарисовать что-то один раз в отдельном массиве и потом просто перерисовывать на картинку. Получилась такая графика:
K>Image: pic.jpg
K>У меня вопрос: на какие других платформах можно реализовать такой движок? Можно ли это реализовать на C#, Java, Flash, Unity3d (или там не хватит скорости)?
Очень интересный софт (уже глянул на демо на сайте). А если там вся графика написана с помощью массива точек, то тем более вызывает уважение.
И всё же я бы советовал переписать визуализацию с помощью OpenGL — тогда само приложение можно писать на вообще любом языке (даже тормознутом Питоне) и всё будет отлично крутиться. Правда при этом придётся полностью переписать все алгоритмы с нуля. Но оно того в общем то стоит, потому как это получается работа на совсем другом уровне абстракции.
Отвечая же на изначальный вопрос (насчёт переноса визуализации через массивы точек в другие языки), могу сразу сказать, что это существенно зависит от вида используемых алгоритмов. К примеру, если при работе с массивом используется адресная арифметика (что нормально в компилируемых в нативный код языках и очень повышает эффективность) или вообще указатели, то такой алгоритм не получится перенести на Java, Flash и т.п. (да и с C# вопросы будут) без существенных потерь производительности — такой код можно перенести без потерь только на другой нативный язык (типа C++, D, Rust и т.п.). Так что надо смотреть конкретный код. Но если там не используется ничего такого специфического "нативного", то перенос с Delphi на Java/C# скорее всего не изменит скорости. Перенос на C++ увеличит. А перенос на Flash или что-нибудь скриптовое замедлит на порядки.
P.S. А в указанные "много приёмов оптимизации" входит использование SIMD? Одно это (вне зависимости от языка, хотя не в каждом оно доступно) способно ускорить подобные алгоритмы на порядок.
>P.S. А в указанные "много приёмов оптимизации" входит использование SIMD?
Я первый раз услышал про SIMD, разве это не подразумевает ассемблерный код?
>R-tree или другой spatial index используете?
Нет, первый раз услышал, посмотрел Вики. Наверно придётся это осваивать, если буду портировать программу на медленный язык.
Я планировал, если буду оптимизировать эти участки кода, построить трехмерный массив с интервалами координат, в которые добавляется каждый атом, и потом сравнивать только атомы, находящиеся в одной или смежных ячейках этого массива (т.е. если это не смежные ячейки, значит расстояние между атомами заведомо больше размера ячейки и связи нет). Надо полагать, R-tree это гораздо более эффективное решение.
Честно говоря я даже не осилил написать самостоятельно алгоритм быстрой сортировки, хотя немного пробовал это сделать, так что разбираться в чужих алгоритмах придётся.
>А зачем ты каждую с каждой проверяешь? > Замечаем что dist(P1, P2) >= abs(dist(P0, P1) — dist(P0, P2)) > Берёшь первый атом. > Считаешь расстояние от него до каждого атома. > Сортируешь атомы по расстоянию. > Теперь нам нужно сравнивать не до конца массива, а только пока разница расстояний между текущим атомом и сравниваемым меньше пороговой величины.
Какой-то странный алгоритм
Выгода от упорядочения атомов будет не очень большая, поскольку в сферу от атома P0 на больших расстояниях до этого атома войдёт много атомов, и их всех надо перебирать. А затраты на сортировку по расстоянию до P0 сделают этот алгоритм достаточно медленным.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K>Я первый раз услышал про SIMD, разве это не подразумевает ассемблерный код?
Не обязательно. Вообще ситуация с SIMD очень не тривиальная и сильно зависит от языка и компилятора. Попробую описать варианты:
1. Язык не умеющий встроенного ассемблера и компилятор не умеющий simd. По сути тут ничего сделать нельзя — программировать simd не получится. Ну т.е. конечно можно создать нужную функцию другими инструментами и потом как-то прилинковать/загрузить в свой код, но это мы не считаем.
2. Язык умеющий встроенный ассемблер. Понятно что тут весь simd доступен (конечно если компилятор вовремя обновляется), но программировать так довольно не удобно. Однако тут всегда можно накрутить любые уровни абстракции поверх этого, написав удобную библиотеку. Соответственно если она есть для данного языка, то считай что проблема решена.
3. Расширения языка (обычно специфичные для конкретного компилятора) для поддержки SIMD. Типа C++ intrinsic. Т.е. компилятор тут знает про SIMD, но всё опять же руками. Это уровень немного повыше по удобству, чем предыдущий, но опять же не особо комфортный. Хотя тут опять же можно накрутить поверх любые уровни абстракции, получив удобную библиотеку. Например типа Boost.SIMD.
4. Автоматическая векторизация — в язык при этом не добавляется вообще ничего. Т.е. это когда компилятор знает про SIMD и сам пытается использовать эти инструкции во всех подходящих циклах и т.п. Уже имеется в некоторых компиляторах, однако пока не дотягивает по уровню до ручного кода. К примеру на реальных задачах у меня включение автовекторизации (опция компилятора) в GCC увеличивало быстродействие в 2-3 раза, в то время как ручной кодирование способно увеличить быстродействие в 16 раз на современных процессорах.
5. Специальные внешние инструменты, созданные исключительно для написания параллельного кода на неком специальном языке. Обычно выдают объектные файлы, которые линкуются в основную программу. Из плюсов тут имеется достаточно высокоуровневый код и автоматическая поддержка разных архитектур (к примеру можно скомпилировать код под Xeon Phi и получить максимальную производительность не меняя код вообще). А из минусов соответственно наличие дополнительного инструмента сборки и отсутствие нормальной интеграции в архитектуру приложения (взаимодействие только на уровне вызова функции).
Понятно, что будущее за вариантом 4, но это когда-то очень далеко (аналогичная ситуация была с оптимизацией обычного кода лет 20 назад), когда он сравняется по эффективным с ручным. А пока я пользуюсь вариантами 5 и 3, в зависимости от ситуации.
Так что если simd до сих пор не применяется для оптимизации, то очень рекомендую. Кстати, на обработках больших массивов вполне хорошо себя чувствует и автоматическое распараллеливание по ядрам. К примеру с помощью openmp и т.п. Главное чтобы вычисления не были слишком короткими, иначе накладные расходы на создание/переключению потоков сожрут все преимущества. В общем если у вас там имеется код вида for(int i=0; i<size; i++) dst[i]=F(src[i]), то переписав его с помощью simd и применив openmp можно ускориться раз в 100 на современных процессорах.
Правда я так понял, что у вас там не стоит вопрос с ускорение существующего кода, а хочется переписать на некий другой язык всего лишь без потери текущей производительности. Правильно? ) Тогда боюсь мой ликбез выше вам не совсем не нужен))) Кстати, а зачем переписывать, если не секрет? ) Этот вопрос не очень понятен, если текущее быстродействие всем устраивает... Да, а если переписать скажем на C++, то скорее всего получится ускорение и без применения simd, openmp и т.п.. ))) Ну а если на Флеш и т.п., то будет замедление на порядки. )))
P.S. Но это всё касалось работы с массивами в общем случае. Если же говорить конкретно о визуализации, то я бы в любом случае предпочёл использование opengl, вне зависимости от языка. Потому как: 1. распараллеливание на GPU по любому мощнее всех вариантов с CPU, 2. данный код уже давно написал и отлично отлажен.
На молекулах каких-нибудь белков где пространства много, но заполнено оно неравномерно, дерево будет эффективней по памяти.
С другой стороны если вы заранее можете оценить и размеры, и "плотность распределения" (размер ячеек вашего 3d-массива), и атомы расположены более или менее равномерно, от дерева может быть пользы и не много будет.
Кстати, перепутал (названия у них контр-интуитивные), вам нужен KD-tree.
Тут есть реализация, в т.ч. на Паскале. http://www.alglib.net/other/nearestneighbors.php
Можно по-быстрому прикрутить, оценить пользу, а потом уже наслаждаться процессом и сделать все самому
_>Правда я так понял, что у вас там не стоит вопрос с ускорение существующего кода, а хочется переписать на некий другой язык всего лишь без потери текущей производительности. Правильно? ) Тогда боюсь мой ликбез выше вам не совсем не нужен))) Кстати, а зачем переписывать, если не секрет? )
Я опасаюсь, что Windows умрёт, а Embarcadero так и не осилят перевод Delphi на кросс-платформенные приложения, т.е. Delphi наконец умрёт.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, Khimik, Вы писали:
K>Я опасаюсь, что Windows умрёт, а Embarcadero так и не осилят перевод Delphi на кросс-платформенные приложения, т.е. Delphi наконец умрёт.
Хотя лично я крайне поддерживаю идею ухода с Дельфи. Но не по причинам кросс-платформенности, а из-за качества самого инструмента.
Далее, если есть опасения о смерти винды, то для выбора языка надо понимать на кого тогда ориентироваться. Понятно, что под смертью винды подразумевается смерть персональных компьютеров (потому как говорить о захвате рынка ПК линухом или маком просто смешно). Не думаю, что это произойдёт полностью (на рабочих местах всё равно останется ПК), но в какой-то степени действительно происходит. Соответственно речь идёт о мобильных платформах и тут явным лидером является Андроид. Т.е. если кто-то и займёт место винды, то это будет именно эта ОС.
Ну а если говорить о программирование под Андроид, то очевидно сразу возникают только два языка: C++ (через ndk) и Java (через sdk). Причём с учётом тормознутости мобильных процессоров для подобных нагруженных приложений, явно лучше первый вариант. Тем более, что он может быть ещё и кроссплатформенным. Это если делать прорисовку самим. Если же делать всё через opengl (es), то можно и второй, т.к. сейчас в каждый мобильный чип пихают неплохой GPU. Ну а можно и opengl на C++ (самый быстрый и кроссплатформенный вариант). Ещё конечно же можно учесть вариант JS (веб-интерфейс), но тут быстродействие будет ещё печальнее жабки. Но зато такой вариант максимально кроссплатформенный (даже не требуется перекомпиляция, как в случае C++).
_>Далее, если есть опасения о смерти винды, то для выбора языка надо понимать на кого тогда ориентироваться. Понятно, что под смертью винды подразумевается смерть персональных компьютеров (потому как говорить о захвате рынка ПК линухом или маком просто смешно). Не думаю, что это произойдёт полностью (на рабочих местах всё равно останется ПК), но в какой-то степени действительно происходит. Соответственно речь идёт о мобильных платформах и тут явным лидером является Андроид. Т.е. если кто-то и займёт место винды, то это будет именно эта ОС.
А как же Mac? Вроде есть компьютеры на Mac OS?
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
_>Ну а если говорить о программирование под Андроид, то очевидно сразу возникают только два языка: C++ (через ndk) и Java (через sdk). Причём с учётом тормознутости мобильных процессоров для подобных нагруженных приложений, явно лучше первый вариант. Тем более, что он может быть ещё и кроссплатформенным. Это если делать прорисовку самим. Если же делать всё через opengl (es), то можно и второй, т.к. сейчас в каждый мобильный чип пихают неплохой GPU. Ну а можно и opengl на C++ (самый быстрый и кроссплатформенный вариант). Ещё конечно же можно учесть вариант JS (веб-интерфейс), но тут быстродействие будет ещё печальнее жабки. Но зато такой вариант максимально кроссплатформенный (даже не требуется перекомпиляция, как в случае C++).
Надо понять, что вообще понимать под выражением "рисовать на js". Если использовать 3d framework-и а-ля d3js и three, то получиться может и вправду чудовищно медленно, но этому есть прекрасная альтернатива -webgl с прекрасной поддержкой opengl на уровне программного интерфейса API GL, хотя под капотом может быть и OpenGL ES и DirectX(9-11) в зависимости от операционной системы и железа.
Можно посмотреть и поиграться примерами и оценить как это летает в живую, можно и doom погонять. Переписывать же свою самописную 3D библиотеку, не использующую OpenGl/DX, под разные платформы и под разное железо можно лишь только для своего личного удовольствия в качестве хобби. Я бы лично в таком продукте не видел бы никакого смысла.
Вообще говоря, WebGL это не обязательно web приложения, Chromium Embedded Framework позволяет создавать свои переложения полностью отвязанные от внешнего браузера, где в качестве рендера в клиентской части родительского окна используется webkit-движок со всеми плюшками и бенефитами полноценного браузера.
Сам хромиум находится на http://www.chromium.org/ , к проекту энтузиасты из комьюнити уже приладили порты под и под C, C++, и под Delphi, и под Go, Java, .NET/Mono, и Python
Здравствуйте, peterbes, Вы писали:
P>Надо понять, что вообще понимать под выражением "рисовать на js". Если использовать 3d framework-и а-ля d3js и three, то получиться может и вправду чудовищно медленно, но этому есть прекрасная альтернатива -webgl с прекрасной поддержкой opengl
У ThreeJS есть несколько бэкендов, один из них как раз — WebGL. Все возможные тормоза, зависящие от JavaScript, не имеют никакого отношения к скорости отрисовки, т.к. JavaScript в этом случае отвечает только за конструирование всяких вершинных буферов.
Здравствуйте, Khimik, Вы писали:
K>Для каждой точки этого массива, если например рисуется сфера, просчитывается цвет (по данным о наклоне поверхности этой точки, направлению и цвету источника света и т.д.). Сферы рисуются как набор горизонтальных линий, цилиндры – как набор линий произвольного направления. Плюс реализовано много приёмов оптимизации, главный из которых – нарисовать что-то один раз в отдельном массиве и потом просто перерисовывать на картинку. Получилась такая графика:
Поздравляю, вы изобрели raytracing.
POV-Ray уже смотрели?
Здравствуйте, Khimik, Вы писали:
K>А как же Mac? Вроде есть компьютеры на Mac OS?
Конечно и занимает свою небольшую долю на рынке ПК, без всяких шансов обойти винду. Т.е. есть вариант (теоретический) "винда умрёт", но это только вместе с рынком ПК, соответственно тогда умрёт и OS X. Или есть вариант что рынок ПК не умрёт, но тогда и винда будет жить и царить. ))) Т.е. варианта "винда умерла, а OS X популярна" не просматривается даже теоретически.
Это если говорить в вышеуказанном контексте смерти винды. ))) Если же говорить просто о небольшом расширение круга покупателей, то кроссплатформенность безусловно имеет смысл. Только рекомендую в начале оценить соотношение стоимости перехода на кроссплатформенный инструмент и потенциальный прирост прибыли от расширения рынка.
P.S. Я то сам сторонник как раз кросплатформенного подхода, но мне не надо ничего переписывать — у нас изначально весь код такой. )
Здравствуйте, peterbes, Вы писали:
P>Надо понять, что вообще понимать под выражением "рисовать на js". Если использовать 3d framework-и а-ля d3js и three, то получиться может и вправду чудовищно медленно, но этому есть прекрасная альтернатива -webgl с прекрасной поддержкой opengl на уровне программного интерфейса API GL, хотя под капотом может быть и OpenGL ES и DirectX(9-11) в зависимости от операционной системы и железа.
Да, это пойдёт. Но только если в приложение высокая нагрузка приходится исключительно на визуализацию. Если там будут какие-то тяжёлые алгоритмы не связанные с прорисовкой, то это уже мрак.
P>Можно посмотреть и поиграться примерами и оценить как это летает в живую, можно и doom погонять. Переписывать же свою самописную 3D библиотеку, не использующую OpenGl/DX, под разные платформы и под разное железо можно лишь только для своего личного удовольствия в качестве хобби. Я бы лично в таком продукте не видел бы никакого смысла.
Нууу если она работает с массивами точек, то это в общем то портируется куда угодно в пару строк. ))) Если конечно изначально написано на кроссплатформенном языке. )))
P>Вообще говоря, WebGL это не обязательно web приложения, Chromium Embedded Framework позволяет создавать свои переложения полностью отвязанные от внешнего браузера, где в качестве рендера в клиентской части родительского окна используется webkit-движок со всеми плюшками и бенефитами полноценного браузера.
Я в курсе, использовал CEF уже (правда для другого — для отображения веб страницы внутри своего нормального приложения). Но это в любом случае получится веб интерфейс, со всеми недостатками и преимуществами.
Здравствуйте, peterbes, Вы писали:
P>Сам хромиум находится на http://www.chromium.org/ , к проекту энтузиасты из комьюнити уже приладили порты под и под C, C++, и под Delphi, и под Go, Java, .NET/Mono, и Python
Здравствуйте, WolfHound, Вы писали:
WH>Теперь нам нужно сравнивать не до конца массива, а только пока разница расстояний между текущим атомом и сравниваемым меньше пороговой величины.
Чтобы не попасть на граничный случай, надо выбрать за P0 не атом, а матожидание координаты атома, где координаты всех атомов — исходная случайная величина.
В любом случае, это вычисление делается один раз при загрузке схемы и один раз строится граф соединений, там нечему тормозить при прорисовке затем.
Ну и стоимость алгоритма "в лоб" без предварительной сортировки как раз равна стоимости сортировки прямым выбором, ХЗ насчет того — имеет ли смысл предварительно сортировать.
Здравствуйте, fireton, Вы писали:
K>>Для каждой точки этого массива, если например рисуется сфера, просчитывается цвет (по данным о наклоне поверхности этой точки, направлению и цвету источника света и т.д.). Сферы рисуются как набор горизонтальных линий, цилиндры – как набор линий произвольного направления. Плюс реализовано много приёмов оптимизации, главный из которых – нарисовать что-то один раз в отдельном массиве и потом просто перерисовывать на картинку. Получилась такая графика:
F>Поздравляю, вы изобрели raytracing.
Нифига. У него просто проекция поверхности на экран + подсчет бликов/освещений по вектору м/у источником света и "зрителем". Причем, у него всего две фигуры — шар и цилиндр, поэтому нормаль у него считается аналитически, а не как нормаль треугольника наподобие того, как это есть в современных картейках. Поэтому, любой сколь близкий к экрану шар и цилиндр так и останется шаром и цилиндром, а не набором плоскостей. Можно, конечно, в картейках использовать подпрограммы-шейдеры для тех же целей, но это будет перенос идентичного алгоритма из CPU в GPU и не более.
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, fireton, Вы писали:
K>>>Для каждой точки этого массива, если например рисуется сфера, просчитывается цвет (по данным о наклоне поверхности этой точки, направлению и цвету источника света и т.д.). Сферы рисуются как набор горизонтальных линий, цилиндры – как набор линий произвольного направления. Плюс реализовано много приёмов оптимизации, главный из которых – нарисовать что-то один раз в отдельном массиве и потом просто перерисовывать на картинку. Получилась такая графика:
F>>Поздравляю, вы изобрели raytracing.
V>Нифига. У него просто проекция поверхности на экран + подсчет бликов/освещений по вектору м/у источником света и "зрителем". Причем, у него всего две фигуры — шар и цилиндр, поэтому нормаль у него считается аналитически, а не как нормаль треугольника наподобие того, как это есть в современных картейках. Поэтому, любой сколь близкий к экрану шар и цилиндр так и останется шаром и цилиндром, а не набором плоскостей. Можно, конечно, в картейках использовать подпрограммы-шейдеры для тех же целей, но это будет перенос идентичного алгоритма из CPU в GPU и не более.
Есть ещё треугольники:
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>Теперь нам нужно сравнивать не до конца массива, а только пока разница расстояний между текущим атомом и сравниваемым меньше пороговой величины.
V>Чтобы не попасть на граничный случай, надо выбрать за P0 не атом, а матожидание координаты атома, где координаты всех атомов — исходная случайная величина.
Если в этом алгоритме использовать не быструю сортировку, а обычную простую сортировку, которую я могу сделать — число итераций пропорционально квадрату от числа атомов. Так и при переборе расстояний между каждой парой атомов тоже число итераций пропорционально этому квадрату.
Плюс, как я уже написал, на больших расстониях от P0 в каждый сегмент попадёт большое число атомов, какой-то некрасивый алгоритм.
"Ты должен сделать добро из зла, потому что его больше не из чего сделать." Р.П. Уоррен
Здравствуйте, vdimas, Вы писали:
F>>Поздравляю, вы изобрели raytracing.
V>Нифига. У него просто проекция поверхности на экран + подсчет бликов/освещений по вектору м/у источником света и "зрителем".
Это и есть raytracing.
V>Причем, у него всего две фигуры — шар и цилиндр, поэтому нормаль у него считается аналитически, а не как нормаль треугольника наподобие того, как это есть в современных картейках.
Видеокарты не используют raytracing, а используют множество треугольников, z-buffer и отсечение по направлению. Поэтому сферы с нормальным освещением (бликами) и отражением не сделаешь на видеокартах без шейдеров.
