UnReality

Sensor pads working

2005-10-22T00:03:00.000+10:00

Tonight I have tested the sensor pad mockup I made, basically 2 bit of wood and some foam, and it WORKS!. If a user steps lightly on the pad, the person starts walking, when the person steps harder, the person runs! :)

I have also gotten the airstick working, there were some hastles, basically unreal joystick support is dodge, but thats all working now, and it feels pretty good, although we will need to user test over the weekend to tweak the interface, its basically done :)

Ceiling done

2005-10-20T23:14:00.000+10:00

Some quick pictures of the ceiling, 6 hours later :P

Room and Underworld progress update

2005-10-19T23:10:00.000+10:00

Quick update:

The room is destorying my inner child. Simply put, the amount of fabric to work with is just simply too big, it doesnt fit in a single room (even the workshop). Working on it tomorrow, so will get it fixed. As far as the design is concerned, added 4 curtain rails for support, and also wood for the top to glue to the fabric so it doesnt sag. Still waiting to hear back from bunnings about sponsorship so dont think it will happen.

Sensors are being built atm, basically just 2 bits of wood each side and foam in between for the sensor. Will be testing this tomorrow night.

Airstick has arrived today (heard from our client), so we should be able to give it a test run tomorrow.

Paul has said he may have the calculation program done this week, however I will email him tomorrow about them.

Bought an infared kit today (like the ones that shops have to ding whenever someone enters. Hoping I can hack this apart and attach to an ezio sensor so I can sense when someone has jumped, therefore jumping in the game.

Finally mark is working hard on the underworld, here is some pictures he has sent me earlier:

big weekend ahead, out tomorrow at 8:30 to scour the neighbourhood for things to use in the room, as well as test the sensors, test the IR, test the airstick, finish the underworld, get it all together, set up the room, and start coding :). Hopefully will be ready by monday, even if it requires 0 sleep.

Corn!

2005-10-16T00:07:00.000+10:00

Consists of
- A corn texture applied to a mesh, duplicated numerous times.
- The mesh is the same used for the gras, only scaled differently. So the performance hit is minimal
- The soil is a model made in 3DSM and a modified/ploughed soil texture applied

http://img414.imageshack.us/img414/6902/corfield8xn.jpg

Underworld

2005-10-15T21:01:00.000+10:00

Five minute job.

Avatars

2005-10-15T12:35:00.000+10:00

Avatars and Skins
With the short timespan left, it seems the easiest way to get avatars working in the map is to use existing UT2004 player models, or models others have created and packaged for UT2003/4. The problem however is that there is a severe lack of models that suit a Mayan environment. Most are of aliens, robots and Simpsons characters. However i was able to find 2 models (one male and female) that are at least somewhat suitable, once the skins have been altered. Both skins have had a skin darkened as well.

Female A
The original had a blue dress and blue hair and black boots. I changed her dress to a faded red, made her hair black and replaced the boots with sandles.

Male A
This is a model of the leader of a skinhead clan apparently. The original was covered in various tattoos and wore blue jeans and boots.

Problems:
- The models have different shaped feet because they are meant to bw wearing boots. Replacing them with a skin texture results in odd looking feet, however it can be masked if the avatar is walking around in the thick grass.
- The models' are made for UT2004, where players hold weapons. The characters come with idle animations (such as the female's standing pose) that may be suiitable, however walking around is in a gun holding position. Some avatar couldperhaps be carrying a bale of corn or a pile of sticks as they walk around.

