Управляемая сцена - Mailing list pgsql-ru-general
From | Dmitry Turin |
---|---|
Subject | Управляемая сцена |
Date | |
Msg-id | 859362693.20081219131120@belarusbank.minsk.by Whole thread Raw |
List | pgsql-ru-general |
Прогресс в офисных технологиях остановился, и это произошло потому, что пользователь, способный написать примитивненькую программку не может: *) отобразить 3-мерные данные в окне своей программы *) передвигать 3-мерные объекты командами в чужой программе (в такой как 'Microsoft Office'), и видеть изменения на экране Объеты могут быть нарисованы мышью самостоятельно, скачены из интернета, получены как результат вычислений или как выходные данные с оборудования. В любом случае нам нужен: *) бинарный формат для файла, содержащего 3D-объекты, причем объекты должны записываться в виде треугольников (которые понятны пользователям), а не на языках 3DMLW, 3DXML, COLLADA, т.к. пользователь не осваивает формулирование и рассмотрение своих задач на этих языках *) движок внутри операционной системы, который: o) позволяет загрузить в себя эти банарные файлы o) по запросу объектов возвращает их в формате X11 [1], дабы программа, обратившаяся к этому движку, могла отправлять полученные данные своему X-серверу без каких-либо собственных вычислений или изменений (без обращения к OpenGL, DirectX, которых пользователь никогда не освоит !!) o) предоставляет два способа изменить координаты объектов (оба способа порождают команды управления X-сервером в формате X11, которые немедленно направляются X-серверу): -) с помощью языка запросов (что позволяет программе изменять координаты) -) принимая события в формате X11 [1], которые также являются командами изменить координаты, но посланы мышью (что позволяет мыши изменить координаты) Пользователю будет достаточно вызвать одну функцию, назовем ее 'printg', в которой указать какие 3D-объекты из базы данных движка должны возникнуть на экране (эта функция, будучи вызванной, автоматически перенаправляет все мышиные команды перемещения объектов и движения камеры в движок, а все полученные от движка сообщения о движении объектов автоматически перенаправляет в X-сервер). И будет достаточно вызвать другую функцию, назовем ее 'request', чтобы отправить приказ изменить координаты на языке запросов (изменение мгновенно отражается на экране, т.к. после вызова 'printg' сообщения из движка автоматически перенаправляются в X-сервер). И эти две функции могут быть вызваны в любой программе. Это прорыв в офисных технологиях. Все ранее известные 3D-интерфейсы (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) разработаны с расчетом на некие когнитивные способности, которыми, как показывают эксперименты, средний человек на самом деле не обладает. Tрудности, связанных с использованием 3D-объектов, возникает из-за низкого качества интерфейса, а не из-за сложности трехмерной задачи. Предлагаю назвать новый интерфейс 'управляемой сценой' и вмонтировать его в стандартные операционные системы, дабы позволить пользователю наконец-то выполнить работу и сделать его более продуктивным, и как результат - более счастливым. Что касается реализации, полагаю, что: *) динамически линкуемая библиотека (например, dll-файл) в качестве такого бинарного файла (координаты хранятся внутри нее и изменяются вызовом ее функций) не подходит, т.к. скачивание ее нарушает безопасность компьютера и повторит все проблемы скачивания ActiveX *) подходят следующие варианты: o) Java-библиотека в качестве бинарного файла, содержащего координаты; и интерпретатор языка Java, получающий Java-текст так же, как интерпретатор языка SQL (т.е. СУБД) получает SQL-текст o) рудиментарное игровое или CAD приложение со встроенным языком программирования и управления 3D-объектами; и файлы, в которых это приложение сохраняет фигуры o) рудиментарная СУБД, возвращающая 3D-объекты как результат оператора 'select' и изменяющая координаты точек оператором 'update' Вариант #1 самый плохой - Java наиболее трудный язык для пользователей. Язык игровых и CAD приложений (вариант #2) промежуточен по трудности. Вариант #3 самый лучший - интервьюирование пользователей показывает, что вставка точек, треугольников оператором 'INSERT' и изменение координат точек оператором 'UPDATE' наиболее легки для них (!); а перенос данных из СУБД в СУБД - хоженый, обозримый, привычный процесс. Автор изложил вариант #3 в отдельном документе [2] и заинтересован во мнениях, комментариях и возможной реализации этих предолжений. 3D-конструкция представлена в нем как иерархия точек, треугольников, фигур (групп треугольников), групп фигур, групп групп, и т.д. Записи, содержащие эти объекты, должны быть связаны внешним ключем. Для того, чтобы извлечь все треугольники фигуры или группы, нужно оператором 'SELECT' выбрать не только запись, являющуюся данной фигурой или группой, но и все записи, расположенные ниже нее в иерархии - вплоть до тех, которые представляют 3D-точки. Для этого таблицы этих записей перечисляются через точку - 'select * from group3.group2.group1.triangle.point' - как это и принято в классических объектно-ориентированных языках [3]. Названия таблиц значения не имеют, т.к. всегда точки предполагаются расположенными на самом нижнем уровне иерархии каждой ветви дерева, треугольники - на один уровень выше, а записи остальных уровней игнорируются [4]. Перед преобразованием в формат X11 невидимые треугольники будут удалены из результата запроса, а частично видимые будут обрезаны до их видимых частей. Итого любая программа отображает содержимое базы данных на экране функцией 'printg("select * from group3.group2.group1.triangle.point")'. Аналогично в операторе 'UPDATE' также можно указать всю иерархию записей от фигуры или группы до 3D-точки - 'update group3.group2.group1.triangle.point set ...'. Итого любая программа изменяет положение объекта в базе данных и на экране функцией 'requst("update group3.group2.group1.triangle.point set ...")' [5]. [1] или в формате Microsoft Window System, если движок работает в 'Microsoft Windows' [2] http://sql50.euro.ru/sql5.16.4.pdf [3] соответственно схема должна быть отделена от названия таблицы не точкой, а каким-то другим знаком, например '§': 'select * from user§group3.group2.group1.triangle.point' [4] как отсекать ненужные ветви дерева, подробно рассказано на страницах 118, 124, 127-129, 132-143 pdf-документа [5] процедуры сдвига, растяжения и вращения предлагаю поставлять не как хранимые в базе данных, а как встроенные в SQL, например сдвиг на 5 единиц по каждой координате выглядел бы как 'update group3.group2.group1.triangle.point shift (5,5,5)' - подробно о новых операторах 'update' и о триггерах для них рассказано на страницах 14, 68-69 pdf-документа. Эти же триггеры могут быть вызваны мышью, т.е. посылкой X11 данных, о чем рассказано на страницах 71-75 Тюрин Дмитрий
pgsql-ru-general by date: