Pages

Wednesday, 11 November 2015

Why Standees Work in Real-Time-Visualisation




When producing a visualisation of a space, you need to add people into the scene. Having figures inhabiting a space stops it from feeling like a beautifully-rendered ghost town, as well as giving a sense of scale and movement. The problem is that creating characters is a lengthy and skilled process that can add significant time and cost. And this indeed is the exact problem we hit when producing the Farnborough Real Time Visualisation.

Uncanny Valley


The primary issues were budget and time, there just wasn't enough of either to make a fully-realised set of people. Since this project was developed shortly after the release of Unreal Engine 4.1, the nascent Unreal Marketplace lacked the range and depth of content that could have yielded something applicable. Early catalogue entries as far as in-game people are concerned mainly consisted of stylised sci-fi, adventure, combat or cartoon characters - not too useful for displaying a corporate exhibition space - so we had no choice but to make some.

We quickly dismissed the idea of animated people. As well as building and animating the characters, the time required for routing, AI and testing would have been too costly. That leaves us with static people. A figure is easy enough for our character artist to make and the first one looked good, so we populated an area with them. This is where we hit a stumbling block. With just one character in the scene it was fine, but with lots of these clones around it was just plain creepy. We were staring down into the Uncanny Valley.


"There's nothing creepier than something that's supposed to look friendly and human, but doesn't manage either. Oh, dolls, they just shouldn't smile."
Steven Moffat





The problem was the people we were trying to make were always real... ish. So perhaps we should make them not real. Initially we tried some shop dummy types, but with a whole generation of cultural horror references burning in our collective consciousness, they were still too creepy. At this point someone made a glib comment about making the damn things cardboard cut-outs, which started us thinking, "Actually, why not?"

The reason it worked is that they have a genuine physicality while still being impressionistic. They give the sense of place, emphasising that this is a space for people, but by being obviously a human-shaped cardboard cut-out with a stand to keep them upright suddenly stopped them from being menacing 'almost-people' into harmless displays.

Developing the Asset Set


Once done, the set was ready for the project, but before we could share it with the Unreal community we needed to do some more work to make it 100% right. Currently the standee set was working well filling in for people in a specifically-styled and rather large exhibition space. What the set didn't do was work well much more close up in smaller spaces, such as offices. They looks a bit flat (Rim-shot, please!),

To address the issue we adopted a well-known solution learned from decades of game development: We started adding the right kind of realism. We've added context-sensitive materials, so instead of them being amorphous non-humans they are now unequivocally made of cardboard, plastic or polystyrene.




With more realistic materials applied we took it further by adding pictures and patterns and it still all worked. As long as we didn't try to make them look like real people (by adding illustrations or images of faces, clothes and accessories) we could steer away from the Uncanny Valley and maintain that physicality. Putting real-world items on the figures just made them look like pathetic non-people that are trying too hard.

Wrapping up


This set of standees is a celebration of the non person. It neatly solves the problem of adding life into an architectural space without adding people. With careful uses of materials, logos and images, they can draw attention to specific points of interest, navigate the viewer through a scene or just stand back and be nondescript, but always looking well-finished and logically not at all human.





Friday, 16 October 2015

Over 400 UK Road Signs for Unreal Engine 4





These UK Road Signs have been made specifically for Architectural Visualisations for big developments.

Large and complex spaces is where Unreal Engine can really shine with it's fast workflow and powerful rendering. Helping developers, architects, local authorities and the public to really visualise the impact, opportunities and (hopefully) beauty of proposed schemes. As part of the design these signs have a relatively small memory and rendering overhead while being attractive and quick to implement, leaving you more time and resource for the important architecture and landscaping.

The objective of these road signs are:

  • They are quick and easy to use
  • They have a small memory and resource footprint as their main use case is on large projects
  • They are not 100% physically accurate but are an iconic representation of the intent of roads and routes in a simulation to illustrate intent
  • They are realistic looking enough to not jar against common Real Time Visualisation (RTV) styling



Uk road sign images are owned by the UK Government and can be used according to the Open Government Licence Version 3.

If you want to know more about UK road signs and how they are used, a good starting place is Traffic Sign Images. From here you can access all the rules for proper road sign use in the UK and pretty much anything you may need to know about the subject of UK roads.

Lastly, if you have a requirement for 100% physically accurate digital or real-time UK signs, roads or street furniture that adhere to UK highways regulations and building standards please get in touch.



