Физическая модель до боли в голове простая

Это с каких же пор модель движения 4х и более гравитирующих тел стала простой? :)

А задумка, конечно, интересная. Кстати, а CUDA часом не быстрее OpenCL?

годы проходят, а motif остается неизменным =)

неизменно страшным, я бы сказал...

>openmotif
Месье знает толк в извращениях.

Хм. http://www.linux.org.ru/gallery/screenshots/3873953

Зачем все компизы и навороты, сидели бы на подобных интерфейсах и все говорили бы что linux быстрее работает чем xp.

и выглядит как привет из восьмидесятых...

Будто это что-то плохое. Дизайн CDE мне нравится.

Вопрос один - чем обусловлен выбор openmotif? Не срача ради, интересно.

2 Eddy_EM:

Ну, я имел ввиду, что имплементированная модель использует формулу, которые все школьники знают. Здесь нет 4-х мерных векторов :) .

На счет CUDA: обязательно попробую, когда доберусь до одного компьютера на кафедре, где стоит можная nvidia, вот забавы будет-то ...

2 PolarFox: да, движок такой же, школьная формула — вот и всё. Но кто не мечтал этакое что-то визуализировать. Я не так давно Си освоил.

2 muhas: согласен, страшненько, но программа весьма функциональна и эльф занимает 40килобайт. Портабельно со всеми версиями libXm с тех-таки 80х годов :)

А что ещё более страшно — то, что я не знаю GTK/Qt, а вот к openmotif приспособился(мне лично нравится функциональная модель кода X intristics+widgets).

а есть что-то лучше?

Segmentation fault (core dumped)

куда баг-репорт слать?

demon@orange:~/src/XmGravdots_v003$ make
cc -g   -c -o many_dots_system.o many_dots_system.c
cc -g   -c -o gui.o gui.c
gui.c: In function ‘main’:
gui.c:56: warning: passing argument 1 of ‘create_and_manage_menubar’ from incompatible pointer type
gui.h:217: note: expected ‘struct _WidgetRec **’ but argument is of type ‘Widget’
gui.c:56: warning: passing argument 2 of ‘create_and_manage_menubar’ from incompatible pointer type
gui.h:217: note: expected ‘struct _WidgetRec **’ but argument is of type ‘Widget’
gui.c: In function ‘org_glxarea’:
gui.c:306: warning: passing argument 3 of ‘XtAddCallback’ from incompatible pointer type
/usr/include/X11/Intrinsic.h:1244: note: expected ‘XtCallbackProc’ but argument is of type ‘void (*)(struct _WidgetRec *)’
cc -g   -c -o process_menubar.o process_menubar.c
process_menubar.c:93: warning: initialization makes integer from pointer without a cast
process_menubar.c:95: warning: initialization makes integer from pointer without a cast
process_menubar.c:103: warning: initialization makes integer from pointer without a cast
process_menubar.c:105: warning: initialization makes integer from pointer without a cast
process_menubar.c:107: warning: initialization makes integer from pointer without a cast
process_menubar.c: In function ‘BuildPulldownMenu’:
process_menubar.c:123: warning: assignment makes pointer from integer without a cast
process_menubar.c: In function ‘create_and_manage_menubar’:
process_menubar.c:160: warning: assignment makes pointer from integer without a cast
cc -g   -c -o help_dlgs.o help_dlgs.c
help_dlgs.c: In function ‘helpCallback’:
help_dlgs.c:140: warning: assignment makes pointer from integer without a cast
help_dlgs.c:161:15: warning: unknown escape sequence: '\040'
help_dlgs.c: At top level:
help_dlgs.c:310: warning: initialization from incompatible pointer type
help_dlgs.c:311: warning: initialization from incompatible pointer type
help_dlgs.c:312: warning: initialization from incompatible pointer type
help_dlgs.c:313: warning: initialization from incompatible pointer type
help_dlgs.c:314: warning: initialization from incompatible pointer type
help_dlgs.c: In function ‘appear_controls_dialog’:
help_dlgs.c:333: warning: assignment makes pointer from integer without a cast
help_dlgs.c:360: warning: passing argument 3 of ‘XtAddCallback’ from incompatible pointer type
/usr/include/X11/Intrinsic.h:1244: note: expected ‘XtCallbackProc’ but argument is of type ‘void (*)(struct _WidgetRec *, int,  struct XmScaleCallbackStruct)’
help_dlgs.c: In function ‘appear_buttons’:
help_dlgs.c:438: warning: assignment makes pointer from integer without a cast
cc -g    -o XmGravDots many_dots_system.o gui.o process_menubar.o help_dlgs.o -lm -lXm -lXt -lpthread -lGL -lGLU
demon@orange:~/src/XmGravdots_v003$ ./XmGravDots 
Segmentation fault (core dumped)
demon@orange:~/src/XmGravdots_v003$

