Recommandé
Contenu connexe
Similaire à Doctor Final
Similaire à Doctor Final (20)
Dernier
Dernier (20)
Doctor Final
- 1. DOCTOR Demonstration of Online Clinics: Training, Observation and Research
- 2. The DOCTOR Staff Jon Loptien Mike Getz Michael Niland Doug Kumagai 2 Doctor - Jon Loptien
- 3. State of the Project Presentation Project Overview User Interface Design Architecture Software Demo Doctor - Jon Loptien 3
- 4. State of the Project Presentation Project Overview The Class The Problem The Solution User Interface Design Architecture Software Demo Doctor - Jon Loptien 4
- 5. The Class Computer Science Capstone 61 Students, 13 Projects Industry Projects Multi-User Cell Phone Game (QUALCOMM Inc.) Peer Distributed Transfer Protocol (ClickCaster, Inc.) Remote Icing Sensing System (NASA) Doctor - Jon Loptien 5
- 6. The Problem Too Many Programs Blackboard Adobe Connect Email Necessary Proctor Intervention No Interaction Between Students No physical interactions Limited to voice and text communication Doctor - Jon Loptien 6
- 7. The Solution - DOCTOR Uses of DOCTOR Requirements of DOCTOR Environmental Functional Conceptual View of DOCTOR Doctor - Jon Loptien 7
- 8. Solution - DOCTOR Online Virtual World Second Life Virtual office building PowerPoint Support Text Chat Support Third-Person Interaction Avatars provide virtual self Voice emanates from avatar Doctor - Jon Loptien 8
- 9. Environment Requirements Software Environment Second Life Linden Scripting Language (LSL) Hardware Environment Determined by Linden Labs Mid-range computers Headset for voice communication Doctor - Jon Loptien 9
- 10. Second Life Client Viewer Similar to web browser Supports wide range of computer hardware Server Storage All information is in the “cloud” Rendering done on server Doctor - Jon Loptien 10
- 11. Functional Requirements Single Program Conference Room Project presentations Examination Room Virtual “look and feel” Offices Student and proctor meetings Doctor - Jon Loptien 11
- 12. Conceptual View of DOCTOR Doctor - Jon Loptien 12
- 13. State of the Project Presentation Project Overview User Interface Design Architecture Software Demo Doctor - Jon Loptien 13
- 14. State of the Project Presentation Project Overview User Interface Design Second Life DOCTOR Architecture Software Demo Doctor - Mike Getz 14
- 15. Second Life Interface Doctor - Mike Getz 15
- 16. Second Life Action Menu Objects Can Have Actions Provided through scripts User Can: Create object Take object Touch object Buy object Open object Doctor - Mike Getz 16
- 17. Second Life Note Interface Provides Information Object “speaks” to user Object-User Interaction Note Stored In Object User can pass notes to other users Doctor - Mike Getz 17
- 18. Second Life Communication Built-in: Voice Text Chat Email Friend List Teleport to friend Instant message Call Doctor - Mike Getz 18
- 19. Second Life Objects Interface Create And Edit Objects Change Object Properties Cost User permissions Location Texture Size Edit Land Doctor - Mike Getz 19
- 20. DOCTOR Interface Doctor - Mike Getz 20
- 21. DOCTOR Conference Room Student Project Meetings Small team meetings Multi-team meetings Ten avatars most PowerPoint Presentations Projector system Ease of use Cost effective Doctor - Mike Getz 21
- 22. DOCTOR Exam Room Realism Routine Walkthroughs Led by nurse Verbal Student Observation Non-Functional Doctor - Mike Getz 22
- 23. DOCTOR Offices Two Offices Chief Nursing Officer Information Services Student/Proctor Meetings Three avatars max Note-Taking System Doctor - Mike Getz 23
- 24. State of the Project Presentation Project Overview User Interface Design Architecture Software Demo Doctor - Mike Getz 24
- 25. State of the Project Presentation Project Overview User Interface Design Architecture Second Life objects Linden Scripting Language Classroom concerns Software Demo Doctor - Michael Niland 25
- 26. Objects - Primitives Basic shapes Square Torus Sphere Cone Cylinder Complex Objects Made of joined prims Imported from design programs Cost to upload Doctor - Michael Niland 26
- 27. Objects – Prim Limits Limited Number Of Prims Determined by land Monthly Land Use Fees Sponsor has 512 m2 Limit Cost To Sponsor Import objects Reduce prim count Doctor - Michael Niland 27
- 28. Objects - Imported Sculpted Prims Image based Grid mapped 32x32 grid Limited base geometries Doctor - Michael Niland 28
- 29. Objects - Imported Imported mapping is awkward May not render correctly Doctor - Michael Niland 29
- 30. Object - Imported Benefits Allows for complex objects Works well on small scale Detractions Does not scale well May not render correctly Difficult to texture Doctor - Michael Niland 30
- 31. Linden Scripting Language LSL, Second Life Scripting Java-like syntax Nearly complete language Runs in sandbox Attachable To Any Object Drag script into object container Provides actions to objects Easy Execution Run at touch action Run at specified event Run at specified time Doctor - Michael Niland 31
- 32. LSL – System Calls Provided Functions Get system info Get object info Get user info Change object properties Example System Calls: llGetTextureRot llGiveInventoryList llPlaySound llDetectedTouchPos Doctor - Michael Niland 32
- 33. LSL – Attach To Object Place Script In Object Objects have contents Script Auto-Starts Runs at all times Waits for action Doctor - Michael Niland 33
- 34. LSL Door Action Script default { touch_start(integer total_number) { //defines action event rotation rot = llGetLocalRot(); //define rotation variable if (rot.z == 0) { //if door is in closed position rot.z = .707107; //rotate 90 degrees rot.s = .707107; } else { //if door is open, set to closed rot.z = 0; rot.s = 1; } llSetLocalRot(rot); }} Doctor - Michael Niland 34
- 35. Classroom Concerns or “a spoonful of sugar”… Doctor - Michael Niland 35
- 36. Blackboard-Second Life Integration From a team at Ball State: Register a student’s newly acquired avatar name from within Second Life Once registered, maintain online status of each student Display the class list with avatar name, class name, and SL Online Status Provide the SLURL of the Class Provide class list information to Second Life, including BB administrator list Allow logging of discussions in second life into the BB Discussion forums Security based on validation with blackboard. Doctor - Michael Niland 36
- 37. Scheduling Minimally, students coordinate with proctors and instructors In-game scheduling: Groups have notices and proposals Notices are one-way announcements Proposals are open to voting Doctor - Michael Niland 37
- 38. Other Concerns Tutorial document – succinct but general “Learner engagement type” – collaboration, presentation, experience? User tests will reveal the average learning curve Doctor - Michael Niland 38
- 39. State of the Project Presentation Project Overview User Interface Design Architecture Software Demo Doctor - Michael Niland 39
- 40. State of the Project Presentation Project Overview User Interface Design Architecture Software Demo DOCTOR KUMC Isle Doctor - Doug Kumagai 40
- 41. Summary Project Overview The class The problem The solution User Interface Design Second Life DOCTOR Architecture Second Life objects Linden Scripting Language Software Demo DOCTOR KUMC Isle Doctor - Doug Kumagai 41
Notes de l'éditeur
- Welcome to the DOCTOR “State of the Project” Presentation.DOCTORis a software project that a team of CU students is implementing for the University of Colorado Denver College of Nursing as one of the Computer Science Department's Senior Projects.
- Before we start, I’d like to introduce the GEEK team – Mike Getz, Michael Niland, Doug Kumagai, and myself Jon Loptien.I'd also like to introduce our instructor, Bruce Sanders. He is an exceptionally cool guy.Also, before we get started, I want to make sure you feel free to interrupt us with any questions or comments at any time. The primary purpose of this presentation is to present the current state of our project and to get your feedback on it, so we want to make sure we hear from you. We'll also have time at the end of the presentation for questions as well.So, let's go ahead and get started.
- We have four topics we want to cover todayan overview of the project, which I’ll covera description of the user interface we have designed, which will be given by Mike GetzMichaelNiland will give a considerable amount of detail on the underlying software architecture that we will be usingand finally, DougKumagai will give a brief demo of the implementation as it stands today
- Most of you know a little about the project, but we thought we would spend the first few minutes giving you some background, in particulara bit about the Senior Projects classthe problem Data Whacker was faced withand the solution that was proposed
- First, the Senior Projects class.All Computer Science majors are required to complete a capstone class, typically either this Senior Project class we are in or a Senior Thesis done individually with a professor.This year we have 61students organized into 13 teams, each working on a project for an industry sponsor.A few examples of the projects being done this year includeA multi-user cell phone based game being done for QUALCOMMA peer distributed transfer protocol being done for a local startup, ClickCasterAnd finally a system to detect remote icing conditions near airports being done for NASA in ClevelandAnd, of course, our DOCTOR project isone of the projects being done this year.
- That’s some brief background on the Senior Projects class in general. Let’s now look at our project in particular.The main problem is that there are too many programs that students need to use to interact. The main programs are Blackboard, Adobe Connect, and email. Blackboard is used for submitting assignments and checking grades. Adobe Connect is probably the most utilized program because it allows students to communicate verbally and to share their computer screens and give PowerPoint presentations. Finally, the students must use email as their main method of communication.Unfortunately, a lot of the necessary programs require proctor intervention. For example, Adobe Connect requires an administrator to grant meeting attendees permission to use voice communication. This requires a proctor to always be present when students communicate and severely limits students abilities to interact with each other.Finally, since the students are enrolled from all over the country, it is not feasible for the groups to meet in a physical setting. As we said above, the students are limited to voice and text communication.Next, I am going to talk about how we propose to fix these problems with DOCTOR.
- Our solution is DOCTOR which stands for a Demonstration of Online Clinics: Training, Observation, and Research.We will now look at:How DOCTOR will be used.The environmental and functional requirements of DOCTOR.And a conceptual view of DOCTOR.
- DOCTOR will provide a virtual world built on the Second Life platform. In particular, DOCTOR will be a small office building that students will be able to visit without the need for proctors to intervene and grant permissions. DOCTOR is designed to give students the freedom of in-person interaction without physically being in the same location.A large part of DOCTOR is PowerPoint support, as student groups will need to give presentations on a regular basis. Since Second Life does not directly support PowerPoint, a strong alternative will need to be developed.Second Life allows users to communicate with either text or voice in an easy and quick manner. Text chat can either be instantaneous or a user can send a message to another user which gets delivered to the recipients’ email address.Second Life was chosen because it allows students to create a virtual character of themselves and interact as the character instead of just using voice to try to express themselves.We will talk more about Second Life in a few minutes, but now we will talk about the environmental requirements of the project.
- The environment for DOCTOR is the Second Life platform, as we’ve mentioned. Second Life provides it’s own programming language, called Linden Scripting Language, that allows us to give objects that we create actions. We’ll go into more detail later in the presentation.Because we are using the Second Life platform, we have no control over what hardware DOCTOR will run on. Linden Labs, the creators of Second Life, determine which hardware is necessary for the program to work correctly. The current minimal hardware that is necessary is a mid-range computer, which most people have. Obviously, a headset is necessary for voice communication.I’ll now talk a little bit about Second Life, since it is our entire software environment.
- The Second Life program is a simple client viewer, which is similar to a web browser. This viewer works by translating the information sent from the servers and displaying it in the proper way for the user to understand it. Because the program is just a viewer, a wide range of hardware is supported.Every aspect of Second Life is stored on servers throughout the world. In the game, the world is divided into regions of land and each region is run by it’s own server. This is useful because it means that our sponsor does not need to provide and maintain their own server for the project and it also means that all the information will be available at any time. The problem with server-side storage is that high speed internet is absolutely necessary and even still the rendering of objects will be slow compared to dedicated programs. Now I will talk about the functional requirements of DOCTOR.
- The function of DOCTOR is to provide students a meeting place to help replace the currently used programs in most of their functions. We won’t be able to completely eliminate all the programs, but we can get the most necessary components rolled into one program to make everything simpler for the students and the proctors.To allow students to give presentations, DOCTOR will need to include a conference room that has support for presentations. The conference room will need to be large enough for about 10 avatars and each avatar should be able to easily see the presentation. Students will use this conference room on a regular basis so we will need to integrate a calendar into the system to let students schedule meeting times.DOCTOR must also provide an examination room that will give students a good “look and feel” of what an examination room will be. Because of the wide range of locations of students, it is not feasible to fly each student in to see rooms that they will be working in on a regular basis so DOCTOR must provide this room to acclimate the students. Functionally, this room will be empty but the design and textures must be as good as possible.
- This diagram shows the a general overview of what we need to implement, labeled DOCTOR here.Second Life sends the information from the server to the user’s client and is displayed in DOCTOR as the different rooms we mentioned earlier. The user sends input, whether that is actions for the avatar to emulate or voice or text communication, which is then output in DOCTOR so other users can view or hear the input.
- Now that we have given you an overview of the project, Mike Getz will describe the user interface for DOCTOR.
- Thanks Jon.There are two user interfaces that DOCTOR utilizes. The first is the Second Life interface, which is designed and controlled by Linden Labs as well as a few third-party programmers. As mentioned before, the Second Life program is simply a viewer similar to a web browser and the third-party groups make slightly different viewers than the one provided by Linden Labs.The second interface is what we are designing for DOCTOR. This interface is contained in the Second Life interface and consists of the virtual objects and building. We will look closely at this interface in the next few minutes and during our software demonstration.
- The screenshot you see here is the general view of the Linden Labs viewer. It generally looks like any other program with the top consisting of the menu bar that has the general menu options and preferences. Along the bottom is the shortcut bar, which contains quick links for the most used tools in Second Life. We’ll go into detail on some of these options and the other menus you see above in a minute.Since there is quite a bit going on in the screenshot above, we will break down the Second Life user interface into the most important aspects for DOCTOR. These are: the action menu the notes interface the communication interface and the object interface
- The action menu pops up whenever a user right-clicks on an object. The menu shows the default action of the object, shown as “Sit Here” in this instance, along with a wide range of other actions. The default action can be changed by using scripts and providing the object with a specific action. For example, the presentation system for DOCTOR can be “touched” to navigate through the slides.Users can create a new object, take the selected object, touch, buy, or open the object.
- The note interface allows DOCTOR to pass information to a user without the need of another user. The note is stored in an object and can be edited by anyone with the proper permissions. Notes can provide how-to information or any other information that would be useful to a student that needs to be repeated multiple times. Notes enhance object-user interaction by giving objects a method to communicate with users. An object can store any number of notes and any user can take the note as long as they have the proper permissions.
- Second Life provides an extensive and easy to use system for communicating with other users. A user can communicate with other users via voice, text chat, or email. The voice support is implemented to make it seem like the avatar is the source of the voice, allowing for realistic conversations. A user can edit the voice options to increase or decrease the volume of their microphone to allow for clearer communication. The text chat pops up messages on the lower right of the Second Life window or in an internal window. Second Life can also send emails to the user’s registered email address, allowing communication to users when not logged in.Second Life provides a friend list, as shown in the screenshot, that allows an easy way to open communication channels with other users. Using the friends list, a user can teleport to the location of a friend, instant message, or call the user.
- The Second Life object interface is probably the most important interface for implementing DOCTOR. All items in the Second Life platform are objects and are created through this interface. The user can change any of the objects properties, such as size, cost, permissions, location, and many other properties. We’ll talk more about objects in the architecture part of the presentation.Users can also edit land that they own to create hills or flatten out for building through this interface.
- Now that we have covered the Second Life user interface, let’s look at the DOCTOR user interface.The image you see above is the general layout for the four necessary rooms that DOCTOR needs to implement. This layout will change depending on how big the rooms need to be built to accommodate everything. We’ll now cover each of the rooms and what needs to be implemented in each room.
- The conference room is designed to be a general purpose meeting room for students. The students will be leading presentations giving status updates and overviews of their projects, similar to this presentation, to small groups of no more than ten avatars. The room should look like a typical conference room, having chairs and a large table. An example Second Life conference room is shown because ours only contains a table and projector system at this point.We need to implement a presentation system that is easy to use and easy for a student to navigate through the slides. Second Life has no built-in PowerPoint support, so we need to use images of the slides, which a user can export a presentation to images directly from PowerPoint. It is a simple process to change the texture of an object to be the slide, and to navigate through textures at will. The problem with this method is there is a cost for uploading files to Second Life. This cost is minimal, but a free method would be better. We are searching for ways to use images straight from the web and how we can make the uploading as simple as possible for the students.
- The examination room is designed to provide students a “feel” of the area they will be working in when they graduate and therefore must be as realistic as possible. The students will be led through the examination room by a nurse and will be verbally walked-through the patient-nurse interactive process. The students will observe and learn from the nurse, but will not role-play as a patient.The exam room does not need to be functional, such as working cabinets or role-playing functionality. The only important feature is that the look of the exam room is as close to a real exam room as possible.
- There will be two offices built for DOCTOR, one for the Chief Nursing Officer and one for Information Services. Each of the offices should be locked so that students cannot enter without the permission of the proctor to keep some privacy for meetings.The meetings that will take place in the offices will be limited to two or three avatars, so the offices will not need to be very big. The meetings will be general meetings concerning the state of the project or any other topic that the students feel are necessary for the course.There should also be a note-taking system on the desk for the proctor or students to write down important information. This system will use the note interface that was mentioned earlier.
- Now that we have given you an overview of the user interface, Michael will talk about the architecture.
- Thanks Mike.The architecture for DOCTOR is almost entirely contained in the Second Life platform. The two important parts that we are concerned about are objects and the Linden Scripting Language. Objects are important because everything is made from objects, as we mentioned earlier, and Linden Scripting Language allows us to manipulate the objects as we need.
- Second Life provides primitive shapes for users to create any object with. There are many basic shapes that a user can choose from as basic building blocks to make any object from. Some of the basic prim shapes are the square, torus, sphere, cone, etc. These prims can be edited and manipulated to create more advanced detail to objects and prims can be combined to create advanced objects. Because advanced objects are made of primitives, or they can be imported from a design program such as Blender. The imported objects still use prims, but not as many as if we created them completely in Second Life. There is a small cost to upload objects though, so we have to balance cost versus detail.
- Second Life imposes prim limits to manage the amount of storage necessary for each server and to help manage the rendering of land. Users that buy land receive a certain number of prims that can be used for construction or other purposes. The more land that is bought, the more prims are allotted, as displayed in the table shown.Owning land has a monthly cost that remains fairly small for small amounts of land, and increases as more land is bought. While building DOCTOR, we must balance the cost of land with the number of prims that we can use. Currently, we have 512 square meters to work with, which gives us 117 prims. We need to limit the cost to our sponsor by importing more objects, which only have a one-time upload cost, to reduce the prim count. By using imported objects, we can reduce the prim count giving us more objects on a smaller piece of land.
- Second Life allows the importation of sculpted geometries in the form of image based “Sculpt Maps”.Sculpt Maps are tga images which have the 3d location of vertices in the grid available mapped to a relative location in space using the colors of the image to describe the x, y, and z.I.E red is mapped to X, green to Y, and blue to Z.Maximum grid size is 128x128Minimum is 32x32However ALL grids are rendered at a 32x32 resolution, higher resolution grids are simply down sampled to fit.A Sculpt map is mapped to a 3d base geometry such as a sphere, cylinder, or torus, however it is important to note that a sculpt map only denotes a deformation of the original prim not a new geometry.
- Because Sculpted prims are not their own objects but mapped on to existing geometries they can have some issues, the image here was taken using the official viewer of a sculpted table, on this particular system the table did not render correctly, however on a similar system using a different graphics card it did, this inconsistency is problematic.
- Benefits:Sculptedprims allow for content that would otherwise be impossible within the restrictions of Second LifeThey work well on a small scale where minor inconstancies and rendering errors are hard to seeDetractionsSculpted prims don’t scale very well to larger sizesCollision becomes a problem, where the projected object and the collisable object can be wildly differentRendering becomes awkward, maps that render correctly at small sizes no longer do so.Difficult to texture such objects without extensive 3d modeling experienceHigh resolution maps downsampledAll maps are rendered using a 32x32 grid
- Linden Scripting Language is the language used by Second Life to give objects behavior. LSL is similar to Java in syntax and is a nearly complete language. LSL runs in a sandbox, which means that each script has it’s own memory location and cannot interfere with critical functions if something goes wrong with the script. Any script is attachable to any object by creating a new script in the object or by dropping an existing script into the object’s contents. We’ll go into a little more detail on this in a minute.Scripts are easily executed and they can be programmed to run at many different cues. These cues can be when a user touches the object, a specified event occurs, or at a specified time.
- Second Life provides many system calls that can tell us almost any information we may need. These provided functions allow us to get system, object, or user information easily so that we can make objects interact with users more efficiently. We can also change any object property, such as the texture, position, or rotation. We’ll show you an example of a script in a few minutes that uses a few of these system calls.
- Scripts are easily attached to objects by placing them in the contents of the object. Multiple scripts can be placed in an object and scripts can talk to each other to provide better functionality. The screenshot here shows the contents of our presentation system, which includes five textures for the slides and the control script. Once a script is compiled and saved in an object, it automatically starts running and waits for the pre-determined action before performing the necessary functions.
- Our door action script is a simple example of the syntax of LSL. This script runs when the door is touched and it opens the door 90 degrees. The touch_start function tells the script to run when touched. The function llGetLocalRot stores the current degrees of rotation in the variable rot. The if statement checks if the door is open or closed and stores the new rotation value into the rot variable and the function llSetLocalRot sets the new value, thus opening the door.The door rotation is tricky because the rotation is set from the center of the object. To get around this problem, we must attach a very thin prim to the side of the door which makes the center the connecting point of the two prims. This makes the door appear like it is rotating from the side, but in reality is rotating the entire object.LSL is pretty straightforward and provides an easy way to manipulate objects.
- Now that we have given you an overview of the architecture, Doug will give us a demonstration of what we have working.
- Thanks Michael.For our software demonstration, we will start with what we have created so far and show you a detailed overview of how we created everything. We will also show you the University of Kansas Medical Center complex to show you what can be created in Second Life.
- In this presentation, we have given a general overview of the current state of our project.In particular, we gave a brief overview of the class along with a detailed look at the problem we are trying to solve and how we propose to fix it. We also looked at the user interface, which included the Second Life interface along with what we have created, and the architecture of the project and of Second Life.We concluded with a walkthrough of what we currently have working, along with a quick tour of what KUMC has created as an example of what we are working towards.We would now like to open the discussion for any questions you may have.