Using the Signs

UK Road Signs are accessed via four Blueprints: a single sign; wall sign; signs on a post and signs on a roadworks frame.

The main blueprint is Sign_single which includes all the functions for setting up a sign. The other Blueprints add on a few extra instructions to deal with moving the signs around in relation to each other.


   

Using Sign_single


The single sign is intended to be wall mounted and the pivot-point/origin sits just behind the sign so it will easily snap to walls that use the UE4 grid. The meshes actually sit just off the grid so the sign gains a strong shadow or ambient occlusion to avoid looking like its floating. Also this leaves a logical space where a wall bracket would go.




The sign mesh is a little fat compared to a real sign, this is to reduce z-fighting at distances and also to reduce aliasing artefacts when the sign is edge-on.




When you first place the sign in the world from the Content Browser an arrow showing which way the sign is facing and a yellow bordered warning sign are shown until you choose a proper sign face. This is not a real uk road sign its a "Warning you haven't chosen a sign yet" sign.




The details panel allow you to tweak the appearance of the sign and choose what sign face is shown.




Sign Condition




The default condition is "new" which is pristine and shiny. The other conditions are for the odd occasions where a sign is drawing undue attention to itself and needs to bed into the environs more effectively. Signs around existing developments can get quite faded so the "Faded" conditions can help differentiate new from old.

The "game" options are for game use, these introduce an alternate 4k texture for the sign faces so using these conditions alongside other conditions doubles your sign texture use. If you are developing a game in which you intend to use these signs we suggest you read the Game Development section below.



Shine




The shine setting alters how much the sign glows when you face it. Its not a light based effect, its based on the direction you are looking at the sign compared to the signs direction. If you stand directly in front of the sign it will be at it's brightest. In some lighting conditions an unlit sign looks too dim so this brightens signs so they look more accurate.


Sign Face Selection




The drop down list can hold 256 entries so we've split the signs into two dropdowns. Each sign face has its own section in the Detail Panel. You can see that Condition and shine are universal to the whole sign and that Sign Face and Size are specific to each sign.



Sign Size




Uk round and triangular signs adhere to set sizes depending on how fast traffic approaches, the faster the speed of approach, the bigger the sign. All the signs can have their sizes changed according to this same formula and although its not physically accurate for the other types of signs its fairly close. If you need to further adjust sign sizes you can select the component by clicking on it twice after selecting the element and adjusting its scale transform manually.


Other Sign Blueprints


All other sign blueprints have two or more signs as its very common for UK road signs to have a symbol sign with a word sign underneath.


Position & Gap




The Position is the gap between the top of the post or frame and the top of the topmost sign. As UK sign positions use trigonometry to place signs at specific legal heights and poles come in standard heights and are then buried into holes in the ground, signs and poles often differ in where they thier top is.


The Gap is the gap between the bottom of the topmost sign and the top of the bottom sign. The default is 10cm which should be fine for most cases.


In addition to the size and gap, smaller signs are often on smaller poles so simply bury the pole in the floor to get the desired height.



All 400+ Signs










Game Development


This section is intended for you if you're looking to use these signs in a game or want to extend the options the blueprints offer. First we'll discuss the way we made the sign assets then we'll show you the workflow we used to change each type of asset smoothly.


We have made these signs primarily for Arch Vis but we know that if you are making a game and use these assets you will likely want to tweak them to fit your existing style. As the data is all held in spreadsheets it is really easy for non-artists to edit these files. Also we haven't added any fun or novelty signs, this is also something you may want to correct for use in a game.



Data Driven Blueprints


The sign data for the individual signs are held in *.CSV files (UE4 link to Data Driven gameplay), we found this was the simplest way to work with a large data set in Blueprints. The method we used for making these *.CSV files from scratch is in this Blog post.





Meshes


You'll find all the meshes in Content > ukRoadSigns > meshes. Due to the way uk road signs are designed based of the font's x height each sign is a slightly different size however the round and triangular ones are always the same size. For the round and triangular signs we use a number designation so we can have reversed and flipped signs, this allows us to make the most of our texture space for the sign icons.

