Been doing some research into browser support for the checkbox hack.
Seems really good other than a strange bug with Android 2.3.
Android 2.3 currently has ~20% market share so it’s still pretty high and could be a potential problem to consider. However the share has dropped by 8% in the last 30 days, so hopefully that will continue.
There is what is mainly a monologue about the issue here:
And the hacky solution here:
The header has been completed and implemented.
There were some issues with the user menu (in the top right) where when you hovered over the image the arrow did not activate the hover effect. So I wrapped both of the elements in a wrapper div so that the child divs hover effect work when hovering other either element.
The branch has now been merged into master.
Here is the result of using the plugin and making a city.
The results are fine however there are some issues with it. The number one issue is that it might be too big and therefore might not be suitable to inject into browser.
After further testing we have decided not to use this model. It is not very efficient to create detail while maintaining a fast render able speed in the browser.
Regardless of this not being used it was still a necessary test to bench mark what models could and could not be rendered in the browser.
The Environment pages on the website are perhaps the most important pages to the project. They host a large percentage of the “cool” and cutting-edge technology that we are aiming to showcase.
This environment pages are going to showcase:
- The 3D Environment Model in different views - 360 degrees, top, side, live (timelapse) view
- The different ways of interacting with it - Webcam gestures and keyboard etc.
- Information about the environment - Graphs or textual information.
We also decided that these pages should probably look relatively different to the other areas of the website. For example, the homepage, which is going to be a more traditional looking webpage. The environment pages are going to look more like an interface, with many buttons, data and different ways of interacting with it.
Based on what we decided the purpose of the environment pages were I set about designing it. I started with the desktop full-width design as I felt this was easier to visual as an interface style design. I chose to make the max-width 1400px which was 200px more than the maximum width on the rest of the website as it would set it apart from the rest of the website and make it look more like a bespoke interface for the environment. However, whilst making it stand apart from the other areas of the website I didn’t want it to look like a completely different website. So I made sure I fulfilled our look and feel decisions of a flat UI style.
This was the result of a few hours designing and feedback from James and Joe:
Now that we had a base design for the page in desktop, the next challenge was to think about how to design this for mobile first.
We drew some sketches of how the mobile layout could look, removing pieces of the desktop design that we felt were not completely necessary or may have affected performance on mobile more than was justifiable.
Once we had decided on how we wanted the mobile layout to look we thought about how we were going to organise the HTML markup of the page into a hierarchical structure. Starting by numbering the importance of certain parts of the page, with the lowest being most important and the highest being the least important.
This would then translate into how the HTML markup would be written, features of the design that are removed in mobile would be at the bottom of the markup and parts that were there throughout the page from mobile to desktop would be at the top of the markup. Whilst also taking into account how elements have to be re-positioned and moved from one CSS breakpoint to another using CSS but without the ability to re-order any HTML markup.
Some of the early HTML markup for the environment page:
What is SVG?
SVG, or Scalable Vector Graphics, is a XML-style markup driven vector graphic rendering engine for the browser. SVG is supported in every browser, except IE < v9 and Android < v3.
Why use SVG?
When you use images in an html document with the tag, you are defining a file that the user’s browser will request. This request will take up bandwidth and require more precious time to download. If your image is instead a set of dom nodes, it cuts that extra HTTP request out, making your website faster and more user friendly.
It also allows us to be more collaborative with the sprites on the website. I created a SVG sprite sheet and all the sprites will be contained in this one document. This makes it easier if the time comes that we need to edit a certain sprite as we just have this one document. It also makes it easier when writing image paths as it should be the same path for every sprite.
SVG also offers a way to do full resolution graphical elements, no matter what size screen, what zoom level, or what resolution your user’s device has. Which allows us to only ever make one version of the sprite in question. We may well do some image fall backs for browsers that don’t support SVG but as that is IE 8 and below we might not even cater for this browser so this might not even be an issue.
How does it work
Using an SVG works quite a lot like using any other image. You firstly define the size and the url.
background: url("/img/sprite.png") -200px 0;
Then using the two numbers after the url you can locate and position the specific sprite.
Our sprite sheet is as systematic as it possibly can at the moment. All the header sprites (which is at the top of the webpage) start in the top left of the sprite sheet and move across to the right. Additional sprites for other pages when added to the sheet will start their own line.
We decided that when showing off models in the environment view it would be great if we had a variety of different things to give variation to the presentation of the 3D model. We want to be able to show off structures and models of different varieties and one way we can do this is using a particular plug in for 3DS Max called Greeble.
What is Greeble?
Greeble is a plugin for adding fine detailing to the surface of any object to make it appear more complex. It avoids the time consuming work of manually creating large numbers of precise geometry. It sub divides the surfaces into smaller areas and therefore adds more detail. The maximum and minimum height can be set so that you can generate a look and feel that is right for the purpose you need it for.
Why are we using Greeble?
We will be able to use Greeble to generate a city very quickly. Then we can select faces and asign textures to individual surfaces to be able to rapidly texture the city.
How does it work?
It’s a very simple process to set up the initial visual city. First you create your chosen object (which in our case will be a plane) and then set the number of length and width segments. Being able to set our own width and length segments is a huge benefit to us as we will be able to control the poly count to help the FPS as James as sated in a previous blog post.
We can then select the Greeble modifier and customize the maximum and minimum height to create our chosen look. Texturing can then take place and this is a simple process as well. The tops and sides can also be selected separately and be given a new material ID so a multi sub object can be created for texturing. A MaterialbyElement modifier can then be applied so that multiple textures can be used for the sides of the building and this will also randomize where the textures are. This is usuful for making the city look more realistic and not just all the same.
Considering the code required to simply load a 3D OBJ file into the browser amounts to a whopping 450KB, we are having to be very careful about the rest of the data we are loading into the page. Specifically, the size of the 3D models and how that affects the performance of WebGL.
I start off with this 100 poly “mountain scene”.
The OBJ file for this model is 14KB. A pretty decent size for the web but not a very smooth looking model. The WebGL performance is of course pretty good at 63fps.
I then decided to push the upper limits, turn on the Turbosmooth modifier and crank up the iterations to 6. This produced me a baby smooth 820,000 poly model.
The exported OBJ is 64MB! Not something we imagine having to download on a wifi connection, let alone a limited 3G one. It took ~9 seconds on my sandbox environment!
Considering the massive file size increase, I was pleasantly surprised to see that the WebGL performance only dropped by 3fps to 60.
Dropping the Turbosmooth iterations down 2 produces a relatively smooth model (undistinguishable without a comparison) with 3,200 polys at 218KB. Still quite a large file but not quite as much as 64MB.
The fps also has increased back up to 63fps.
Some things we may need to consider is providing visual feedback in the form of a spinner or preloader while the OBJ is loading and potentially showing a warning message declaring that this page is going to be bandwidth heavy.