AIScripts
I have been familiarising myself with the AIScript and ScriptedController systems even further (it's quite a complex system) and have been able to get these custom avatars controlled by them. This means that the characters can walk around the level in a set path, or they can play sounds as they go (talking?) and also talk (play a sound) or change their animation as a player approaches. It is possible to set conditions so the characters will do different actions based on something in the level, however I have not yet tried to get this working, and I'm not sure where and how it could be used in the final game.

Grass
I have the new grass in. It looks more realistic (in my opinion) than the other grass, and also sways around. I have also increased the density 5 fold which, due to it all using the same mesh, has little effect on performance.

The Environment
Looking at the research.famsi.org Erik linked to has been a fantastic resource in seeing how the environment looks. Contour maps etc shows the temple locations, however these ariel photos show forest growth, fields between the temples etc. They are of the modern day site, however are still good reference to go by.

Also, another fantastic find was a painting by Christopher Evens of a Mayan city. I'm not sure of the accuracy, however it clearly shows the Palace and Pyramid temples in their correct locations. The stone floor surrounding the area is something interesting, and will have to bring it up with the client on Monday. I think it would be a great resource to base the environment on.

The Staff:
I have created a working version of a staff that shoots lightning as per the client's request. The staff is a child class of the lightning gun, with a custom model. The client has stated that the model is not an accurate representation of a Mayan staff, however the model can easily be recreated and imported over the top of the existing model.

The client has also expressed interest in creating a blow-dart style weapon. Any such weapon should be easy to create, by extending the existing weapon classes. The flak cannon is the most suitable, as it can fire a projectile which is affected by gravity. I have asked the client for any information/pictures on what such a weapon may look like so it can be modelled and textured in 3DSM.

Assault Mode working !

2005-10-15T11:38:00.000+10:00

Today I have been working on modifying the Unreality game type (see the big update post) to extend the assault mode. What does this mean? Through talks with our client, we have decided that the Assault mode in Unreal 2004 would be our best bet, as it offers the best single player experience in terms of progression. Assault mode gives players a set of objectives, which can then be carried out by the player. Types of objectives are getting to an area, getting close to a particular player or actor, standing in a single place for a period of time, or destroying an object. This means that we can build our game objectives around these categories, and this enables us a lot less coding time. It also means that it "SHOULD" be possible to run a network game between our setup and a normal computer, however due to not having Unreal for Mac (that works) we have not been able to try this yet. Here is a screenshot of what the assault looks like at the moment, we will change all the icons and everything to make it fit in better with the game:

Here is also a screenshot of the game menu (been having problems screenshotting it):

Mark has a series of Avatars up now, and also has created a staff that shoots out lightning. Unfortunately dont have any screenshots of that at the moment, but hopefully will be up soon.

At the moment the HUD is causing all sorts of problems, as can be seen in the screenshot the minimap is there, however I want it to be circular instead of square. At the moment its using the DrawPortal function, however I have been toying with the idea of making as a texture instead of a portal. To do this I created a securitycamera within the level, that followed the player. Then I applied a shader to make it round. However Unreal doesnt seem to support having scriptedtextures placed on the HUD, therefore it is impossible to do. I could have a square that followed the player with the texture, but I believe this is a very dodgy solution so I wont progress with it. Today I will be doing more stuff on Assault mode and also remaking the HUD textures and stuff to fit in with the new SQUARE minimpa :(

Plan until submission

2005-10-11T21:28:00.000+10:00

Okay with only 12 days until submission, it has come time to write down a plan to stick to until deadline. There are an enourmous amount of things left to be done, so there isn't much more time for stuffing around.

Dekker
---

Tuesday 11th - Testing out material and this document

Wednesday 12th - Finalizing the construction of the room and game design documentation

Thursday 13th - Finish game design documentation and begin unrealscript and interaction documentation

Friday 14th - Continue with unrealscript documentation and finish HUD

Saturday 15th - Blog and set game up for assault mode (with objectives)

Sunday 16th - Do professional practice assignment (30%) and set up cube

Monday 17th - Meeting with Erik and finding out whether room can stay up till exhibition and book out projector

Tuesday 18th - Chase up mesh settings for cube and do sensor pad construction

Wednesday 19th - Insert the assets into the game and make anymore that are required

Thursday 20th - Same as thursday + blogging and finalizing unrealscript and interaction documentation as well as making the push sensor work correctly

Friday 21st - Final research into Mayan civilization and begin constructing goals based on the game design doc and the research

Saturday 22nd - Get the cube working fully with the projector

Sunday 23rd - Final testing of the game (adding any code) and making box/manual/faq etc

Monday 24th - Present and finish anything not formally completed

Tuesday 25th - Sleep.

And I think that should cover almost everything.

Update!

2005-10-04T23:19:00.000+10:00

Sorry about the big delay, have been working so hard we haven't had a minute off to blog! (:D). The project is progressing well (although extremely slowly), and is looking like a few 100 hours work to get to a good stage. We are currently using IRC, MSN and whiteboards to collaborate and keep track of our progress, and we have modulated the code so that it is much easier to transfer and update between computers (see code section).

Room:
-----
The room setup at the moment is going really well, except for some minor hastles. A budget of 100$ was given to building the room (dimensions 2.5 by 2.2 by 2.2). After many designs and many wasted pieces of paper and dead pens, I decided that there was no feasible way to create a freestanding structure of these dimensions which matched the criteria (portible, sturdy, safe and projector reflectivity) without stealing many housing estate signs. I collaborated with a friend who has had many years experience with structual physics and building things, and we decided that the best way to match all criteria in the budget was to create a structure that used the roof for support. The ceiling in the room where we are to present is tiled, and these tiles can be pushed up so that rope can be attached to the steel that holds the tiles in place.

With this decision done, I then began started designing a solution that incorperated the roof. Something light, portable but also sturdy enough to hold the walls in place was needed as a base structure. I decided on electrical conduate as I could aquire some for free and it met this criteria. I built a structure that was 2.2m by 2.2m in size, with an extra 100mm on either side for support to the ceiling. Although I was unsure how I was going to attach the fabric, this was a start and one that was needed as this side of the project was severly draining energy from the team. I used 10$ worth of 1/4 inch by 2 inch bolts to hold the conduate together. Eventually the structure was complete:

The structure was designed in mind with the roof, and after aquiring some stiff wire, 12 hooks were constructed that would connect the structure to the ceiling.

-------------------- --ceiling
V V V V V V --hooks
--------------- --structure

With the structure complete, I then had to choose a fabric that would be sturdy enough to hang from the structure and not twist or gather, as well as a fabric that would have enough reflectivity for the projection. Through a friend I got a bargin on projection material fabric that satisfied both of these requirements. I then designed the cut for the fabric so that 2 walls and the false ceiling would consist of one piece of fabric, and then the front wall would be a seperate piece. This means that the fabric can be transported without creasing it, and it is also the best way to secure it to the structure. The material looks like:

The cost of the material was 90$, which finished off the given budget. I then bought some acrylic cotton that will be used to seam the material so that it bends at the corners properly without curvature. Excess material is also available to block out any light from outside the room, so that the picture is as vivid as possible.

The mirror has arrived, and myself and Erik tested it out (see previous post). I have also begin testing out the projection screen, and I am hopeful that Pauls measurements will be possible to do through the projector alone, rather then the game itself (which will be much more difficult). I have also tried to hook our PC into the sound equipment in the room we are using, but have so far been unsuccessful. I am hopeful that we can aquire a nice digital surround sound setup which can be places outside the 'room', as our game sound and music will be designed with 5.1 surround sound enabled.

Currently I am hoping that the fabric will be completed and attached to the structure by the end of this week (week 11). I then hope to test out the setup with the mirror and Pauls calculations on friday of week 11. Once this is complete, the structure will be pulled down, and only put up again at the end of week 12. Then that leaves 3 days to get the screen setup perfectly and working with the game.

Interface:
---

The interface part of the project has not been progressing very well as of late, but still is the most progressed of all the parts of the project. There are three main parts to the interface, the floor sensors, the 'push' sensor, and the airstick.

At the current time, the airstick has not arrived, although it has apparently been bought. This causes major dramas for our project, as it was anticipated to be the piece of technology that bought the immersion, although if it does not arrive in time for the project it is possible to use a standard mouse. The problem with the standard mouse is that it will make players extremely uncomfortable (as we have found through testing), and will make the effect of the floor sensors lessened.

The floor sensors are almost complete, although there have been some major hastles with them. Firstly due to the age of the EZIO boards that we are using, the time it takes for readings to be taken on the sensors is extremely inefficient. With four sensor readings, there is around 2 seconds of lag, which is not acceptable. However we have discovered that adding multiple EZIO boards will relieve this problem, and so for the final we are hoping to aquire four EZIO boards (at the moment we have two). Another problem is again due to the age of the boards, there is crossover on the connections on the board. This means that when one sensor is pressed, the other sensors also detect a small reading. This means that if a player interacts with the sensors to move forward, then they may also sometimes begin to move left. Again this problem can be removed by using multiple boards. This weekend will also involve creating casings for the analog sensors, so that players have a much larger surface that they can stand on to activate them. This will be done through a foam casing. Once these are complete, the floor pad sensors will be completed. The last stage for this interactive device will be to code into the system 'gestures' where by a player can perform actions such as jumping by performing a set of sensor movements in order. This cannot be completed until four EZIO boards have been acquired (due to the problems with user testing with 2 seconds of lag). The unreal and java code for this has been completed, with the two languages being connected through UDP sockets.

The final part of the interaction is a podium that will contain an analog sensor. This sensor will be used to 'push' things in the virtual world, in particular a stone slab that is situated within the temple. The code for sending this sensors information to the server is complete, however at this time it is unsure whether it will be possible to code. However theoretically it should only require that if the player controller is against an object, then the object will recieve the reading, and will then move accordingly. However due to time constraints this has not been tested yet, as it at a lower priority then the other interactive devices.

Unreal Game and Code:
-----

As stated in the below post, the code for this project has now been modulated so that it is no longer integrated with the UT2004 game itself. We have also created batch files to perform the install of the mod, so that it can be run merely through "UT2004.exe -mod=Unreality". This means that myself and mark can quickly send the game to eachother without having to worry about which files to send. The basic file structure for this mod is:

UT2004 --Root Directory
\-Unreality --Our Modification Directory
\--changelog.txt --A log we have been recording changes to the game
\--compile.bat --A batch file that compiles the source code to unreal and deletes old compilations
\--play.bat --A quick batch file that runs the mod
\--ut2k4mod.ini --An unreal required file that sets the default name, description and URL for the mod
\--Help
\---UnrealityLogo.bmp --Our loading logo for our MOD
\--Maps
\---Palenke.ut2 --The Palenke Map
\---Underworld.ut2 --The up and coming Underworld map
\--Textures
\---Unreality.utx --HUD textures
\---projectunreal_tex.utx --Textures for the maps and static meshes
\--Static Meshes
\---projectunreal_sm.usx --All 3dsmax models for the map are stored
\--Sounds --Where any sounds will be stored
\--Music --Where any music will be stored
\--Karma --Where any physics modifications will be stored
\--Animation --Where additional animations will be stored
\--Unreality --The compiler directory
\---Source --Source code for the MOD
\----avatarPawn --The extention of the player character model and movement
\----avatarXPlayer --The extention of the players controller
\----HUDUnreality --The HUD for unreality
\----myUDP --The socket connection code for the sensors
\----TestModKey --Interaction controls for the menu
\----TestModMainMenu --The main Menu
\----UnrealityCameraMap --Camera emitters
\----UnrealityGame --Constructor class for the game
\----UnrealityMenu_Load --Custom loading menu
\----UnrealityScoreBoard --Inventory and player action recording (an extention of the HUD)
\--System
\---default.ini --Default UT2004 ini file (required)
\---unreality.ini --Custom config file for setting up compile and path locations
\---unreality.int --Construction file used to set game and map type
\---unreality.log --Custom log file
\---unrealityuser.ini --Custom ini file for binding and alias's used in the mod
\---unreality.u --Compiled source code

This structure means that the entire unreality directory can be safely removed and transferred to a clean install of the game without any problems. Although this layout seems quite simple, learning how each part of the mod (especially the ini and int files work) was extremely difficult and tedious.

The main problem we have found with the structure and coding with unreal is that there is simply no official manual. Although there is a brief reference guide, it doesn't cover any specifics on the language. The best sites we have found are: http://3dbuzz.com, http://wiki.beyondunreal.com/wiki and http://udn.epicgames.com/Two/UnrealScript. The last reference is the official reference guide, however most pages within the guide require registration, which costs 250,000$US. Although the entire unrealscript code (which controls all of the game minus the native C engine code) is available for browsing, it is extremely big (about 30 meg of source, which is 6 times bigger then the quake 3 source code). Because of the OO coding style, every class written has to extend a pre-existing class, and then has to be executed by the mod in the right way (either from an int, ini or class file). To use this code effectively, a coder must have indepth knowledge of OO code, including typecasting, polymorphism, extending, interfacing and instancing. The code itself is quite java like, and consists mainly of event handlers, functions and condition statements. An object is the main class, which is extended by actor, which is anything in the game. Anything above that is part of the game, including HUD's, Playercontrollers, AI, sound, anything at all. The problem with this is that the OO structure is destroyed because many things are included where they shouldn't be.

To combat these problems, we have found an incredibly useful IDE code interface for unreal (WOTGreal). This interface is excellent as it sorts the classes in heirarchy which can be look at my better. The IDE also includes syntax highlighting and quick compiling.

Another problem is the fact UnrealEd (the editor for unreal) is extremely buggy and likes to be difficult (currupting, not opening and not saving documents). UnrealEd is required for all placement within a map (actors etc), as well as setting properties, event triggers etc. It is also responsible for creating matinee (cutscenes) and any special effects. It is well integrated with unrealscript, however it is very hostile against Mods. UnrealEd is also required to compile any textures, sounds, static meshes (external 3d models) and animations. Although this program is quite effective at what it does, its problems make the workflow much slower then it should be.

At the moment in the game itself, we have completed the menu screen, loading screens, map (palenke) and are currently working on animations, HUD and the underworld map. We are hoping that we are on track, but there is an immense amount of work left to be done.

Although this is only a brief summary of the work we have accomplished so far, writing an entire list of what we have tried and finished (including code) would take days in itself, although we are hoping to have a FAQ to creating modifications for unreal in the final version. We are still looking at game design ideas, and are hoping that our client can give us a solid and scopable game idea (as he is much more knowledgable in the area of Mayan civilization then we are, although we have some ideas that we are trying out). At the moment we are behind shedual, mainly due to the unexpectedly high learning curve of unrealscript, but we are hoping to accomplish what we first stated, that is a fully living breathing interactive and immersive world that helps to educate users in Mayan civilization.

Unreality now self-sufficient!

2005-09-28T02:27:00.000+10:00

Tonight I have been working on transferring Unreality into a TC (total conversion) mod for Unreal. This means basically that its a whole new game in a sense, rather then a simple modification for unreal.

The advantages of this are:
Totally custom menu's and intro's
Custom loading screens
Much easier to control (with regards to versions)
Much easier to backup (all in the one directory)
Much easier to install on any computers
And finally much easier to edit the code/textures/maps in as they are quite seperated from the default assets

Tomorrow Mark will be looking at the HUD and Ill be looking at the sensors (AGAIN :()

Mirror finally arrives!

2005-09-23T18:41:00.000+10:00

The mirror for our *cough* CAVE *cough* arrived today, so as soon as I had the chance I ran down to the office and borrowed the mirror and projector to test it out.

It seemed really angry towards light, so we tried to mark it dark as possible, and it actually worked really really well (well a lot better then I was expecting). Although the image really needs to be modified to work properly with the mirror (which paul is helping with) it is actually semi-playable/semi-readable especially in windows desktop.

Here are some images that Erik took after it was set up.

Our attempt of taking a photo of the setup with the flash on :D

without the flash (very dark though, pretty average photo too, looks a lot better in reality

the mirror as such, probably can be buffed and cleaned up a little :)

dodgy photoshop effects meet low budget 3d projection

I gave back the projector and mirror today to A.M. (because Di is sick) and Im hoping that the mirror will still be okay on Monday (its apparently really fragile :-S) but should all be good.

Sensors

2005-09-22T22:54:00.000+10:00

So as many people may now know, I have the analog sensors through java into UT through sockets. I will put up the code eventually (been at uni already today for 12 hours so really cant be bothered). However I have been thinking about the lag that is associated with the sensors, so tomorrow I am going to try get 4 different boards and see how much that speeds it all up. If that is still not acceptable, I am thinking of moving the program to C++. I have done almost no C++, but over the last few days have been going through a heap of tutorials trying to figure out how best to do it. Hopefully in a few days time I will have a solution that takes care of the lag, and hopefully the airstick (with pc drivers) will be here soon, in essence taking care of the interface and being left with the tedious task of making the actual game :D.

Prototype and Midsemester

2005-09-22T18:07:00.000+10:00

Monday’s prototype presentation went well (if not a little overtime). Both myself and Dekker have had a number of students comment to us throughout the week how impressed they were with the project.

After a long weekend we managed to get everything into the prototype we wanted to have at that stage. The only aspect that was missing was more NPC’s...however the system used to control and navigate scripted bots is far more complex than I had envisioned.

It would also have been nice to have an airstick for the prototype; however it’s out of our control but will hopefully arrive soon. But we can save it for the final :)

The midsemester break will give us a great opportunity to catch up on other projects and keep steady progress on this one. Next week I’ll try and get the environment polished:

- Texture changes, modifications with guidance from Erik
- Guidance from Erik with positioning of buildings etc
- Additional visual detail (butterflies, moths, birds etc)
- Ambient Audio (wind, birds, trees, water, insects)

While also working with Dekker and Erik on the game idea and specific game objectives. Also becoming familiar with the NPC system, so that characters can be walking around, interact with the player and generally give life to the environment.

Huts are working

2005-09-19T02:33:00.000+10:00

Huts can be found at:

Huts

Terrain...the good, the bad and the ugly

2005-09-17T23:11:00.000+10:00

After a week of trial and error..I finally have some progress on the terrain.

Good:
- Terrain from a 3DSM model is in the Unreal engine.

Bad:
- Unable to convert contour lines into a 3D model. So not all of Palenque is in the prototype.

Ugly:
- Exported 8bit greyscale is far less definition than 16bit. The final terrain is bumpy and 'jerky'. I have smoothed it out a bit but may have to look into using Maya for 16bit heightmap exporting (which 3DSM cant do from my research).

-----------------

Rather than importing a terrain 3D model as a static mesh, I want to use Unreal's terrain system as it was designed for this very purpose.

- It renders faster
- It is easy to modify from the editor
- Ability to 'paint' on layers of different textures
- Ability to 'paint' on grass, trees etc

In the previous level we had a (rather quickly) created terrain built from memory of Erik's 3D model. It looked very 'game like' in my opinion and was nowhere near accurate.

I have imported the Autocad contour line files into 3DSM, however am unsure how to get that into a 3D terrain model. The terrain and compound shape tools which seem to be for this prupose only seem to work when the contours/splines are in a 3D arrangement.

So for now I am using the terrain from Erik's "wholesite.max", it appears accurate but not all of palenque is there.

Step One:
Render the 3D terrain from a top, orthorgraphic view and enable the ZDepth render filter. This generates a second, 8bit greyscale image which pixels closest to the camera white, and those furthest away black.

Step Two:
Crop, scale and resize the heightmap accordinhly in Photoshop. Unreal engine only accepts textures with dimensions of powers of two. The heightmap I'm using is only 128x128 pixels to keep the final terrain polycount low.

Step Three:
Convert the 8bit image and save it as a 16bit heightmap (.BMP) using a program called "G16Ed" which was written for Unreal heightmapping.
Import the 16bit .BMP into UnrealEd overriding the heightmap texture.

Sensors!

2005-09-13T19:18:00.000+10:00

Lorna suggested to me that instead of jumping into analog sensors, that I may want to first make up some digital ones to see if the navigation interface actually is acceptable for use, and also whether analog sensors would add much to the experience. Today I made up 6 digital sensors (foam, aluminium and wires) to hook up to unreal to test out. I will be testing these out tonight, and will leave these in here. At the moment I am currently going through unreal, that is learning unreal completely. i think i have the mapping utility (unrealed) pretty much sorted, and am looking into importing models from 3ds/maya at the moment. These are really only so when I get to learning unrealscript I know the terminology that they are talking about. Im hoping to have learnt script tomorrow (wednesday), and have a fair grasp on the physics engine (karma) and the AI pathing by thursday. Then I can spend the weekend sleepless catching up creating our presentation for prototype. At the moment Mark is struggling with the heightmap terrain in 3DS in trying to export it into Unreal. More to come.

Oh one last thing, I spoke to Bergita today about materials for the cube, and she is going to have a look around this weekend, as will I (in my spare time :D). Were hoping that a rough version of the cube (without PVC pipe :<) can be made for around 100$, skeptical, but hopeful :).

Project Progress as it stands

2005-09-04T15:22:00.000+10:00

There are 3 phases of implementation and design for this project:

Projection/Screen/Environment/Equipment:

At the moment the screen and projection phase is in freefall until we can successfully find a budget to buy PVC to create a room, or find a cheaper alternative that is as light and portable. The mirror is on order I believe, so we should be able to test whether the method of projection will work, even if the display is not optimal. We are in discussions with Paul Burke at the moment regarding projection methods. The number of machines that we require isn't a huge issue, I am bringing my PC in to uni to use as the main place to code up the game and interface devices, so that both me and Mark have 24/7 access to it.

Interfaces:

Interfaces at the moment is a bit behind shedual, but should have caught up by this week. The floor mats (analog sensors) should arrive back at Di's office this week, which means we can start creating the movement interface and also the podium/rostrum for moving objects. The airstick is being ordered asap (or is already ordered?) so should be available soon. The design of these interfaces is roughly worked out, however much testing will be required to see if they perform as well as expected. We are currently talking with Jeff Jacobson (www.planetjeff.com) on both the interface and screen issues.

Game:

As can be seen, Mark has the game progressing well, with the main temples and the terrain imported. Although no interactivity or game has been implemented yet, the world is semi-created so progression on the game can commence.

Plan for this week:

Get placeholders in for the game, allow walking through the game, finalise the environment(models/textures), show it to the client, work out a script for the game

Plan for next week:

Floor pad interface working in unreal, with analog inputs, some game aspects complete, character models worked out, start of script implementation.

Plan for prototype:

Floor pad and airstick implemented into the game for user testing, first part of the script complete in game, game looking promising.

Post prototype:

Finish game, finalise interface, get projection working.

Its looking like its going to be a very long project, however we have been pushing ahead in other studies to get them out of the way so we can focus on this project.

Progress!

2005-09-04T13:15:00.000+10:00

Changes since Monday:
- Temple textures are now red.
- Changed fog from sandy to grey
- Added terrain (roughly based on Erik's 3D model)
- Placed temples in new locations
- Added a river
- Added a forest
- Birds in the sky!

This will be in our presentation on Monday so I hope to get feedback from students, tutors and of course Erik. My main interest is what level of accuracy is required (landscape, flow of the rivers), and how much can be left up to artistic license.

A night's work...

2005-08-30T01:02:00.000+10:00

Finally figured out how to texture the models in 3DSM and get it preserved when importing into the Unreal editor. A good learning exercise. Just using standard UT2004 textures for now. Add some fog, trees and a sky...something half decent looking!

Feedback welcome.

CaveUT trial

2005-08-29T16:34:00.000+10:00

I was hoping to get this setup last week however I was off sick.

Using the TFT panels on the Dells in the PC lab, we were able to run a basic multi-screen setup with CaveUT. We managed to get up to four displays running, only limited by the tethers on the other computers :)

The software setup is quite easy. All it requires is UT2004, the latest patch, the CaveUT mod and changes to each client's CaveUT.ini file for it's respective Field Of View/Angle settings.

Distortion is minimal, however the latency from the server display to the client/spectator displays is noticeable. We could solve this issue by having all displays as spectators with the server running on an external machine.

However this lateral screen setup is simple compared to a BNAVE/cubic setup. The camera FOV, angle and position settings seem complex to derive. Jeff Jacobson (PlanetJeff) has example setups on his web site which we will have to check out, failing that if we cant figure it out give him and email.

Data Projector details

2005-08-26T23:13:00.000+10:00

Here are some details on the data projector we have available to use, I have to test it out on monday to see how it projects on a wall/roof and wall/floor setting in unreal to see which is more immersive :).