Round and Triangle sign number designations:

  • SM_xxxx1_LOD0 is UV mapped top left to bottom right, 0 to 1 as normal and with a border
  • SM_xxxx2_LOD0 is horizontally flipped with a border
  • SM_xxxx3_LOD0 is vertically flipped with a border
  • SM_xxxx4_LOD0 is horizontally and vertically flipped with a border
  • SM_xxxx5_LOD0 is UV mapped normally without a border
  • SM_xxxx6_LOD0 is horizontally flipped without a border
  • SM_xxxx7_LOD0 is vertically flipped without a border
  • SM_xxxx8_LOD0 is horizontally and vertically flipped without a border

Only the designations used are present so neither round or triangular signs use all 8 mesh variations.

None of the square sign meshes use this, they are all individual and mapped normally. The square meshes used for each sign can be found in the ukRoadSignsData DataTable.

We have used up to 6 UV channels to control the masking and graphics on the signs. here is a list of the UV channels:

  1. (0) Sign face. In ukRoadSignsData Datatable we move the UV's of this channel around the T_signFaces_m texture
  2. (1) Light map channel
  3. (2) Mask the back/unprinted from the front/face of the sign. This refers to the T_borderBasic_m texture
  4. (3) Coordinates for the overlay dirt textures
  5. (4) Coordinates for the detail textures. This only includes T_reflectiveDetail_n
  6. (5) This for the border of round and triangular signs. This is most easily seen on the T_borderDamaged_m texture.



Textures


All the textures can be found in Content > ukRoadSigns > textures:




  • blank is used by M_Master_simple material to fill texture slots when a texture is not required
  • blank_nrm is used by M_Master_simple material to fill normal texture slots when a normal texture is not required
  • T_bracket_ao is the ambient occlusion map for the bracket which visually attaches signs to poles, its added to the diffuse in the material
  • T_bracket2_ao This is an alternate AO/color map used for the Game-style bright frame
  • T_bracket3_ao This is an alternate AO/rust map used for the Game-style frames
  • T_frame_ao is the ambient occlusion map for the roadworks frame. Added to the diffuse in the material
  • T_frame_n is the normal map for the roadworks frame
  • T_frame_Alt_m is for the frame roughness to distinguish between the sandbags and the metal. For dirtier (less reflective) versions this can be dispensed with in favour of a grunge map
  • T_poleCracks_MT is a mask for the pole and frame models which adds wear and tear via the metallic channel
  • T_poleCracks_n is a normal map for the pole model which adds wear and tear via the normal channel
  • T_reflectiveDetail_n is a normal map that simulates the retro reflective material and is present as default on all signs
  • T_weathering01_bc is the diffuse and roughness mask for general weathering
  • T_weathering02_bc is the diffuse and roughness mask for heavy dirty weathering

These next pair of textures are used to mask in the front faces of the signs. The masks have been packed into each of the RGBA channels then in the blueprint each mask channel is assigned a colour from the limited palette of sign colours to composite each sign face.

  • T_signFaces_mThis is the main mask for all the sign faces
  • T_signFacesDamaged_mThis is an alternate mask for all the sign faces for the "dilapidated" settings on the "Condition" drop down.

The next set of textures are used to mask the back from the front of the signs and mask in borders on triangular and circular signs.

  • T_borderAged_m adds small cracks or bumps around the edges of the sign faces
  • T_borderBasic_m is the clean/new version of this mask and forms the basis for the other two
  • T_borderDamaged_m adds significant scuffing around the sign edges as well as breaking up and fading borders


Materials


All the materials can be found in Content > ukRoadSigns > materials:




The materials on the sign faces are all dynamic instances of M_master_signsHi made in the Blueprints from material data held in the dataTables. This material is closely linked to the Blueprints and is not easily changed as the whole system relies on colour masking around this material.

  • M_master_simple is the base for the pole and frame

The materials below are used "as is" on the pole, frame and brackets. In the "condition" DataTable these materials (and the meshes) can be easily swapped for alternatives.

  • MI_pole_xxxx All the pole material instances for the different pole conditions
  • MI_frame_xxxx All the frame material instances for the different frame conditions

These material are used in the demonstration map to simply color the environment.

  • MI_sample_xxxx All the material instances for BSP volumes on the example map

The materials at the end of the list are all for material development and are not used directly. In the "Material Development" map these materials are assigned to raw assets to develop the material parameters and colors that are then added to the "condition" DataTable to be used for the sign faces.

  • MI_SigFace_xxxx Material and color development materials.




Blueprint Additional Files


All the supporting files can be found in Content > ukRoadSigns > blueprints alongside the blueprints.




Dealing with a large number of assets is cumbersome and memory hungry as there are so many signs. To deal with this most of the sign data is held in *.CSV files which we make up in Excel, import into UE4 as DataTables then use Blueprints to generate finished assets. We've written a blog post about how we do this *here*.


To edit the signs in any way you'll need to start with the DataTable files. There are 4 Datatables:

  • ukRoadSignConditionData This is how the sign looks. This holds the condition of the sign and color of the sign per condition. Edit this DataTable of you want to change how dirty the signs get; swap in different masks to make them more beaten up or want to change the RGB of each sign color. Unless you want to change the signs themselves this holds almost all the data about how the sign looks.
  • ukRoadSignsData This is the sign symbol/writing. This is the data for the sign face so if you swap in your own sign faces this is the file to edit. The colors used on the signs, you will see are named, this refers back to the Condition (above) where the names colors are specified as RGB values. Other values are UV coordinates and the mesh to us as well as if the sign is angled or flipped.
  • ukRoadSignShineData This just holds the material shine value. It's only in a DataTable for consistency as it only holds a single set of values.
  • ukRoadSignBracketData For the list of bracket objects for the back of the signs on the post.

Blueprints


We hope the sign Blueprints themselves are easy enough for you to follow with enough comments where you need them. Please engage us on the Epic forums if you have any questions **Add Link to thread here**. We'll add to this section or the FAQ section as we get feedback from the community.



FAQ

Are there LOD versions of the meshes? The meshes I can see are all postfixed with "LOD0".


No. We did look at LOD but decided that saving memory and draw calls was more important than saving polys as modern integrated graphics and some OEM graphics cards are more likely to be memory starved or have a low CPU-to-GFX transfer speed than struggle with rendering.


Will you make changes to this asset set in the future?


Yes. Obviously any bugs we discover or are reported to us will be fixed in a timely manner. If the community and/or Epic suggest a tweak that could improve the objective of the asset set we'll make changes (see objectives above). In addition we have made these assets because we use them ourselves in our work so if we find them lacking we'll introduce updates.


What about other street furniture? The roadworks sign on its own is a little thin on the ground.


Agreed. We looked at adding traffic lights, road cones and other items but the amount of work on the set would have ballooned which would have put the price up as well as move the focus from Arch Vis Signs, I doubt many Arch Vis scenes would look more beautiful with roadworks outside the window! We actually only expect the Sign-on-the-post to really get much use.

Thursday, 15 October 2015

String to Object Dilemma In Unreal Engine 4




A subject that often pops up on Epic's UE4 Answer Hub is the question of whether to reference assets in Blueprints via their name or a string. This is obviously not a good approach but why not and how do you get around it? I hope to answer both these questions for you.

Why Not Reference Asset by String?


When you make a variable in Blueprint or select a specific asset in a node you see its name. Although it looks to all intents and purposes the same as a string, its actually a pointer which can directly pinpoint the asset, component or variable in memory. A string is just a collection of characters which can represent the name, so Unreal has to read the string, convert it to a name and then go and find the reference.

So why is this an issue? Well let's picture the data of an Unreal project like a long street. You want to visit Mr MaterialAssetNamedMyMaterial, but all the houses look the same and there are thousands of them. An asset's name acting as a pointer is like having Mr MaterialAssetNamedMyMaterial's address in front of you, but if you just have a string containing his name you've got no option other than knocking on doors to try and find him. By the time you reach his house at number 5,654 time has ticked on quite substantially.

That sounds very much like a database search, and that's pretty much what it is. Game engine coders know that database searches are too slow to be effective for real-time, but this concept isn't quite so obvious to people like us - designers and artists - who use Blueprints rather than direct code, while those coming from the fields of web or app development will be used to database searching as part of how they work. In fact I ended up having to ask an experienced game coder.

So this is why Blueprints do not support references by name; otherwise the system would just crawl under the weight of data searches. However, the real problem in practice is when assets need to be referenced in Blueprints at scale. It's tedious enough manually adding a dozen objects but what about when adding hundreds? If referencing them by string is not an option, then there must be a another way to deal with large-scale data sets in Blueprint. Well, yes there is and Epic have given it to you.

Data Driven Elements


