New step in office technologies: Driven scene

Progress in office technologies stopped and it has occurred because user, capable to write primitive programs, cannot:

• display 3-dimensional data in window of own program
• move 3-dimensional objects by commands in a foreign program (in such as 'Microsoft Office'), and see changes on display

Objects can be drawn by mouse independently, downloaded from internet, obtained as a result of calculations, or as output from hardware. In any case, there is a need for:

• binary format for file, which contains 3D-objects, moreover objects must be written as triangles (which are understandable for users) instead of languages 3DMLW, 3DXML, COLLADA, because user does not master formulating and considering of own problems on these languages
• engine inside operating system, which:
• allows to load into self these binary files
• return objects in format X11 [1] at query of them, that program, addressed to this engine, could send obtained data to the X-server without any own calculations or changes (without referencing to OpenGL, DirectX, which user never will masters!!)
• supplies two ways to change the coordinates of objects (both ways create commands in format X11 to control X-Server, which are immediately forwarded to the X-server):
• by query language (that allow a program to change coordinates)
• accepting events in format X11 [1], which are also commands to change coordinates, but are send by mouse (that allows to change coordinates by mouse)

It will be enough for user to call one function, we shall name it as 'printg', in which user specify what 3D-objects from database must appear on a screen. This function being called first time, automatically forwards all mouse motion commands of objects and motion of camera into DBMS; all messages about updating coordinates of objects, obtained from DBMS, automatically forwarded into Window System. It will possible to apply the same function to send order to change coordinates on query language (change immediately is displayed on screen). And this function can be called on any programming language.

This is breakthrough in office technology. All earlier known 3D-interfaces (3DMLW, 3DXML, COLLADA / OpenGL, DirectX) are designed with target of some cognitive abilities, which as experiments show, average person cannot accomplish. Difficulties related to the usage of 3D-objects appear because of inferior quantity of interface, instead of difficulty of three-dimensional task. I propose to name new interface as 'Driven Scene' and add it into common operating systems to allow users finally drive its own work (including data manipulation), which should make user more productive and as result more happy.

What's about implementation, I suppose, that:

• dynamic linked library (e.g. dll-file) as this binary file (coordinates are saved inside it and are changed by calling functions of library) is not suitable, because downloading it breaks security of computer, and will repeats all troubles of downloading ActiveX
• the following variants are suitable:
• Java-library as binary file, containing coordinates; and interpreter of language Java, getting Java-text like interpreter of language SQL (i.e. DBMS) getting SQL-text
• rudimentary CAD application or game application with build-in language of programming and control of 3D-objects; and files, in which this application saves figures
• rudimentary DBMS engine, returning 3D-objects as result of operator 'select' and changing coordinates of points by operator 'update'

Case #1 is the worst - Java is the most difficult language for users. Language of game or CAD applications (case #2) is intermediate on difficulties. Case #3 is the best - interviewing of users shows that insertion of points, triangles by operator 'INSERT' and change of coordinates of points by operator 'UPDATE' are the most easy for them (!); and movement of data from DBMS to DBMS is routine, common process.

More detailed description for case #3 is presented in pdf-document (p.209-271). 3D-construction is presented in it as hierarchy of points, triangles, figures (groups of triangles), groups of figures, groups of groups, etc. Record, containing these objects, must be bound by foreign key. To extract all triangles of a figure or a group, it's necessary to select by operator 'SELECT' not only record, being this figure or group, but also all records, located below it in hierarchy - up to records, which present 3D-points. For this, tables of these records are listed through point - 'select * from group3.group2.group1.triangle.point' - as this is accepted in classical object-oriented languages [2]. Names of tables are not important, because points are always expected to be located on the most lower level of hierarchy of each branch of tree, triangles - on one level above, and records of other levels are not visualized [3]. Before transformation into format X11, invisible triangles will be removed from result of query, and partly visible triangles will be cut to their visible parts. So any program displays contents of a database on screen by function 'printg("select * from group3.group2.group1.triangle.point")'.

Similarly it's also possible to specify whole hierarchy of records from figure or group to 3D-points in operator 'UPDATE' - 'update group3.group2.group1.triangle.point set ...'. So any program changes position of an object in database and on screen by function 'printg("update group3.group2.group1.triangle.point set ...")' [4].

[1] or in format of Microsoft Window System, if engine works in 'Microsoft Windows'

[2] accordingly scheme must be separated from table name not by point, but by some other sign, for example '�': 'select * from user�group3.group2.group1.triangle.point'

[3] how to cut unnecessary branch of a tree, it's described in detail on p.12-16, 21-22, 34-46, 53-55, 58-68 pdf-document

[4] i propose to supply procedures of shift, sprain, and rotation not as stored in database, but as built-in in SQL, for example shift on 5 units on each coordinate would look as 'update group3.group2.group1.triangle.point shift (5,5,5)' - it's stated in detail about new operators 'update' and about triggers for them on p.218, 232-233 of pdf-document. The same triggers can be called by mouse, i.e. by sending X11 data, about what it's told on p.235

References:

P.Scarponcini. SQL Multimedia and Application Packages - Part 3: Spatial. Bentley Transportation, 2000-03-26. http://www.wiscorp.com/sqlspat.zip

Dima Turin, dmitryturin@yandex.ru