NEC
LT260

Distance away from lens
30 cm away - blurred, unreadable, max focus 8' max 5' min
40 cm away - blurred, readable, max focus
50 cm away - good, readable, max focus 14' max 10'min
60 cm away - good, readable, almost max focus
70 cm away - good, reabable, less focus
100 cm away - still readable, about 23' at max, about 20' min
150 cm away - good, readablew, 40' at max, 25' min
max is about 500cm

Thursday night fun and games

2005-08-25T20:13:00.000+10:00

Currently in this project there is a few things that I have looked at:

The optimal solution for the project would be:
Some sort of screen for viewing (preferably cave or VR)
Unreal engine game taking advantage of the interface devices
Floor mats for walking through the world
Bodypad for moving the avatar, not so much walking but positioning legs and arms with objects
Airstick for manipulating objects, picking an object up, putting it somewhere, integrated and sync'd with the bodypad

Tomorrow I will get out a projector and set it up to test how accurate and clear it is.

Meeting on Monday and other random things

2005-08-24T20:13:00.000+10:00

First things first, interim presentation on Monday ! (YAY)

Myself (Mark was away), Erik, Carla and Lorna had a brief discussion on Monday about the progress of the project.

In that regard, nothing :). The project at the moment is pretty stagnent, just looking at possible technologies and all the fun procastination things (except for actually getting in there and coding).