During development, game designers have to juggle a lot of variables, often make sweeping changes to test gameplay many times to get the elusive fun factor spot on. To save designers getting repetitive strain from having to modify large numbers of assets, there needs to be a way to enter, edit and manage sets of data easily and centrally. To facilitate this, UE4 gives you the ability to import CSV files, which can be created and edited in your favourite spreadsheet software then loaded into Unreal.

The data in these CSV files can be used to reference assets, variables and objects by name and handle their associated data; UE4 will automatically make a pointer for each asset for you when you import the CSV file.

Looking at the documentation seems to suggest you need some C++ experience to achieve this, but you can do this with just Blueprints.

How to Import a CSV File


First you need to tell UE4 what data to expect from the CSV file, so you need to make a Structure. Right click in the asset browser pane and select Blueprints > Structure.




Open the structure and you'll see that you can add variables in much the same way as you do in other Blueprints. Add a variable for each column of your spreadsheet data apart from the first column.

Take a look at the screenshots below. The first is the CSV file when loaded into UE4 and the second is the Structure derived from it. You can see that the first column in the CSV file isn't replicated in a Structure. Instead, it as a key to the data in the other columns. UE4 refers to these as the 'row names' and uses them as pointers to the specific rows in the CSV.



Some of the data types UE4 expects can be quite verbose so you may want to split the data down into simpler items then recombine them later in the Blueprint. Colors are a usual candidate for this, splitting them into Floats to represent the component red, green and blue values (plus alpha if required).


On the right hand side of the Structure you will see the default values for each variable appear, You can leave these empty.






