On February 20th, Decentraland was opened to the public. For those who don't know, Decentraland is a virtual world that is supported by Ethereum'sblockchain, where its community defines the utility and aesthetics of its parcels, creating an innovative and dynamic relationship between owners and visitors. Under this premise, the only limit is imagination.
We had the opportunity to be part of the development of content for several parcels before the launch, from labyrinthine adventures and experimental sound art to art galleries, gardens, and even a transportation system. Shaping the future of virtual transportation, today we show you how we created the Trail Transit System in the south of Decentraland from start to finish, the day before the launch.
Decentraland aims high with its innovative concept, where the creations that users create, own, and control their designs from the blockchain stand out. This step-by-step of the project can help designers, users, and Decentraland colleagues understand the creative process or even serve as an introduction to new content creators.
For this workflow, at Polygonal Mind we have used a plugin for Unity that you can find onGitHub. This plugin has allowed us to work natively in Unity, compose and create scenes without touching too much code. It is important to emphasize that we have not used exactly the same version that you can download from the link above, the plugin has been modified to get the most out of it in our particular case and for our needs, improving its performance and preparing it for the DCL graphics engine.
Each project requires a different approach and a different production pipeline, which is why the plugin was modified as we encountered different challenges and technical issues, mainly related to performance once deployed in Decentraland.
#00 - Basic concepts of a transportation system
The initial idea was to create a modern transportation system that fit into a series of parcels in Decentraland, with interesting stops between the start and the end.
When Daniel and I started taking the first steps, we encountered some interesting challenges.
How was the train going to stop?
How will users get on the platform?
Should the train turn around to go back to the beginning?
The initial sketches considered having two levels of height to create connections between plots.
As soon as we began to define all the work we had to do on paper, we decided to lean towards making the entire environment a megalithic structure with an elevator that could be accessed from the ground. The problem of the train turning when it returned was solved by having two cars going in opposite directions to avoid having to wait too long for a train. This created a visual and design problem: we needed 4 platforms per level and these levels had to be connected, so that the user could freely climb throughout the structure.
I created a visual mood board and proposed it as the basis for the entire visual aspect in order to start with the first designs. For the artistic style, I was greatly inspired by the environments and artistic design of Bioshock, and the transportation system of Fallout 4. Both games have a significant influence on retrofuturism, but rely on different artistic styles. Bioshock has beautiful environments, heavily influenced by Art-Deco, mixed with monumental wrought iron environments. Regarding Fallout 4, it has a well-built world based on futurism from the eyes of people in the 50s and 60s, full of details.
This became the main reference and inspiration for the shape, color palette, and functionality as a train.
Bioshock masterfully uses metal pipes in its environments and this was a decisive inspiration for me when we decided to take our own approach to the art-deco environment.
Once the limits of art were established, we could start working. Let's break down how the assets were created, starting with the first version of the train, the one that goes on top of the rail; followed by the design of the station and its integration with its surroundings. And last but not least, we will show the iteration with the second train, the one located under the rail.
*Bioshock, developed by 2K Boston / Irrational Games and published by Take Two.
**Fallout 4, developed by Bethesda Game Studios and published by Bethesda Softworks.
#01 The Train: Shaping the Virtual Wagon
For a plot of 55 parcels, the scene limitations were quite strict considering that the environment was basically a train system. Therefore, we opted for a high-polygon mesh level of detail instead of a more blocky low-resolution shape resolution, with a maximum of 550k tris, 116 materials, and 58 textures (512 square max) to be implemented throughout the scene.
The resulting design, based on a single image, perfectly fit our vision for the environment's "feeling." However, during development, we encountered issues because the image was hand-drawn without any real reference and with a forced perspective of a view from the future during the 1950s.
As the design progressed, problems began to manifest in the wheel area (because it deformed the main structure) and how the train was going to move on the rail. This led to a design change, favoring a larger and more streamlined wheel cover, and a wider rail that adapted to a new, also wider wheel.
If we go inside, we can observe that the design of the wagon is based on concepts from the 50s and the use of contrast between wood and iron. The most complicated part was giving "controls" to the train, which means that it was necessary to include a control panel or something similar, with levers and buttons.
Material design consists of using mainly two materials, one for the exterior and another for the interior props, and an extra one for the emissive that the control panel had. Again, the lack of content since the plots were going to function as a transportation system meant that we could dedicate more care, detail, and resources, with the limit of 512x512px textures. After a few iterations, we had our first model of the train traveling on the rail and ready to perform the first tests.
#02 The Station: A Balance Between Composition and Utility
As we mentioned before, the station had to have two levels of platforms: one at 16 meters with connections on both sides of the plot and another at a height of 32 meters. All platforms had to be connected in one way or another to be playable for the players and it had to be easy to turn to the opposite side in case you missed a stop, like in a real metro system.
Additionally, from an artistic point of view, the idea was to avoid using stairs or long paths as much as possible to fit with the more mechanical and futuristic vision of what transportation should be that we had. Taking the environments of Bioshock and concept art as an example in materials and composition, I started making the first sketches of what the station would look like.
I began defining the elevator design, based on how Bioshock uses art-deco mixed with steampunk for its elevators. I decided to follow a similar design from 0 to the final look of the model. The design ended up being open concept and without walls, to avoid claustrophobia and to serve as a reference point for model and material detail.
From the beginning, I wanted to create a mechanical opening and closing system for the elevator, so I started planning how the animation would be. I had to take into account where the pivots had to be and how the hierarchy should be so that the animation runs correctly.
Once the elevator was finished and placed in its final position, the casing was installed around it to allow access to the elevator. The platforms began to take shape.
We started developing the platforms with an idea of how they were going to function from a gameplay perspective, so it was crucial to design how the station was going to be played and experienced by the player first. So, I made a level design or graybox defining the playable boundaries and anticipating the visual part that would come later and all the problems that could come up later, and that's how we found and dealt with the connection problems between the floor and the 16-meter platform, as well as other problems that complicated the visual integration of the entire set.
One of the original problems we had was the large gap between the entrance and the upper and lower platforms, with the added issue of the narrowness of the plot.
The first block out was completed using the avatar model as a reference for size. However, we also had to take into account the camera's Field of View as an additional limiting factor. The second train was still on the "to do" list, so we had no idea of its actual scale. Therefore, I took the top rail and placed it underneath as a block out.
Following the original idea, the concept was to elevate the user from the 16-meter platform to the 32-meter platform with an elevator located on top of the upper platform. However, this made us realize all the visual integration and gameplay problems, and we quickly decided to discard it because it overloaded the scene with polygons. Instead, we found the solution in a platform between the two main platforms.
With the final touches completed, it was time to paint and design the materials. I decided to use seamless tileable textures for larger objects, as it would give me more control over the details. For the platforms and elevator, I made their UVs and packed them into an atlas, maximizing control over the detail and improving the graphics. We also utilized the metalness/smoothness channel to make the environment shine naturally.
Normal maps are really helpful in giving a very defined detail to a very large structure
#03 The Second Train: Reinventing the Same Concept
Once the stations were placed and operational, it was time to incorporate a second train to the rail. This design was planned to be suspended from the same rail as the original car but with clearly apparent modifications.
The main limitation for remodeling the exterior was to maintain the UVs so as not to have to redo the texturing, because both trains use the same materials.
#04 Limits in materials and asset optimization
The trains were finished and placed in their place, the stations were in their final position and the first tests were giving good results, because for this project we decided to use a prefab approach, and A. Picazo, our programmer, suggested and implemented some modifications to the plugin to recognize the same meshes and instantiate them instead of exporting each one of them individually as different GLTFs.
We use a single rock model and constantly reuse it by changing the rotation and scale to make it appear unique. The same goes for stations, as the GLTF of the station only loads once and is copied three times at runtime.
Overall performance improved greatly and it was time to cut back a bit on textures, not because it was really necessary, but because it's always a good idea to revisit the work done and improve or delete irrelevant files. As I delved deeper into the relationship between texture usage and final result, I concluded that Normal maps were not really necessary to achieve the look we were going for. This is because Decentraland's ambient light kills this kind of micro-detail and directional light doesn't really help in these situations. So, Normal maps were removed from all materials that didn't need to simulate bump information.
Microdetail normal maps such as ground and dirt were removed because any impact they had was minimized by the ambient light.
I must say that one thing that really helped us achieve the high level of graphics in this scene was the use of the metallic/smoothness channel. This provided a subtle shine without being visually intrusive, unlike the glow channel.
As you can see, the Smoothness channel gives the normal map a perfect tone.
Texture ORM Packing in Decentraland
Decentraland recommends optimizing textures using RGB textures packed as ORM (Occlusion, Roughness, Metalness). It's a good idea when working with a PBR workflow, but for this project, we avoid using "Ambient Occlusion" and instead bake it into the albedo with a "Multiply blend mode". More information on this type of texture can be found in the Khronos Group documentation: https://www.khronos.org/blog/art-pipeline-for-gltf
Colliders in Decentraland are created by superimposing a mesh on the model you want to have collision and adding the suffix "_collider" (in lowercase, VERY IMPORTANT) to the name of the mesh you want to use as a collider. It is important not to have the same name twice in the same hierarchy or having a parent and child with the same name would cause the GLTF export to crash. Hierarchy and naming conventions are very important.
As far as performance is concerned, I recommend using a low-res version of the mesh when creating the collider because Decentraland creates "Mesh Colliders" based on the mesh with the suffix I mentioned earlier. If you are familiar with Unity, you will know that "Mesh Colliders" are not suitable for complex scenes, and it is best to avoid colliders with very complex shapes and try to make their boundaries.
Basic problems when using Unity workflow
Decentraland runs on a modified version of the Unity engine with modifications focused on its current and future platform features. This is good because you can see how your project is coming along in real time within Unity, and how similar it will look once deployed. However, there are significant visual differences due to Ambient Light and Directional Light within Decentraland.
Despite the efficiency improvement, doing so means that working with the Unity editor has two limitations to keep in mind.
Most components will not be exported by the GLTF format and therefore will not be visible after deployment: particle systems, lights, cameras, 2D components, colliders, and vfx will not work. GLTFs only allow you to have mesh renderer, materials, and a limited Animator functionality.It should be noted that the X axis in Unity is flipped and can lead to placing things out of place, because DCL does not have the inverted axis.
X = -X
In addition, the exporter does not work well with very large scenes and can cause the editor to slow down. It is recommended to have the DCL plugin hidden while editing large scenes and open it to evaluate the entities and keep in mind if you are exceeding the limits of the parcel.
As soon as the main stations were in place and the transportation was functional, it was time to develop the surrounding ground. I opted for something almost desert-like, without plants, because I wanted to avoid going overboard with polygons and wanted to improve the detail of the train experience, not worsen it.
Here's what we decided to do: the rocky environment was detailed with some resting areas and pipes decorating the paths. The resting areas reuse textures from the station props. Three more materials were created for dirt, rocks, and crystal structures.
#06 Final Touches
During the final part of development and with Decentraland's launch around the corner, KnownOrigin decided to host the art that would be displayed on the structures for the public to see. A limited number of pieces were selected to be placed along the rail, allowing them to be seen while traveling on the train from one station to another and while waiting for the train.
Two examples of NFT cryptoart from KnownOrigin placed at the station. Users can contemplate the cryptoart while waiting for the train.
This environment was a huge challenge for the team, because we needed to develop a customized system for the train to move and stop at all the stops. All my congratulations to A. Picazo for making it look so beautiful. For me, who was in charge of the entire environment, it meant a lot because I was able to bring to life a great design based on two games and an artistic style that I love.
In addition, there were limited graphics resources because we ended up reusing many assets, but without making the composition boring or repetitive. This gave me the freedom to improve the appearance by adding geometry and approaching a realistic material design, giving an extra touch of detail to a platform where flat shading and low poly reign in the environments like Decentraland.