We talked about screens, interfaces, (missed out on the game ideas) and giant cubes that will take over the world.

Game ideas at the moment:
Erik is really interested in an Aztec type environment, with a game idea he has been playing around with previously.
I am more interested in the Mayan culture, although its a bit dirty and crazy for a mmds project (lots of violent and wrong things). Were definately looking at a FPS although it may be necessary to use a 3PS (third person shooter) cause of the problems with immersion.

Interfaces:
We talked a fair bit with Lorna about interfaces, seems it may be a huge hastle, due to getting the interfaces talking with the game engine (UT2k4). We found out that there is analog sensors at Di's office, which may be useful. The interaction between the EZIO board and the game through director/java (yes java is slow too) and a text file makes this pretty impossible. The only way now is to delve into C coding, however because the source for UT engine 2 isn't available, it makes it hard to plug the equipment in (we have asked planetjeff.com's admin about it). Another possibility is the bodybag (http://www.bodypad.com/eng/), although this is meant for PS2's, it may be possible to use a PS2/USB convertor to get it working in our game.

Screens:
Screens. Cubes? CUBES!. After looking at the mirrorbox idea way to much, we have decided to build our own temporary room to create our own mirror box. Although I was skeptical about the idea (I spend most of last night researching if it was possible physically), I have been ensured that it should work. So now I have designed how to build the room, just waiting on dimensions. It will be made of alumium joints with T sections to put it all together, however cant decide definately until the dimensions have been given and see what is possible with the size. For the screens I am thinking canvas or calico, and to keep them flush and square to use the same method as flyscreens (the wire that holds the screen in place idea). Although again this would be near impossible with metal (wood may work though). The fact that it needs to be portable is a big problem though, which needs to be constantly considered.

We also got 7.5/10 for our first presentation. We aren't too happy with our marks but know that we did fall down in a few areas (although it seemed strange that we got a heap of good feedback from others). One really strange thing that we got on our feedback sheets is everyone loved our presentation slides but thought that they were a bit too flashy. However we only got 5's and 6's for our presentation flashyness, which was strange, considering we also had a video we had made and a 3d model of what we were looking at building.

Anyway thats progress for this current moment in time in space in this dimension on this planet.

UQ VisaC setup

2005-08-17T15:35:00.000+10:00

Today I was going to ring the UQ VisaC department, with the intention of asking to borrow their equipment or use it to display our project (the HPC (high performance computing) faculty). However before ringing them, I decided to look at what equipment they actually have available. It was very encouraging to see that the lab has 24 hour access, something that will definately be needed.

"Students attending subjects within the Lab are offered individual swipe cards
that grant 24 hours access.
The card may be used to unlock the doors to the lab and buiding access door immediately below the lab.

The lab workstations may be used at any time the Lab is not booked.
During a booked timeslot, ad-hoc usage is at the descretion of the booking holder.

Forms to obtain a swipe card or register an existing card will be supplied
by the subject lecturer or supervisor."

I believe that Erik may be able to get us access to the lab, but it seems only students with the right permission can use it. However the main problem seems to be the fact that the HPC lab uses Intel Itanium processors, rather then AMD Opterons. The problem with this is the fact that Itaniums require specific code for 64 bit and doesn't handle 32 bit like the Opterons do. The other problem is the 64 bit on Itaniums is different from standard x64 bit code. I have emailed Visac with these questions but so far have not recieved a reply. Hopefully if UT2004 can be run and they dont mind us plugging in sensors everywhere it should solve a lot of resource problems :).

Resources

2005-08-16T15:52:00.000+10:00

After looking through the available resources today, it seems that we will be unable to get enough (any) of the tap tile sensors that we were after for interactions. During a meeting yesterday Erik suggested a table with analog sensors that could be pushed, which depending on how hard would push obstacles, very tangable feedback using sound. Anyway have talked to a group doing studio 4 at the moment, and they are having problems finding resources and space required for their project. Their project is going to require sensors as well as a projector, and I am currently disgussing whether we could use the same resources, which might solve some problems :). Am doing up a list of all the equipment we will think we might use (after the table of interactions :P) and then they will do up a list as well and we will see if we can use the same space :). This could also get around issues finding space to setup, or at least the hastle of spending hours looking.