>куда баг-репорт слать?

Спасибо, что не поленились попробывать!

Это то, чего я боялся, на некоторых видеокартах этого не избежать(раньше оговоренный i845, и , наверняка, видеокарты старшей модели).

Врядли возможно будет исправить, не залезая в сам openmotif и libXt. Но, несли можно, вместе в backtrace из gdb отправте на e-mail, указанный внизу файла README. Ну и вывод lspci, если вовсе не жалко будет.

Спасибо.

Незачёт.

Виджеты мотифные, а декорация эксфцшная.

killall xfwm4 && mwm &

Будто это что-то плохое. Дизайн CDE мне нравится.

Кроме look есть еще и feel. В плане современных реалий удобства использования CDE не выдерживает никакой критики.

Вот я и спрашиваю, чем хорошо. Имел опыт только с винформс и гтк, второе явно писало стадо пьяных макак.

> Ну, я имел ввиду, что имплементированная модель использует формулу, которые все школьники знают.

На деле задача не такая уж тривиальная. По сути это является графическим решением диффура, посему необходимо прикручивать соответствующие методы, Ренге-Кутта там какого нибудь. Что резко подогревает интерес к решению задачи, и, заодно, ускоряет модель.

И ещё начальное распределение неверно: надо от горизонтали выбирать угол наклона вектора равномерным распределением, а по этому вектору выбирать модуль уже по Гауссу. Сейчас очень хорошо видно, что множество точек отрисовывают квадрат.

Ну и… ждём результатов моделирования с антиматерией ;).

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

Распределение кубическое такое — это от лени, просто в декартовых координатах появляются точки с радиус-векторами Scale*(drand48()-0.5).

А на счет темной материи — иногда мне кажется, что здесь такое что-то и без её воплощения есть, точки между собой притягиваются, а система в конце концов расширяется на бесконечность(даже имея 0й импульс в начале) :-)

По сути это является графическим решением диффура, посему необходимо прикручивать соответствующие методы, Ренге-Кутта там какого нибудь.

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

Как вариант - можно квантовать по планковскому времени ;) Правда, тогда чтобы рассчитать, что будет с системой через пару минут, придется ждать оочень долго.

Ренге-Кутт — это как раз метод оптимизации численного решения диффуров: то есть повышение шага квантования при сохранении точности.

Оценить точность очень просто:

1) сделай отрисовку траектории

2) оставляешь 2 точки, чтобы они по эллипсу летели.

3) включаешь и смотришь: сильно ли каждый новый виток эллипса отличается от предыдущего.

Из-за ошибок численного решения он должен тихонько расползаться. Возможно из-за этого у тебя они и разлетаются.

Про метод Рунге-Кутты я знаю :)

> Имел опыт только с винформс и гтк, второе явно писало стадо пьяных макак.
По сравнению с мотиф гтк - это просто рай земной.

>а есть что-то лучше?

есть )):

http://www.tcl3d.org/cgi-bin/demolist.tcl?dir=DemoOfTheMonth;cols=4;sort=reverse

