The textures are still highly unoptimised. I’m aiming for a max of 20Mb download for the whole site with roughly 2k texture sizes. Most are PNG currently, so I need to extract them out and compress and resize them to JPEG. I can almost reduce the initial download size that way. It will work wonders for the rendering performance as well, as between poly count and texture size the site is breaking older mobile devices currently. I’m planning a quick performance bench while the site is loading as well, to provide a traditional 2D option as well and recommend either 2D or 3D based on the bench results. The user would be able to switch between the 2 views via a toggle at any time though…
EDIT: One of my biggest challenges so far was having seamless transitions between any 2 scenes, even allowing the user to load in on any scene / page given a URL. That and lighting / shadows. My word, getting the right balance of lights, shadows, ambient occlusion and bloom to let each scene “work” with the same set of lights is immensely challenging, frustrating and rewarding.
Thanks, it’s been a long, iterative and expensive process. We started with very high detail “low poly” models, tried to cut and reduce details to browsers as targets and ended up redoing them all with low poly and performance in mind. Our target was not more than 10k poly’s per model, except for the final “sky city” which we couldn’t get below 18k odd. I’m quite excited about the characters being added in soon, as they really give life to the site.
It probably also doesn’t help that I’m pedantic as hell and had this vision in my head which I couldn’t get people to execute correctly. So I took over earlier this year and made it my pet project during off-peak hours.
Nope, actually a normal map not linked correctly on the model itself. We’ve had several of these issues on the model exports and I received the redone airship only this morning, so it needs some tweaking still.
This project has been gnawing at me for months now, so I decided to just push forward and get as much done as I can. The eventual plan is to gamify the website where you assemble your crew of 3 from 6 possible characters, customise your airship with various parts and then play through an optional mini-game to get to the final “city in the sky”.
The whole thing is a metaphor for the typical process we go through in tackling a project: assembling the right team, picking the right tools for the job, struggling through hazards while building the project and eventually relishing in the splendor of a well-built project. Unfortunately the mini-game will have to wait until later this year, as I have a strict deadline to get this done before the next SA Innovation Summit, where we’ve been asked to present a “master class” on a topic of our own choosing. It’s probably quite apt that our slogan has always been “master” software crafters?
It already shows and I could see that just by simply browsing and scanning the site. Some of the best designs and processes are told through a story, and the site does this and does it well.
Oops - seems like I wasn’t aware of yet another character added to the ensemble cast! Here are the current crop of crew you would be able to recruit on the site:
EDIT 1: We’re also planning some t-shirts and hoodies each featuring the characters in their unique setting, so I’ll keep everyone here posted if they’d be interested to place an order for one.
EDIT 2: Each of the characters also represent the roles we typically need to fill on a project, i.e. engineer (droid), team lead (captain), project management (navigator), artist (musician), architect (holding the scroll), builders (strong-man) and, every so often, someone who just has a little bit of a magic touch in the project (alchemist).
So I’ve been making some huge improvements to asset (model and texture) management of the site, including disposing all assets not currently in view of the camera. This has proven to be a major headache, but has allowed me to gain some significant performance boons on the site. The previous deployment happily crashed iOS browsers, due to high CPU and RAM usage. The new deployment has cut RAM usage by 80% and CPU usage by 65-70%.
I’m still optimising it when I take a break from normal work and especially want to find a solution to the render hitch that happens when a new scene transitions in and the previous scene’s assets are disposed. All our scenes (including the airship) are now optimised for website use (with an average 40% cut in polygons and vertices), with the characters now receiving some TLC. I also improved lighting considerably, including a candlelight flicker to the contact scene. There’s also a quality toggle at the top-right so I can test various pixel ratios and AA settings to find the optimal balance between fidelity and performance on a host of devices. I’ll continue posting updates here when I have something noteworthy to mention.
Lesson learned: WebGL (with Three.js specifically) is still quite in its infancy. The resources online seem sufficient, but really aren’t. There is still a lot of trial and error involved in getting anything substantial done. I’ve learned a ton of its quirks and how to optimise meshes and rendering. All in all it’s been a worthwhile journey and I’m confident that we can start expanding our UX offerings to include 3D digital experiences. We’re trialing the new offer at a client currently to see how successful it is and will adjust our pricing / delivery times accordingly. Next experiment is using WebXR (augmented- and virtual reality) using Three.js. My Quest 2 will come in handy for testing!
Site link (again) for those who want to test. Bear in mind the content is still placeholder stuff and I will start working on it next week after the scenes are optimised.
Looking back on the original Space Jam website, circa 1996. I can’t believe this is where we started, not only that, but we were okay with that. You can clearly see what sort of generation it comes from just by looking at its design implementations. Oh how far we have come.