Console Commands

2005-08-12T17:24:00.000+10:00

Interaction in most FPS engines occur through the use of console commands. Any key/button/input can be bound to any console command. Commands cover everything from gameplay input (moving, jumping, switching weapons) to administrative tasks to debugging and developer functions. There are even console commands for changing the key binds.

A list of keys and their assigned commands are usually stored in a text file in the game directory. In UT2004 it's the User.ini file in the System directory.

How can they be used in this project?

1) Basic game inputs.
-Moving around
-Looking around
-Jumping
-Shooting

2) Cheat/Debugging commands
-Third Person
-Fixed Camera
-Variable Game Speed
-Changing variables and properties in realtime
-Display settings to adapt to mood

3) Add our own commands
I've done this before and it's fairly easy. You can specify your own commands in unrealscript and have each command execute functions of code. It's also possible to have the commands accept variables/arguments, so they could do different actions based on the input.

Limitations
It seems that CaveUT uses a network game in order to have each display run on seperate computers. This means that none of the cheat and debugging commands will normally work. Some of these can be enabled by becoming the server administrator, but not all work very well. Commands to change/alter rendering and display options will also only affect the server computer and not any other displays.

Here is a list I've compiled of what commands would be useful in this project. The file includes the name, game outcome and possible uses for each console command.