скрин страшно уныл, как в этом можно работать

Реквестирую ссылку на обоину.

Ссылка из sylvia-треда протухла и показывает эррор 404.

Ну и… ждём результатов моделирования с антиматерией ;).

с тёмной материей и энергией

Держите:

http://s2.share.te.ua/b153255/kitties_silvy.jpg

На сайте обещают не удалять файлы, по крайней мере пока хостинг живой :)

[qutoe] с тёмной материей и энергией Только до сих пор никто не знает точное распределение темной материи во Вселенной :)

Да, вид имеет оно недружелюбный, но мне было интересно затронуть часть истории строения GUI в восьмидесятых. Например, можно почитать как там конкурировали OPEN LOOK и Motif ... в коце концов жаль что CDE был платной проприетарщиной, именно с её выходом оффтопик и обогнал всех.

Статья, где написано, как прикрутить OpenGL в X11 вышла в девяностых «X and OpenGL», Mark Kilgard, жаль у себя на компьютере её нигде найти не могу.

У меня лично ещё есть одна поделка в таком направлении — это программа для быстрой отрисовки потока данных с микроконтроллера(софтверный осциллограф этакий). Реализировано постредством обычного xmDrawingArea в одной ветке, и через виджет с OpenGL — в другой.

Закончу это(хоть на gtk уже готовых 2 штуки нашел, но всё же) — и тогда возьмусь за GTK+ что-ли, почему бы не знать всё? :)

Спасибо за внимание.

А про SDL все уже забыли? А к ней лучше Guichan прикрутить. :)
Ну а если реально так нужно GUI с OpenGL - то Qt.

PS делал подобное в 10 классе... быстрая отрисовка точек это ещё та задача особенно без быстрого вывода из видео памяти.

Вот я и спрашиваю, чем хорошо. Имел опыт только с винформс и гтк, второе явно писало стадо пьяных макак.

попробуй Tk - я нарадоваться не могу

А чё не на хаскелл?

Только до сих пор никто не знает точное распределение темной материи во Вселенной :)

вроде определили 5% атомов 25% антивещества(тёмной материи) 70% тёмной энергии

По этой теме посмотрите Barnes–Hut simulation, если ещё не видели.

Методы численного интегрирования ДУ (в том числе и Рунге-Кутта с адаптивным шагом) хорошо описаны (с исходниками на C++) в книге Numerical Recipes (The Art of Scientific Computing). У меня 3-е издание (новое), но не думаю, что их реализация такой классики, как Р-К, сильно поменялась за это время.

Так же можно посмотреть, как метод Р-К реализован в Matlab. Т.к. большая часть Matlab написана на самом Matlab, то код многих функций доступен в открытом виде (например, Р-К - это функция ode45).

Я пока обошелся чем-то таким:
dr = p/m∙dt,
dF = p∙dt
Боюсь, что если использовать Рунге-Кутта, то надо «запоминать» несколько значений p(t-dt1), p(t), p(t+dt1) всех точек системы. Это накладно, если объектов много.
Но попробовать стоит.

Зато вы выигрываете в том, что размер шага dt в Р-К обычно можно сделать значительно больше, чем в методе Эйлера (за счёт большей точности), следовательно и самих шагов будет гораздо меньше.

собирал с openmotif

что-то смущают некоторые ошибки при компиляции, особенно вот это - «*несовместимый тип указателя*»:

[yr@dream XmGravDots-v003-r1]$ make
gcc -I/usr/include/openmotif -L/usr/lib64/openmotif -g   -c -o many_dots_system.o many_dots_system.c
gcc -I/usr/include/openmotif -L/usr/lib64/openmotif -g   -c -o gui.o gui.c
gui.c: В функции ‘main’:
gui.c:56: предупреждение: в передаче аргумента 1 ‘create_and_manage_menubar’: несовместимый тип указателя
gui.h:217: замечание: expected ‘struct _WidgetRec **’ but argument is of type ‘Widget’
gui.c:56: предупреждение: в передаче аргумента 2 ‘create_and_manage_menubar’: несовместимый тип указателя
gui.h:217: замечание: expected ‘struct _WidgetRec **’ but argument is of type ‘Widget’
gui.c: В функции ‘org_glxarea’:
gui.c:306: предупреждение: в передаче аргумента 3 ‘XtAddCallback’: несовместимый тип указателя
/usr/include/X11/Intrinsic.h:1244: замечание: expected ‘XtCallbackProc’ but argument is of type ‘void (*)(struct _WidgetRec *)’
gui.c: В функции ‘zoomCallback’:
gui.c:585: предупреждение: приведение указателя к целому другого размера
gui.c: В функции ‘grid_callback’:
gui.c:621: предупреждение: приведение указателя к целому другого размера
gcc -I/usr/include/openmotif -L/usr/lib64/openmotif -g   -c -o process_menubar.o process_menubar.c
process_menubar.c:93: предупреждение: при инициализации указатель преобразуется в целое без приведения типа
process_menubar.c:95: предупреждение: при инициализации указатель преобразуется в целое без приведения типа
process_menubar.c:103: предупреждение: при инициализации указатель преобразуется в целое без приведения типа
process_menubar.c:105: предупреждение: при инициализации указатель преобразуется в целое без приведения типа
process_menubar.c:107: предупреждение: при инициализации указатель преобразуется в целое без приведения типа
process_menubar.c: В функции ‘BuildPulldownMenu’:
process_menubar.c:123: предупреждение: в присваивании целое преобразуется в указатель без приведения типа
process_menubar.c: В функции ‘create_and_manage_menubar’:
process_menubar.c:160: предупреждение: в присваивании целое преобразуется в указатель без приведения типа
gcc -I/usr/include/openmotif -L/usr/lib64/openmotif -g   -c -o help_dlgs.o help_dlgs.c
help_dlgs.c:163:15: warning: unknown escape sequence: '\040'
help_dlgs.c:312: предупреждение: несовместимый тип указателя в инициализации
help_dlgs.c:313: предупреждение: несовместимый тип указателя в инициализации
help_dlgs.c:314: предупреждение: несовместимый тип указателя в инициализации
help_dlgs.c:315: предупреждение: несовместимый тип указателя в инициализации
help_dlgs.c:316: предупреждение: несовместимый тип указателя в инициализации
help_dlgs.c: В функции ‘appear_controls_dialog’:
help_dlgs.c:335: предупреждение: в присваивании целое преобразуется в указатель без приведения типа
help_dlgs.c:362: предупреждение: в передаче аргумента 3 ‘XtAddCallback’: несовместимый тип указателя
/usr/include/X11/Intrinsic.h:1244: замечание: expected ‘XtCallbackProc’ but argument is of type ‘void (*)(struct _WidgetRec *, int,  struct XmScaleCallbackStruct)’
help_dlgs.c: В функции ‘appear_buttons’:
help_dlgs.c:440: предупреждение: в присваивании целое преобразуется в указатель без приведения типа
gcc -I/usr/include/openmotif -L/usr/lib64/openmotif -g    -o XmGravDots many_dots_system.o gui.o process_menubar.o help_dlgs.o -lm -lXm -lXt -lpthread -lGL -lGLU -lX11

Ну и соответственно результат:

[yr@dream XmGravDots-v003-r1]$ ./XmGravDots 
IRQ's not enabled, falling back to busy waits: 2 0
Ошибка сегментирования (core dumped)

система fedora 13 64bit

видео встроенное в амд785 чипсет драйвер -R600

backtrace:

Starting program: /home/yr/ME/tmp/XmGravDots-v003-r1/XmGravDots 
[Thread debugging using libthread_db enabled]
IRQ's not enabled, falling back to busy waits: 2 0