When you import your CSV file (which we'll do in a minute) it will be turned into a DataTable. When the DataTable is created you'll want UE4 to make a pointer to your assets. If UE4 fails to make a pointer. what you see when you open the DataTable is "none" where the asset name should be.

UE4 seems to be good at finding some asset types itself but for others it needs help. If after importing your CSV file you have "none" where you should have an asset name, drag instances of the problem assets into the current map so they are present in the world, then reimport the CSV data, This helps UE4 locate the asset.


Next, import your CSV data in the same way you'd import a new mesh or texture.



You'll then be presented with the DataTable Options dialog. Select to Import as: DataTable then choose your Structure you made previously as the Table Row Type.



You will now see DataTable assets along with your Structure assets.





Working With CSV Data


Once you have some CSV data with asset pointers in place you can use Blueprints to implement the data in any way you like. Here are the Blueprint nodes that you'll need to use.




In your Blueprint, right click to bring up the nodes menu and type "data table" to see the DataTable nodes available.

A simple way to use a DataTable is to use the Get DataTable Row node to select a data table by name. This name is what's held in the first column of your CSV file (as mentioned above), the one that you didn't reference when you made the Structure Asset.

From the node output, you can then drag off a connection to Break <datatable name> which will give you access to all the juicy data in your CSV file without having to manually create lots of individual variables.

Shown below is a node which features data from part of our UK Sign asset set.




Last Word...


Before finishing this post, there's one point to note:

If you notice that reimporting a CSV file into UE4 isn't behaving like you'd expect, it could be because it will fail to reimport if Excel still has the file open. Epic are working on a fix for this but there is a sort of workaround.

If you work on a file saved in .xlsx format (which also allows you to colour code rows and the like), you can save it in CSV format and then save again as an .xlsx. This will disassociate the file that's open in Excel from the version in UE4, allowing you to freely import the CSV file into UE4.




Thursday, 8 October 2015

Early Lessons From Our Clients

The first products we produced at Leap Interactive functioned very much like game systems.  This simply means that they are controlled in the same way a game would be, with a controller. But whilst games are made for ‘gamers’ who are used to game controls, we make software for a variety of people, who aren’t always accustomed to them. Using a traditional game controller often represents a barrier for those not used to gaming. To explore this barrier we simply gave people the controllers to see what they made of them. This is how they responded:


‘I might break it!’

The first thing we found is many responded to the software the same way you might respond to driving a car for the first time. Clients tended to test the controls gingerly to try to get used to them, and if anything went wrong some people were instantly put off.

Our solution: To combat this nervousness we try to include as few controls as possible in order to make the software intuitive and very quick to learn.


Dizzy controller syndrome


Game controllers are comfortable to hold and easy to use, once you get accustomed to them. But no one can operate them instantly. In fact most console games feature ‘baby steps’ tutorials that introduce one control at a time. Without this, a common reaction to being given a traditional games controller for the first time is to press both thumb sticks forward, which usually results in the camera looking up at the sky while blindly running forward. Now visually at sea, the next step is often to wiggle the thumb sticks in an attempt to figure out what’s gone wrong, inducing what we like to call ‘dizzy controller syndrome’.

Our Solution: By adopting systems that people are becoming increasingly familiar with, such as touch screens, we make interactivity far more direct and much less disorientating.


The mouse effect

Anyone who has played a first person shooter game will know that the trusty mouse gives you exactly the precise control you need to excel. It is comfortable and allows you to turn quickly and move freely, unrestricted by the often sluggish speed imposed by using key presses. However, as with many game-like controls, when people are first try to navigate through our simulations with a mouse they often find movement hard to manage. By design mouse controls are very sensitive; so the faster you move it the further across the screen you will travel. This means, again, you can easily find yourself stuck staring at the sky or your own feet.

Our solution: When mouse control is required, we limit the speed of movement and add auto-centering to make sure the viewer can easily reorient themselves and ease themselves into the feel of the control.

Bad buttons

We soon learned that, if you’re going to give someone a controller, you need to make sure that everything on the controller is necessary for their 3D experience.  For instance, accidentally pressing a button that drops to the main menu would break them out of the interactive experience, while the pause gives them the opportunity to leave rather than making the effort to navigate back to the 3D scene.

Our solution: We ensure that the only functional buttons on the controllers are ones that contribute to and enhance the client’s 3D experience.

With the added complexity of a third dimension, changes must to be made to the way we use controllers. Because people can’t press their finger through the screen, most widely available 2D control devices such as mice struggle to convey 3D movement. This is a perennial problem that User Experience designers like us slave over; there are tonnes of new ways of controlling 3D software. Wii and Xbox Kinect controllers are two great examples of how how designers are attempting to replicate real 3D movement into virtual 3D navigation. This kind of revolutionary technology that not only adapts to but enhances 3D movement, is exactly what we are implementing for our 3D visualisations.


Monday, 20 July 2015

What We Do And Why

At Leap Interactive, we bring real time technology out of games and into the real world. We realised the potential of games technology to benefit other industries and - along with the new generation of renderers - we can now achieve the visual fidelity of Architectural Visualisation Movies.

The most obvious place to take this technology is into the architecture industry, because games and architecture actually have a lot in common. Despite their aesthetic differences, both industries involve design, artwork, lighting and atmosphere and both professions also tend to experience similar hurdles. So what we aim to do is bring the benefits of games into architecture. By removing the guns from the shooting games that kids play with gamers across the world, the same technology can also be used by professionals to communicate remotely, and intuitively analyse a virtual 3D environment.

Indeed, the real time graphics used in the games industry offer many selling points that AV movies can’t. Because movies are made up of sets they don’t allow you to truly experience a place, whereas real time technology is a reactive piece of software. This means it is interactive, immersing and full of possibility.

With real time you can:
·   Turn lights on and off,
·   Remove roofs,
·   Change the environment e.g. weather and time of day,
·   Move furniture,
·   Change wall colours.

This list is definitely not exhaustive as there are a whole host of other ways real time technology can enhance your experience of a virtual 3D environment. This makes it a very effective selling tool for marketing completed, fully furnished properties to clients, as it allows them to virtually experience the finished building before it is constructed. Because games are very immersive and concerned with user experience, we know from our expertise gained in the games industry how to bring a virtual environment to life.

We also understand how important it is to be able to accurately communicate a creative vision, which means we are familiar with the challenges involved. When making games, you have to be able to not only make wonderful-looking environments, but iterate changes quickly without adversely affecting the visuals. With AV movies, this would mean rebuilding, reanimating and re-rendering - a costly and time-consuming process.

Why now?


Games technology has always pushed the boundaries of what machines are capable of. Which is why graphics chip manufacturers work in tandem with the people who actually make the games. Games continuously strive to look real and now graphics cards are powerful enough to mimic the lighting you get in offline renderers like MentalRay and VRay. The power and availability of this new technology makes a vast difference to the visuals and opens up the potential of games technology to other fields.

Why us?


Expressing a real space via static images or plans is a very difficult prospect and is a concept that many can't easily grasp.The best way to communicate something that doesn’t exist yet is physically showing people. Real time games technology makes this possible, even if that space doesn’t yet exist, allowing potential buyers to visualise the property before they buy it.