Complete List of console commands
http://udn.epicgames.com/Two/ExecFunctions

Quick list of interaction devices

2005-08-11T20:18:00.000+10:00

Here is a really quick list of interaction devices

Resource Issues

2005-08-11T18:54:00.000+10:00

This week we have run into serious resource issues regarding the tools needed for our project.

We have heard that for the sensors and projectors there will be a severe shortage on what we actually need. At the moment we are looking like we need:

1 Projector (if our contact using the lens is willing to let us use his technology, otherwise probably more projectors)
5 Taptiles (analog versions of the touch pads, for the movement of the player)
2 Geforce (sensors that control movement for the device we will be using to control where the player is aiming)
1 Touch type sensor (a small sensor that controls the trigger on the device)
Possibly more sensors depending on what else is needed for interaction (use bbutton, jumping and ducking?)

Our other main problem is the severe lack of room space. At this time there is nowhere at the university where we can host our product. Unfortunately due to the fact that we are under-grads we are not allowed master keys to the rooms (which is understandable). We have thought about possible rooms and made a list, however these are not very satisfactory:

209 Side-Room - Not much space, public and not enough blank walls
Animation Labs - Good space, has a code (although public could be changed) but again doesnt have blank walls)
Lower Pit - Good space, but is full of junk
Building 2 Labs - Public but locked at night, good space, possibility of blank walls