Program received signal SIGSEGV, Segmentation fault.
0x0000000000000000 in ?? ()
Missing separate debuginfos, use: <много библиотек>
(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x0000000000405256 in InitGL () at gui.c:76
#2  0x0000000000405162 in main (argc=1, argv=0x7fffffffdfe8) at gui.c:51

Во-первых, материи несколько больше, во-вторых, природу темной материи могут определить только в случае обнаружения бозона Хиггса, в третьих, я говорил не про количественное соотношение, а про качественное: определено уже, что темная энергия более-менее изотропна, а вот темная материя имеет неравномерное распределение.

Спасибо за бек-трейс.
Выходит, что чёрный список пополняется Intel i845, i945 + amd785.
Вылетает оно на первой же openGL-функции.

Сам я успешноо запускал на таких видеокартах:
ATI Radeon X1600, Nvidia GeForce 4 Ti4200, Nvidia GeForce 7800GT.

Т.е. проблема со встроенными видеокартами, как я вижу. Извините за принесённые неудобства. Надо что-то с этим делать.

Ещё кое-что: какой у вас, vyv, стоит драйвер? На ноутбуке с intel i845 и драйвером vesa программа падает, а для нового ядра и Х интел даже не шевелится поработать над своим драйвером.

Причина segfault'a связана, как я говорил ранее, с методами, которые используются для привязки OpenGL контекста к openmotif-виджету. Я этим пытаюсь сказать, что это не есть следствие такого кодия, проблема в библиотеках ([libXm, libXt]+libOpenGL). Надеюсь что найду время порыться там.

Спасибо.

>Физическая модель до боли в голове простая
Модель гравитации с такой кучей точек и простая? Это же как? Или програмка не для моделирования предназначена а для программирования?

Для того, чтобы увидеть как будет вести себя система в будущем, надо ещё поработать над алгоритмом, возможно поискать хорошие модели физических симуляций, т.к. эта пока написана с нуля(даже векторы вводились своими кустарными структурами).Но надо с чего-то начинать же. Чисто для программирования можно и блокнотики писать, здесь всё немного сложнее.
На счет тулкитов: к счастью, «движок» этого всего легко перенести на Qt/GTK/GLUT, чтобы избежать выше указанных проблем с видеокартами, что наверное будет сделано в будущем(т.к. всё что внутри glBegin(); ... glEnd(); портабельно).

nvidia 9600 - работает. Но при компиляции много warning'ов, что не есть хорошо. Кроме того, у вас некоторые точки в процессе движения куда-то исчезают - аннигилируют с антиматерией, что ли? И да, движение все-таки не очень реалистично: при близком пролете точки около другой ни одна практически не изменяет своей траектории.

Отлично! За мотиф отдельный зачет, некрофилия - она всегда в моде ;)

Вообще думал что-нибудь на OpenCL сделать, но как-то не приходило в голову такое взаимодействие. Теперь надо, чтобы вокруг каждой точки крутились еще несколько, вокруг них еще, и далее рекурсивно...

>Ещё кое-что: какой у вас, vyv, стоит драйвер?

чипсет - так называется : RS880 [Radeon HD 4200] (amd785g)

драйвер «открытый» - xorg-x11-drv-ati-6.13.0-1
DRI - r600_dri.so (mesa-dri-drivers-7.8.1-6)

различные openGL приложения работают нормально.

Думаю, что проблема крашдампов в преобразованиях int <-> pointer

в 32битной системе это допустимо, а в 64-ой такой адрес (из «инта») приводит к SIGSEGV

скорее всего это какой-нибудь адрес callback функции.

я бы обратил внимание на эти warning'и: «предупреждение: в присваивании целое преобразуется в указатель без приведения типа»

вот кстати ссылка по теме: «Перенос Linux-приложений на 64-разрядные системы»

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

Хотя не сильно обнадёживает, с выше указанными видеокартами падает и на 32бит системах.

Не хочу вводить в заблуждение: если у вас есть хороший пример на OpenCL - то это достойно нового скриншота на главной, здесь эти расширения не используются :)