Aalborg University Copenhagen Medialogy Cand. Sc.
Abstract / synopsis The system architecture described in this report, is an integral part of an event, where a two-week light-show is envisioned, with multiple light projectors being placed around the chimney of a power plant. The central idea in this event is that the programming of this light show, is made by pupils of participating secondaryeducation schools in the neighboring area, in the months preceding this two-week event.
Table of Contents 1 Introduction 1 2 Initial considerations and analysis 3 Related work 4 10 4 Development work phases and report structure 5 General application model 13 15 6 Initial prototype 17 7 Initial prototype evaluation and platform choice 20 8 Version development overview 22 9 Database and user set-up and administration 25 9.1 Usage phases and user set-up 9.2 Database set-up 9.3 Administrator site walkthrough 9.
Appendix A. Appendix B.
1 Introduction The system described in this report, is an integral part of an event, entitled "Fra Damp til Digital" [40], where a two-week light-show is envisioned, with 60 light projectors being placed around the chimney of a power plant, located at the harbor in Randers.
Figure 2. Images of the area surrounding the tower in Randers Each class from participating schools will be allocated 15 minutes for which to provide a light programming.
The two-week light show event, “Fra Damp til Digital”, is a part of a greater celebration event set to celebrate the 100 years of electrification of Randers Kommune in Denmark.
2 Initial considerations and analysis Within the initial discussions while approaching the problem of the web interface, several issues immediately proved themselves important. As first, management of the light show, and other administrative tasks related to the setup of classes and their light programs on the event days, should have already been accounted for in the system, before the pupils start logging into the system and making their light programs.
which it might be programmed, the specifics of the possibilities of the projectors cannot be ignored, and must be accounted for – as eventually, what is demanded from such a 3D interface is a realistic representation of the designed light show, as it would unfold in reality. This demands that the modelling of the environment is taken into account, and the realisation that in essence there are two parameters of the modelling: 1. Realistic 3D modelling of the environment 2.
Figure 4. Image illustrating replacement of gobo wheels in a projector, illustrating their placement in it (Martin Mac 2000 spot projector user manual, from Ref.[1] ) Certain projectors also allow for rotation of individual gobos, and mixing of patterns from gobos placed on several wheels - and the possibility of controlling all this via DMX is there as well.
real-time, with information about individual rotating gobo patterns – with a decent level of realistic approximation, yet without choking the 3D engine, which still has to be able to run as a part (meaning with the limitations) of a web interface.
implemented in audio and video sequencing software, where visualisation of cues in relation to time is a standard problem; however, it cannot be expected that pupils of the target group age would, on a general basis, have experience with sequencing software, whether audio or video (although some of them might).
7. 8. 9. Design of a cue programming engine and interface, integrated with both the rendering preview and the database storage – and eventually producing data that can serve as a master for the actual light show. Design of the previous points (5-7) considering that the end target group is teenagers, which will use the interface as a part of a school activity, for a limited and brief amount of time. Integration of the development product with the rest of the web site structure, related to the event.
3 Related work This project is in many respects unique – hence finding related work to use as a reference was difficult.
Networked Intelligent Collaborative System [35]” aiming towards “transparent communication between participants to make them feel that they are meeting in the same place despite their physical locations [35]”.
the issues about technological deployment, which becomes almost critical in the context of multi-user consumption – and deployment is usually not a topic of discussion in similar research. In addition, one needs to consider that once a class gets allocated a 15 minute timeslot, a problem arises of how to distribute that slot between student groups within the class, yet at the same time allow student groups to visualise how their particular part relates to the entire programmed show.
4 Development work phases and report structure It is obvious that answering the demands that arise from the initial considerations is a complex task; and it can be hardly expected that all functions can be performed using a single interface. Hence, it was determined early on, that the solution should include two separate interfaces, an administration interface and a user interface, catering to the needs of four general groups of users of the system: administrators, teachers, student groups and guests.
1. Database and user set up and administration 2. Development of a cue programming and playback (sequencing) engine, integrated both with a real-time display of a 3D world and the abovementioned database. In addition, the focus on targeting pupils acts as a constant constraint, slightly more special than the other technical details. Thus, this report will introduce the general model of the system and the initial prototype.
5 General application model As mentioned before, it was determined early on, that the solution should include two separate interfaces, an administration interface and a user interface, catering to the needs of four general groups of users of the system: administrators, teachers, student groups and guests. Both interfaces would call on the same central database, located on the remote server, for user authorisation and personalised data retrieval, as rendered on the figure below: Figure 5.
rendered by a server side script is a standard practise. The user site is the 3D web interface, intended primarily for use by the pupils, and it is here where delivery of 3D content on the web, and the technical details of implementing a cue-programming engine, are of essence. The implementation of this general model will be discussed in more detail in the corresponding section, “Database and user set up and administration” – as it is mostly concerned with the back-end perspective.
6 Initial prototype Due to the specific differences between the functionality of the administration and user web interface, different technological implementation, and the need to eventually move the application between servers, early in the development it became of importance that both applications are written in that way, so that all corresponding files can be put into a folder, and all links would be relative to the root of that folder.
This initial prototype featured a non-functional login page, after which, as can be seen, it is a simple HTML based website for table administration. It was written in ASP .NET C#, connecting to a Microsoft Access database. It was the first attempt to provide some sort of a way to administer users, and correspondingly, information in the database. Mostly, it built on ASP .NET components like DataGrid to provide display of database tables as HTML tables.
The user site prototype was accessible through a single HTML page, as it was programmed as a Macromedia Director movie file – all additional branching in the application is achieved internally. In essence, it consisted of three parts, two of which are presented in Figure 8: Login screen, walkthrough (or help screen – not on the figure) and main screen, where the 3D is rendered.
using already provided spot light models, and using the built in rendering capability of, in this case, Director. In that sense, while a projector was selected, the user could click on the colour icons of the graphic interface, and the child light colour of the projector would be changed, which was indicated on the reflection as well. Hence, this was also a demonstration of the connection between the 2D interface and 3D output, which is necessary as part of the interaction design.
display, paging and indexing of database data, as well as components that deal with time formatting and display, which is of essence in the administration interface. The user site presented a different set of problems. In essence, it demanded an evaluation of the 3D engine.
However, the benefits of Virtools far outweigh Director – Virtools is targeted towards 3D (even game development for Xbox), can be trusted with the web plugin at least for Internet Explorer on Windows, and plugin installation initiates automatically.
The development initially started on the administration site, which was developed in two major versions (an additional, minor redesign was performed later on). Afterwards, work begun on the user site versions using models of a world provided in Virtools, in parallel with work on the environment modelling. Version 11 supported saving and loading of a light program sequence to hard disk, and version 12 did the same with the remote database.
VIII IV XIII XIV XVIII XV Figure 9. Screenshots of several different versions of the user site prototype. The roman numerals indicate version numbers.
9 Database and user set-up and administration 9.1 Usage phases and user set-up As illustrated on Figure 6. The general model of the web application, with illustration of user access rights”, there are four groups of users that the system recognizes. This is due to the highly specific roles that these users perform, at distinct times of usage of the system. The following time chart might help us visualise the main phases of usage of the system: Figure 10.
addition, they keep in contact with the teachers, as official representatives of participating schools, passing on information about the system if necessary. This is the administration set-up phase, mentioned above in the time chart, which obviously must be conducted before any actual users can log into the system.
• Student [groups] – Each student account refers actually to a student group which has a definite group slot within the allocated 15 minutes for that class; in the extreme case, a teacher may choose to give an account to each individual student (hence the reference to both terms). The student account, as it should, is only recognized by the user site - the students should not even be aware of the administration site.
database, into DMX compatible data, so that they can be used as actual sources of the event show.
9.2 Database set-up From the discussion so far, it can be concluded that although there are four main user groups, since the guest account can be handled with a single hard-coded login/password combination, the database has to consider only the first three classes of users: administrators, teachers and student groups.
The administrator table has id column, which simply serves as a primary key, and login and password fields as all other tables. Actually, the fields of the administrator table can be seen as the bare minimum that is also included in the other two tables in the database. The name field is only used to personalise the display in the administration site, and the email field is used in the email facilities of the administration site.
task of the administrator identity is to manage information stored in this table (as well as its own, administrator table). The current format of the student [group] table UL3 is: Figure 13. Format of the UL3 (student/group) table (screenshot from phpMyAdmin) Again, all the fields from the UL1 table are here too.
SQL sentences and troubleshooting while coding the database interaction. Finally, it works, and so far no database related problems were identified in the prototype testing process.
9.3 Administrator site walkthrough The administrator site, in its current version is programmed as an ASP .NET application in C#, with a code-behind DLL (usually placed in a /bin folder at the server). The corresponding active server pages and other files are grouped into a folder, which for the current version is AdminSite02.
For the administrator version, this is the initial screen displayed: Figure 15. Initial administrator screen (help tab) In both versions, after login, the user is displayed with a horizontal tab strip menu, containing clickable buttons that link to each section of the site for the given type of user, and the first choice on the menu, as well as the first displayed screen is the help screen, containing basic instructions. The administrator user has 5 choices in the administration site: 1. 2. 3. 4. 5.
The regular view at a table through this interface looks like this: Figure 16. A regular view at the administrators table An entry can be edited by clicking the corresponding button on the left – the view changes, and the user can enter new data and update, cancel, or delete the entry: Figure 17. An edit expanded view of a row Finally, a row can be added by expanding the menu by clicking the button on the bottom – a view is shown where data can be entered, and added to the table: Figure 18.
The third choice, Event Calendar, presents a slightly different view at the entries in the teacher [class] table – using the Calendar ASP .NET user control , the administrator can choose a date, and obtain an overview of entries scheduled for that date, ordered by starting times – so in that sense, it can facilitate easier administration of scheduling light programmes for the event: Figure 19.
The Send Email screen is meant to facilitate easier communication between the user groups – especially between teachers and administrators, in case of needs for problem troubleshooting. It is a simple field that allows, for administrators, sending of a message either to all administrators, or to all teachers, by using the e-mail information stored in the e-mail column of the respective table. For the teacher version, this is the initial screen displayed: Figure 21.
Let’s remember that the teacher is in this case delegated to set up the groups in her own class – hence, at first login, there would be no groups whatsoever. This is indicated in both Class-set up and Edit class views: Figure 22.
From this point on, the teacher can enter login and password information for his student groups, and once that is set up, the student groups are ready to log into the user system. As such, as the login password information comes from different sources, it is critical to implement a check for unique login/password combination for each student group involved. The Edit class screen also allows the teacher to control whether a given group has entered any light program cues in their allocated time slot.
the point where the user log off is defined. This is actually handled quite easily by placing a log-off button. The problem is however, that most computer users, after they are done with a login based application, almost never click on “log-off” buttons for that purpose; instead, almost always they choose to close the web browser altogether, (by clicking, in most browsers, the X button in the corner of the title bar). Occasionally, a different address may be entered into the address bar as well.
The current version of the administration site raises the is_online flag for the respective user upon successful login. When the user is done, she is expected to click on the log-off button, which loads a page, that reads through the session variables, finds the user ID, and resets it’s is_online flag back to zero. For the case when this doesn’t happen, and the user chooses to simply close, another attempt was undertaken.
Certainly, instructed users will give permission to the popup window, but this is not yet the end of the story. Once the user closes the main browser window, the child listener must initiate a request to the server, meaning it must load a page(in particular, the page resetting the is_online flag) somewhere – and in the current version, it tries to open yet another pop-up, and as soon as it’s done, a dialog box is displayed, which when clicked closes both pop-ups.
At the present time, this problematic behaviour with the pop-ups is the only serious issue with the administration site – as often accounts are left with “hanging” is_online flags set to 1, preventing future logins, which demands a reset of these switches directly from the database. That is why a similar check for unique logged user is not yet attempted for the user site.
10 3D user interface development With the user and database set-up in place, it is easier to commence the work on the 3D user interface. Considering the previous discussion, there are three main points to consider about the 3D interface: - Distribution and deployment of the software over the Internet, as hassle-free as possible, since the primary end-users are pupils. - Modelling in 3D, realistic to a certain degree, of a given environment.
This software package is actually free for download, however, keep in mind that this is an application aimed at users of the GrandMA console, as closer inspection at the complete user interface reveals: Figure 29. A closer look at GrandMA 3D and GrandMA Offline (Ref.
Thus, in spite of the impressive hardware interfacing capabilities, GrandMA 3D serves only as an inspiration in relation to the degree of accuracy that is expected of the 3D part of modelling of a light show. The possibility of rendering gobos is there, and the light cones a projector creates are visible as well, maybe even exaggerated (though this might be seen as a tool to assist the light designer while working).
Figure 31. The sequencer related GUI of Adobe Premiere Figure 32. The sequencer related GUI of Macromedia Flash One general conclusion for these interfaces is, besides having common points like organisation in tracks, player controls, graphic event indication and a current player time marker, they also contain vast amounts of visual information; as such this can certainly work overwhelming on the target group, and a simpler implementation of a similar GUI is needed.
Figure 33. The sequencer related GUI of BluffTitler The GUI of BluffTitler is much simpler – rendering each event (here called key) simply as a vertical line; no track information is displayed. In that sense it is much easier to use, as there is essentially not much of a visual language to learn.
Some of these projectors have rotating gobos and some do not; some actually are intended for placement where no light cone is visible either. This must be taken account for in the application. This projector specification also helped to determine the number of parameters that should be taken into account in the cue programming engine. In its current state, the cue engine in the user site prototype supports the following parameters of a projector: colour, intensity (dimmer), gobo and gobo rotation speed.
user collaborative environment, similar to the massive multiplayer online games, would demand a network loop to be threaded with the needed frame rendering and player timing loop; and this could be a rather difficult task that might eventually take its toll on the rest of the application performance.
10.1 Interaction and graphic user interface The key features of the interaction and graphic user interface will be presented through a short walkthrough, illustrated by screenshots based on the latest version, BrugerSite20A, which contains projector models, positioned accordingly to the light design. Upon loading of the page, the Virtools plugin checks for player version, and auto-updates accordingly. With the proper Virtools plugin in place, the compiled Virtools player file (.
Figure 34 shows the login screen, with login and password fields (1), a login button (2) and a server response text field (3). When presented with this screen, the user is expected to enter a login and password combination, and press on the login button. This initiates a request for login authorisation to the server, and the stages of this process (as it is asynchronous, and the exact time of server response is unknown), are followed through the server response field.
The init phase spawns and sets up the projectors within the world, spawns their light cones, calculates which surfaces are to render a projector light and parses the loaded light program if any. At the same time, the rest of the user interface is initialised as well. That is why this init phase can last up to several minutes, even on newer Pentiums. During the init phase, the interface engine does not work in full, and one has to wait for this phase to finish before using the application.
The state presented on Figure 36 renders almost all main elements of the graphic user interface (but one, discussed later), which are: 1) Personalized title texts: information about i. Name, school and class, and the title “Skorstenshow” (1a) ii.
different resolutions to be chosen for the full screen display – which presents a special problem for the chosen graphic interface. The different user classes are mostly distinguished by the personalized title texts, and features mostly related to the timeline. For instance, the guest account is not connected to a database program at all, and that is reflected by a non-separated, blue group timeline: Figure 37.
This is to indicate that the teacher has the permission to edit cues throughout the entire class allocated timeslot. In contrast, the student group timeline, after init looks slightly different: Figure 40. The timeline of a student account That is, only the time slot belonging to the group is shown as bright, indicating that the user has the permission to edit cues only there – the slots belonging to other slots are rendered with a dark shade.
When the navigation panel is expanded, it indicates the current navigation mode, which first and foremost relates to the usage of keyboard keys. The navigation mode can be changed either by clicking the orbit or pilot button on the panel, or by clicking the N button on the keyboards (switches from one to the other). The zoom in/out buttons on the left of the panel, and the orbit buttons to the right, are linked to the corresponding key functions of the orbit navigation mode.
The left panel can be accessed by clicking the left panel tab: Figure 42. Collapsed (left) and expanded (right) state of the left panel The bottom part of this panel has a camera section. By clicking one of the position buttons, the camera will be instantly placed at one of the three locations, where the cameras/webcams recording the event will be placed. In addition to this, three fly-by tours are available, built upon three different 3D Curves in Virtools, and usage of the Curve Follow BB in Virtools.
10.1.2 Projector selection and edit As discussed previously, the base action for inserting a cue was taken to be: click on a projector to select it, and click on a 2D interface to change a parameter. Thus, selection of a projector by clicking is the primary means of projector interaction accounted for in this version of the user site. It chiefly relies on the 2D Picking BB in Virtools to determine whether the mouse pointer of the user is hovered over a projector.
The right panel has not been introduced so far, since after the init phase, there is no projector selection by default (the appearance of the selectors around the projectors during the init phase is due to an initial reset loop; each projector must be selected and deselected once by the application for the engine to work properly. Note that sometimes the application “forgets” to deselect the projectors after the init phase – nothing an empty click won’t solve).
As soon as a selection is made, the user can read out the current value of the parameters of the selection (if they are equal) on the right panel. Afterwards, by making any change in the right panel, the user either inserts a cue, if none is present at the current time location; or modifies an existing cue – the display on the timeline after such an action is updated accordingly. Let’s also mention that the right panel also functions as a tab, and can be permanently collapsed: 1 3 2 4 6 5 Figure 45.
The four parameters that can be edited for a projector are regulated through their corresponding areas. The gobo selection area (2) features all gobos available for the show as clickable buttons. The first button (in the upper left corner) is used when no gobo is applied to the projector. A red outline shows the gobo of a selected projector (or multiple projectors, if they all have the same gobo) at a given moment in player time.
For a single projector selection, if the player time is on a cue that also includes the selected projector, the 1D cursors are bright, and a cross is used as the color 2D slider cursor. If the player time is not on a cue, then the values of the projector shown in the world and in the right panel are interpolated; hence X is used as a 2D slider indicator, and the 1D slider indicators become transparent.
There is one more aspect to be considered - the projectors are placed at different “geographic” locations in the world, and sometimes a certain amount of “driving” is needed until a view that allows selection of the needed projectors appears.
10.1.3 Player time / cue selection and edit The part of the interaction interface that deals with cue sequencing, selection, and editing, as well as the control of player time, is the aforementioned timeline. Let’s take a more detailed look at the timeline: s1 t t t 1 2 3 4 5 6 7 8 9 10 11 12 13 14 s2 15 16 17 18 Figure 48. A view of the timeline with all buttons shown In the above image, the “t” symbol refers to a current player time marker.
interaction allowed with cues. It was found that such a solution with “free” zoom may confuse the users of that age – hence this solution (implemented after the major redesign) includes both an overview of the entire class-allocated timeslot (through the group timeline) and a fixed zoom view, large enough so the quantization steps are visible, and implementing button interaction on the events makes sense.
• Group zoom level functions These functions are related to time slot displayed on the group timeline. The total zoom button sets the display to the entire class 15-minute timeslot: Figure 49. Total zoom displayed on the group timaline The numbers in red indicate the time positions of the bounds of the group timeline, relative to the start of the class timeslot. Hence, for a total zoom, they always display “0:00” for the start and “15:00” for the end.
• Player time control functions These represent one of the key functions in the application. It should be mentioned that all of these functions actually trigger the main player function – which simply calculates a new time moment (relative to the beginning of the class time slot) to be the current player time.
- - - - Fast backward [7], fast forward [11] – adds or removes a second from the current player time as long as these buttons are held – simulating a fast forward/backward (auto-quantizes) Previous cue [8], next cue [10] – sets the new current time to the position of the previous or next cue, relative to the ‘old’ current player time (auto-quantizes) Play [9] – initiates a timer function, and a continuous looping reexecution of the time calculation and the update functions that result with a new frame r
rotating, based on the cue data for that particular player time. This is a great visual aid to light designers, and as such is reproduced in PC software dealing with light programming as well – and so it should be implemented in this user interface too. That simply means, that the control of the gobo rotation should be removed from the main time based update loop, and should be made independent, referring only to the rotation speed cue data for that instance in time for a given project.
within the limits of their group slot – the teacher has access to the entire class timeline. When a multiple selection of cues is made, the user can choose one as reference, and while still holding shift, click on the reference cue and drag it along the detail timeline – this will initiate movement (displacement) of all the cues in the selection upon release: Figure 54.
operation, however within own group bounds only – meaning that, if a position of a pasted cue happens to overlap with already existing cue, the existing cue is deleted and replaced by the pasted one. Again, this can happen only within the group bounds of the account – the pasting operation stops as soon as the group bounds are overrun, that is, the pasted cues get truncated at the bounds of the group.
The load operation triggered by the load button [17] always refers to loading a program from hard disk. In that sense, it triggers the familiar OS-based file dialog: Figure 55.
The save button command opens a dialog box, which offers the options of saving to a database or saving to hard disk for teacher or student group accounts – the guest account has only access to save to hard disk. Figure 56.
Otherwise, the file saving possibility on hard disk comes from the capability of Virtools to save its own internal Arrays as text file – this can however occur only in temporary directories where browser applets have access on the local computer. A reasonably complex algorithm parses all of the cues on a light program down to a single string, which then is saved as a text file.
three separate materials for the released, pressed and hovered state. This behaviour block has been implemented at several spots in the application. However, all of the sliders are custom programmed using Virtools BBs and the scripting language VSL, so as to achieve that the slider marker (head) gets positioned where the user clicks on the slider – instead of having dragging functionality (in which user has to hover the marker first, click, hold, drag and release).
some distance from the viewpoint … MIP-mapping helps alleviate this problem. [26].
pixel contents from the padded image into the host rectangle, by manipulating the texture u/v coordinates for that rectangle. Figure 57. Texture Mapping: Texture Coordinates Interpolation (Ref.[24]) Fortunately, Virtools allows direct manual editing of the UV (texture) mapping for a 2D Frame - which is an internal Virtools data structure, representing a rectangle expressed in the coordinate system of the screen (not the 3D world).
The final issue related to the 2D interface aspect is a problem, which in one or another way is always present in web design, and that is layout appearance at different screen resolutions. In the 3D context, it is essential to repeat the concept of a view vindow, or a viewport: “A viewport is the actual 2D window that the 3D world is shown within[30]” Figure 59. Illustration of a camera frustrum and a viewport (Ref.
Virtools offers so-called “stick” parameters, to help alleviate such problems – the erroneous behavior might be alleviated by having the elements stick to all corners of the viewport, in which case they would be scaled. However, stick scaling is relative to the viewport size in the Virtools development environment (which is often changed manually during development work), so it is hard to set up their sizes manually.
indicates – and was certainly one of the development hotspots that were least expected in this project.
10.2 Projector lights modelling A key problem in the user site application is modelling the visual appearance of light projectors and their lights, to achieve a realistic 3D preview of the light design. There are two major issues in respect to this. First, the lights should eventually render a light cone, and a reflection of a gobo pattern on the affected environment models; this is the projector light simulation issue. As this is not a standard feature on GPU’s, a corresponding algorithm must be devised.
their light cones (hereafter called site spawning process), which directly addresses the light placement design issue – within this code, measures have to be taken to properly initialise the projector light simulation as well. Thus, this algorithm (hereafter called projector setup process), which composes most of the init phase of the user site (mentioned first at the beginning of the chapter), must address both the light design (site spawning) and (to a certain degree) projector simulation issues.
As visible on Figure 61, the spot light accurately models a projector, in all respects apart from the rendering of a gobo pattern. However, there is one more problem: “Light Properties are also used in the Light calculation ... from this table, a Spot light requires the most calculations ... Lighting calculation is done for each vertex of the scene and for each light ... Warning: The maximum number of active lights is limited when using a video card that support Transform and Lighting (T&L).
A possibility is to target one earlier generation of graphic cards, those that support multitexturing (feature from 1998, [24]), as multitexturing allows for hardware accelerated calculation of light maps. However, for rotating gobos, that would mean continuous redraw of the light map texture, which is an operation impossible to achieve without going down to the Virtools SDK level and coding custom DLLs for texture drawing, which increases the licensing fees.
your target platform. [31] (Texture (CKTexture))”. In addition, a Mesh itself can have several so-called Material Channels: “A Mesh can have up to 8 additional Material Channels. A Channel is a Material that is blended with the main Material or other Channels. Each Channel is associated with one Material for the faces, and one set of Texture coordinates.
is the only one (in that example) that has light materials applied as channels to its Mesh – one for rendering each gobo pattern respectively. Each light material refers to its own gobo texture (in this case they are both the same) and has individual color information. In addition, each light material has the TexGen-with-referential effect applied, where each material refers to its own projector.
utilising hardware acceleration of the GPU is a necessity for a custom texture drawing of gobos). In this case, as well as when using a spot light model, there are no visible light cones “in the air” coming out from the projectors – only the light effects are rendered on the mesh materials.
Functions defined through States, that modify object's texture coordinates according to certain State values. Pseudo environment mapping, chrome effect or planar mapping can be achieved with TexGens [31] (Shaders Glossary)”. The term fixed-functions stands for “Hard coded rendering algorithms used by GPU on 3D graphics cards.
10.2.2 Projector setup process The role of the projector setup process in the init phase of the user site, can be briefly summarised like this: - To dynamically create (spawn) the projector models and light cone objects, based on information in the environment model and an external text file.
Figure 66.The expected hierarchy of objects: at the root of the scene (left), expanded view at the master node for the world objects (middle), expanded view at the master projector models node Figure 66 shows several views at the expected hierarchy of objects. There are only few children of the root node of the scene, among them Randers World (Center Aim) which acts as the single parent of all the objects composing the world. Besides this child node, two others are special to the system.
Besides the Projectors Parent, the master light cone object, the master selector object and the main camera reside in the root of the 3D scene, and are important to the projector setup itself; otherwise, 3D frames for the camera positions, the master target of the chimney tower and the curves for the fly-by tours also reside in the root. The construction of a projector container model is again specific.
So, in more detail, the projector setup algorithm looks like this. First the applications looks for all Projectors_ and enumerates them in an array (Projectors). Then it reads the Projector.stp file, and concatenates its values to the previously created Projectors array (the number of rows and the projector names in the Projector.stp MUST match the projector containers in the model).
According to Figure 69, the unknown side h is: ( 2) h = d tan α Eq 10-1 It’s a little more difficult to apply that data to the scaling of the light cone, as the original dimensions of the master cone need to be taken into account first. In any case, this is the core of the spawning process. The benefits of such organisation are in the fact that minimal number of 3D data is stored, as the projectors and the cones are spawned (although they probably would not contribute too much to file size anyway).
cone once it is available. This was one of the most problematic tasks to approach. In essence, some type of a test is needed to determine which surface is lit (and get an additional light material channel) and which one isn’t; this type of test needs to be conducted for each individual projector/light cone. The first measure to take here is to limit the number of objects that can be lit.
Figure 70. Dependence of the ray-tracing algorithm (based on cone tessellating) on the sampling resolution An additional difficulty in the ray casting algorithm, is that what we need is to cast a ray, and get the first object intersected by it – this is achievable in Virtools only through the Ray Intersection BB (as a graphical block).
Figure 71. The results of the current version of the ray intersection testing The effects of the current version of the light testing algorithm can be seen on Figure 71, where it is also visible that there is a quite sharp cut-off between surfaces that passed the test and those that didn’t – but apart from that, the approximation is reasonable enough to allow visualisation of the eventual results in the real world.
10.3 General overview of the Virtools user site engine The Virtools composition is organised in two Virtools Scenes – Login Scene and World Scene. There is only one Level based script, which loads the Login Scene; all other scripts are children of their respective scenes, and work only when the Scenes are active (the same is valid for any 2D/3D objects assigned to a Scene). Upon start of the Login Scene, the two external text files are read – dansk.
With this, the init phase is finished, and the application enters a state of constant listening to user input via keyboard and mouse listeners; this is the main process loop of the application. Accordingly to user input, the camera is manipulated, projector selection is checked, clicks on right panel (which modify a projector state, and modify/insert a cue) are processed, and clicks on the timeline – both cue manipulation and player buttons – are processed.
The numerated blocks on Figure 72 delimit the main function blocks: 1. 2. 3. 4. Init phase scripts Player listener (listener to player controls, like play, rewind, etc) Other listeners (save/load; cue functions – click, copy etc; zoom clicks) TimePlayerSequencer – the script that calculates the next player moment (+ some additional functions) 5.
The key in this organisation is the Projectors array – any actions on the user interface that change a projector parameter, change it in the Projector array. Similarly, when a cue is interpolated, the values are applied to the projector entry in Projectors array. Finally, when a redraw is needed, whether in the 3D world or on the 2D interface, the Projector array serves as the source of information about the current projector values.
11 Conclusion and perspectives The online system, whose architecture is presented in this document, answers the initial demands, which is to provide an online client that facilitates programming of a light show by groups of students in a 3D environment. The programming of lights by the students should be conducted within a limited time window, and the results of the programming should be stored in a central location.
possible delivery technologies. Virtools is chosen, is spite of the huge price tag, as a 3D API that is more specifically related to issues in 3D applications, and as such offers greater assurance in development.
and keyboard based, first-person camera navigation, as implemented in the prototype, bear a more direct resemblance to a game). In retrospect, the application outlined in this document bears many specifics, so related projects are difficult to identify – indeed, it may be the first of its kind as an idea. Many of those specifics come from the fact that this is an application based on and around light programming, which in particular is coupled with an actual real light show.
Appendix Appendix A.
Appendix B. Client-server communication chart Figure 73. Chart of the communication process, and stages in the user site – the client side (the Virtools program) is on the left, the server side on the right; time axis points downwards. The CPU-GPU communication chart from Ref. [24] is placed at the main process loop, to stress the mportance of the GPU in this stage.
List of references [1]. Martin, User manual, MAC 2000 Profile II (Rev. M), http://martin.com/service/downloadfile.asp?name=UM_MAC2000ProfileII_EN_M. pdf&cat=65 [2]. DevX.com Forums Access memo field 64k limit..., http://forums.devx.com/showthread.php?t=51283 [3]. MySQL AB :: MySQL Connector/ODBC 3.51 Downloads, http://dev.mysql.com/downloads/connector/odbc/3.51.html [4]. MySQL 5.1 Reference Manual :: 11.4.3 The BLOB and TEXT Types, http://dev.mysql.com/doc/refman/5.1/en/blob.html [5].
[17]. gMA PC software, http://www.actlighting.com/MAlighting/gmapcpresnetation.htm [18]. MA Lighting: Lighting Consoles / grandMA 3D / FAQs, http://www.malighting.com/43.0.html?&tx_lightpowerpdb_pi1[parent_gruppe]=35& tx_lightpowerpdb_pi1[produkt_id]=1862&tx_lightpowerpdb_pi1[bereich_id]=4&cH ash=00d4c58273 [19]. Music Production :: Steinberg Media Technologies GmbH, http://www.steinberg.net/27+M52087573ab0.html [20]. Adobe Premiere homepage, http://www.adobe.com/products/premiere/ [21].
[34]. Broll, W. et al, "The Virtual Round Table - a Collaborative Augmented MultiUser Environment", GMD - German National Research Center for Information Technology, Sankt Augustin, Germany [35]. Leung, W. H. et al, "A Multi-User 3-D Virtual Environment with Interactive Collaboration and Shared Whiteboard Technologies", Carnegie Mellon University [36]. MMORPG Wikipedia, the free encyclopedia , http://en.wikipedia.org/wiki/MMORPG [37]. List of MMORPGs Wikipedia, the free encyclopedia, http://en.wikipedia.