We could have a look at St Lucia for a room however due to the fact that the product has to be displayed at Ipswich as well as myself and Mark are situated in Ipswich makes this idea unfeasable.

There is an update for the resources. Tonight I am collating a list of sensors and how they could best be used in an immersive environment.

Meeting with Keiran

2005-08-09T09:28:00.000+10:00

I had a small meeting with Kerian today to discuss the sensors that would be involved in creating a cave setup.

He suggested to either use floor mats (digital) for the movement or touch pads (analog). Analog would probably be the best way to use it as you could control movement speeds which would be much more interactive however it is unclear at the moment how sensitive these pads are.

For the interactions he has suggested using two g-force sensors, that are analog and basically measure movement in a specific direction. Using two of these (one for left-right, one for up-down) should solve the problems with a device. This has also been previously been suggested by Lorna. It could also be possible to use an analog sensor for the device trigger to make it more interactive.

For the implementation of these he explained that for digital it is really easy to hook up a joystick device, however analog would prove to be a problem. I suggested our earlier plan of creating a shell that exports a text file of inputs which UT could read. As we had thought this would probably be quite laggy. He also suggested to look at the UT engine and see if it was possible to insert the ezio c++ code to make the engine recognise the sensors. Another possibility is also to create a program that hyjacks the movement from the sensors and bind the values to an already programmed device (such as a mouse or joystick). However again with analog sensors this may prove to be a problem.

Reverse engineering input devices?

2005-08-06T21:22:00.000+10:00

On Monday Andrew brought up the idea of using a modified joystick for input. The more I've thought about this idea the more appealing it becomes.

Firstly, any such device would already be supported by game engines. As far as the engine knows it's just an ordinary joystick.
The degree of modification required could vary, and straight away we're limited to the device's internal measurement systems. A joystick I imagine would have potentiomters or some sort of jiro system. Some models may even include sensors that measure the force applied to buttons and the stick itself.
Dancepads could be used for foot controls

Secondly, some engines (UT2004 included) support force feedback. I imagine most devices respond with by just vibrating...but connect up our own circuits and a range of feedback is possible. ie: Get shot and a light turns on or something.

Tomorrow I am off to Harvey Norman and some other stores to at least get an idea of what devices exist (as I really have no ideas) and have a play with display models. No doubt some of the more interesting devices will be the most expensive and this will weigh into any decisions.

Phone Meeting

2005-08-05T19:45:00.000+10:00

Today I had a phone meeting with Erik Champion (our client for the project) to decide on Mondays presentation with regards to the client brief and proposal. The notes of the meeting are as followed:

for monday

game engines: look at all engines
avatar: not first person? third person
game models: use egyptian models until we have time to make our own
know which person is doing that
what we want

how would it be successful?
erik: evaluation of equipment: ease of use, scripting required, user and design view, how hard to learn, how limited or portable
what types of interactions the equip suits best
faq for equipment
itinerary for what we want, what is availible - technology
1 test demo environment (web playable)
1 game engine to make videos and use in conferences
erik wants a copy of the stuff, not ownership
focus of the interactive

3 weeks on waiting on screen
paul burke made it
little bit open gl tech
not much work
need to control game outputs

why egyptian temple?
archilogical and tech guy did the caveUT
will get email
book in library about unreal
character animation

working demo, comparison of 2 game engines
gesturing just an option

list in table types of interaction devices and what the interactions are conditions, how it can be adapted to be games

10 mins max

mark - summarise unreal as technology for interactive (an idea) from last semester

mention a room
matt simpson
projected
rear and front projection
how the audience works
head mounted tech - 50000$ for a good one, erik will ask around
visak - a UQ place with screens?

cardboard magnet!!!

phycial device changes when u pick something up - tangable feedback - can it be done - force feedback

springs on the mats, airpumps change bouncyness

arch as placeholders, discuss imaginative worlds

mark - do u want to use the malta stuff, how interactive

video avatars

ghost idea from malta - gonna

USE UNREAL ENGINE

possible machinima creation tool

work out best interface

how much should the client and we want to do, negotiation, scope, equipment test > game or other way round

possible spirit game where at night where u catch spirits, shaman stuff, erik has a game idea

texture

social/cultural - LICENSING

unity - dont look at

torque - dont look at but landscape interesting

keep it untechnical

concern for time and building game stuff, evaluation

28th sept - prototype - is there a prototype ready - architecture conference -

our design process is this way so at the end of semester u can see our process like this **** sketches
make it useful for us as well as erik

work out whose saying what in presentation

Random mockup

2005-08-04T23:07:00.000+10:00

This is just a really really quick random mockup of a bluesky implementation :)

My Skills

2005-08-04T21:23:00.000+10:00

To give an intro to the blog myself and Mark are going to give a rough explination of our skills and what we wish to learn through the project.

For this project I am mainly looking to improve my 3D skills, and to a point my coding skills. My overall goal for this project is to create something that hasn't been done before and something that I can be proud of.

Digital Imaging:
- Adobe Photoshop
- Adobe Illustrator
- Adobe InDesign
- Corel Painter IX
- Macromedia Freehand
- Macromedia Fireworks
- Paint Shop Pro
- Apophesis 2.0

Video Editing:
- Adobe After Effects
- Adobe Premiere
- Apple Final Cut Pro
- Apple Motion
- Apple Livetype

Audio:
- Apple Soundtrack
- Soundforge

Authoring:
- Macromedia Flash
- Macromedia Director

3D:
- Alias Maya 6
- 3D Studio Max 7
- Terragen
- Poser 5
- Archicad
- Amorphium
- Electric Image

Coding:
- Java
- HTML
- CSS
- XML
- PHP
- Javascript
- Lingo
- Visual Basic

My Skills

2005-08-04T21:21:00.000+10:00

For this project I would like to expand on my interest in 3D environmental and game level design, by linking the virtual world with the physical one in a more better/different method than the traditional mouse and keyboard.

The Unreal Engine is my preferred software base however others are being considered and weighted on their ability to be linked with various input devices.

Video Editing
-Adobe Premier
-Final Cut
-AviSynth

Game Engines
-Unreal Engine (advanced)
-Doom 3 Engine (basic)

3D
-UnrealEd
-Amorphium (medium)
-Electric Image (basic)
-3DSM (very basic)

Graphics
-Adobe Photoshop
-Adobe Illustrator

Audio
-Aduacity

Authoring
-Macromedia Director

Code
-C#
-Java
-UnrealScript
-Lingo
-HTML
-CSS

test

2005-08-04T20:55:00.000+10:00

pop goes the weasel