|
Why do I need to modify the Unity plugin? Using the Decentraland SDK to place entities "manually" in the typescript code may be a slow and tedious process, especially if you have to put a lot of them and you have to look one by one if they are in the right place. That's why you have tools to help you build a scene, like the Decentraland builder or the Unity to DCL export plugin. However there are a limited set of things you can do with them. In this guide we'll see how to make custom modifications to the Unity plugin for DCL to expand the number of things you can export to code from the Unity scene editor. Before starting with this guide you should have a minimun knowledge of the Decentraland SDK, the basics of how to export a scene from unity to DCL and some programing basics (we'll use typescript and C#).
 Prepare your Typescript project
It isn't necessary to make a custom component to place an NFTShape (which is already a component), but for the sake of the guide we'll do it anyway, besides it will be useful for you as a base to make your own more complex components. Before start writing code in your game.ts file, be aware that the Unity export plugin will ovewrite the entire game.ts file and your code will be lost, because of this we need to work in a separate file. Create a new file src/imports/components/NFT.ts with the following code: //Creates an NFTShape component with the given info export function createNFTComponent(entity: IEntity, smartContract: string, tokenId: string){ entity.addComponent( new NFTShape('ethereum://'+smartContract+'/'+tokenId,Color3.Blue()) ) } //Add a NFTdata component to the entity, creates an NFT component with the given info @Component('NFTdata') export class NFTdata{ entity: IEntity //entity of the NFT smartContract: string //Smart contract of the NFT tokenId: string //Token ID of the NFT constructor(entity: IEntity, smartContract: string, tokenId: string){ this.entity = entity this.smartContract = smartContract this.tokenId = tokenId createNFTComponent(entity, smartContract, tokenId) } } And another one src/imports/index.ts with: export { NFTdata, createNFTComponent } from "./components/NFT" Now we have our code ready for when our modified plugin exports the game.ts Make a Unity script to hold the data to export Create a empty script in Unity and open it in visual studio (or your favorite code editor).  You only need to store here the NFT address info for this guide, but fell free to add anything you need for your project. public class nft_script : MonoBehaviour { public string smartContract; public string tokenId; }
Now we have the data stored in our entity, the only step left is to modify the plugin to translate this data to our project in typescript. Modify the Unity plugin in C# Modifing the plugin may seem like an overwhelming task, but keep in mind we only need to add our little pieces of code in it and expand its functionalities, simple if you know where to do it. Open SceneTraverser.cs in the Decentraland plugin folder: Assets/Decentraland/SceneTraverser.cs Find the public static ResourceRecorder TraverseAllScene function and add the following code after the comment //====== Start Traversing ====== //====== Start Traversing ====== if (exportStr != null) { exportStr.AppendLine("import { NFTdata } from \"./imports/index\"\n\n"); } This will import our NFTdata class at the start of game.ts Next find the public static void RecursivelyTraverseTransform function and after exportStr.AppendFormat(NewEntityWithName, entityName, tra.name); add this code: nft_script nftObject = (tra.gameObject.GetComponent("nft_script") as nft_script); if (nftObject) { exportStr.AppendFormat(SetNFT, entityName, nftObject.smartContract, nftObject.tokenId); } Last step, find the place where the export strings are declared and add the SetNFT string at the end.  private const string SetNFT = "{0}.addComponent(new NFTdata({0}, \"{1}\", \"{2}\")) \n"; This code will check if the exported entity has an nft_script and will add the NFT data component to the entity in our game.ts file. With all done your scene is ready to be exported to a typescript project and your resulting game.ts should look like this: import { NFTdata } from "./imports/index" var entity1372n = new Entity("NFTentity") entity1372n.addComponent(new NFTdata(entity1372n, "0x06012c8cf97BEaD5deAe237070F9587f8E7A266d", "558536")) engine.addEntity(entity1372n) entity1372n.addComponent(new Transform({ position: new Vector3(6, 1.5, 6) })) entity1372n.getComponent(Transform).rotation.set(0, 0, 0, 1) entity1372n.getComponent(Transform).scale.set(1, 1, 1) Final tips You can access from anywhere in the project to an array of entities with your custom components, this can be usefull to control where and how some components or behaviours start. engine.getEntitiesWithComponent(NFTdata) You don't need to make complex new components if you don't have to, for example you can export from unity only the info to put an entity in an array and apply to them a custom behaviour. Before start making your componets, take a look at the decentraland sdk and the decentraland utils library, they may have what you are looking for. ECS API Reference: decentraland-ecs-utils: npm install decentraland-ecs-utils Conclusion If you have understood the steps done in this guide, you are ready now to make your own components for decentraland and place them using the Unity editor, this will be very usefull to fill your scenes with gameplay and interaction. I hope it makes your development process for decentraland easier.
0 Comments
 Decentraland official documentation Libraries and imports You need to install in your typescript project the eth-connect library, to interface with Ethereum contracts and call their functions. npm install eth-connect Also, you will need to import the following functions in your file. getUserAccount to obtain the user's ethereum address. getProvider to create an instance of the web3 provider to interface with Metamask. getUserAccount and getProvider are provided by the decentraland SDK. import { getProvider } from '@decentraland/web3-provider' import { getUserAccount } from '@decentraland/EthereumController' import * as EthConnect from '../node_modules/eth-connect/esm' For this libraries to work in the DCL localhost preview, you'll need to paste &ENABLE_WEB3 to the url, example: http://192.168.0.112:8000/?SCENE_DEBUG_PANEL&position=12%2C44&ENABLE_WEB3 Important information needed before start To perform a MANA payment you need to gather some info. Ethereum address to pay the mana, this will be the address that will recive the MANA from the user's payments. example: const PAYMENT_ADDRESS ="0x4tU......8dY" MANA units you want the user to pay example: const MANA_PAYMENT = 10 The MANA ethereum contract address const MANA_ADDRESS = "0x0F5D2fB29fb7d3CFeE444a200298f468908cC942" Fake MANA contract address (optional), only if you want to do test transations with Fake MANA const FAKE_MANA_ADDRESS = "0x2a8fd99c19271f4f04b1b7b9c4f7cf264b626edb" The MANA contract ABI Create a empty file inside your project, "/contracts/mana.ts" and paste the MANA ABI in export const abi, or paste the contents of this file. export const abi = [{"constant":true,"inputs":[],"name":"mintingFinished","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"name","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_spender","type":"address"},{"name":"_value","type":"uint256"}],"name":"approve","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"totalSupply","outputs":[{"name":"","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_from","type":"address"},{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transferFrom","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"decimals","outputs":[{"name":"","type":"uint8"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"unpause","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_amount","type":"uint256"}],"name":"mint","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_value","type":"uint256"}],"name":"burn","outputs":[],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"paused","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"}],"name":"balanceOf","outputs":[{"name":"balance","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"finishMinting","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":false,"inputs":[],"name":"pause","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"owner","outputs":[{"name":"","type":"address"}],"payable":false,"type":"function"},{"constant":true,"inputs":[],"name":"symbol","outputs":[{"name":"","type":"string"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"_to","type":"address"},{"name":"_value","type":"uint256"}],"name":"transfer","outputs":[{"name":"","type":"bool"}],"payable":false,"type":"function"},{"constant":true,"inputs":[{"name":"_owner","type":"address"},{"name":"_spender","type":"address"}],"name":"allowance","outputs":[{"name":"remaining","type":"uint256"}],"payable":false,"type":"function"},{"constant":false,"inputs":[{"name":"newOwner","type":"address"}],"name":"transferOwnership","outputs":[],"payable":false,"type":"function"},{"anonymous":false,"inputs":[{"indexed":true,"name":"to","type":"address"},{"indexed":false,"name":"amount","type":"uint256"}],"name":"Mint","type":"event"},{"anonymous":false,"inputs":[],"name":"MintFinished","type":"event"},{"anonymous":false,"inputs":[],"name":"Pause","type":"event"},{"anonymous":false,"inputs":[],"name":"Unpause","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"burner","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Burn","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"owner","type":"address"},{"indexed":true,"name":"spender","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Approval","type":"event"},{"anonymous":false,"inputs":[{"indexed":true,"name":"from","type":"address"},{"indexed":true,"name":"to","type":"address"},{"indexed":false,"name":"value","type":"uint256"}],"name":"Transfer","type":"event"} Fake MANA contract ABI (optional) export const abi = [ { constant: true, inputs: [], name: 'mintingFinished', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'name', outputs: [ { name: '', type: 'string' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: '_spender', type: 'address' }, { name: '_value', type: 'uint256' } ], name: 'approve', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'totalSupply', outputs: [ { name: '', type: 'uint256' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: '_from', type: 'address' }, { name: '_to', type: 'address' }, { name: '_value', type: 'uint256' } ], name: 'transferFrom', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'decimals', outputs: [ { name: '', type: 'uint8' } ], payable: false, type: 'function' }, { constant: false, inputs: [], name: 'unpause', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: '_to', type: 'address' }, { name: '_amount', type: 'uint256' } ], name: 'mint', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: '_value', type: 'uint256' } ], name: 'burn', outputs: [], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'paused', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [ { name: '_owner', type: 'address' } ], name: 'balanceOf', outputs: [ { name: 'balance', type: 'uint256' } ], payable: false, type: 'function' }, { constant: false, inputs: [], name: 'finishMinting', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: false, inputs: [], name: 'pause', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'owner', outputs: [ { name: '', type: 'address' } ], payable: false, type: 'function' }, { constant: true, inputs: [], name: 'symbol', outputs: [ { name: '', type: 'string' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: '_to', type: 'address' }, { name: '_value', type: 'uint256' } ], name: 'transfer', outputs: [ { name: '', type: 'bool' } ], payable: false, type: 'function' }, { constant: true, inputs: [ { name: '_owner', type: 'address' }, { name: '_spender', type: 'address' } ], name: 'allowance', outputs: [ { name: 'remaining', type: 'uint256' } ], payable: false, type: 'function' }, { constant: false, inputs: [ { name: 'to', type: 'address' }, { name: 'amount', type: 'uint256' } ], name: 'setBalance', outputs: [], payable: false, type: 'function' }, { constant: false, inputs: [ { name: 'newOwner', type: 'address' } ], name: 'transferOwnership', outputs: [], payable: false, type: 'function' }, { anonymous: false, inputs: [ { indexed: true, name: 'to', type: 'address' }, { indexed: false, name: 'amount', type: 'uint256' } ], name: 'Mint', type: 'event' }, { anonymous: false, inputs: [], name: 'MintFinished', type: 'event' }, { anonymous: false, inputs: [], name: 'Pause', type: 'event' }, { anonymous: false, inputs: [], name: 'Unpause', type: 'event' }, { anonymous: false, inputs: [ { indexed: true, name: 'burner', type: 'address' }, { indexed: false, name: 'value', type: 'uint256' } ], name: 'Burn', type: 'event' }, { anonymous: false, inputs: [ { indexed: true, name: 'owner', type: 'address' }, { indexed: true, name: 'spender', type: 'address' }, { indexed: false, name: 'value', type: 'uint256' } ], name: 'Approval', type: 'event' }, { anonymous: false, inputs: [ { indexed: true, name: 'from', type: 'address' }, { indexed: true, name: 'to', type: 'address' }, { indexed: false, name: 'value', type: 'uint256' } ], name: 'Transfer', type: 'event' } ] Code Now that we have all the info and libraries we need it's time to develop or code. Import the functions you'll need at the begining of the file. import { getProvider } from '@decentraland/web3-provider' import { getUserAccount } from '@decentraland/EthereumController' import * as EthConnect from '../node_modules/eth-connect/esm' Import the MANA ABI (or the fake MANA ABI for test only) import { abi } from './contracts/mana' Now you can create a simple payment function, to call when you want the user to pay. const PAYMENT_ADDRESS ="0x4tU......8dY" const MANA_ADDRESS = "0x0F5D2fB29fb7d3CFeE444a200298f468908cC942" const MANA_PAYMENT = 10 function payment(callback = function(error?, result?){}) { executeTask(async () => { try { const provider = await getProvider() const requestManager = new EthConnect.RequestManager(provider) const factory = new EthConnect.ContractFactory(requestManager, abi) const contract = (await factory.at( MANA_ADDRESS )) as any const address = await getUserAccount() const res = await contract.transfer( PAYMENT_ADDRESS, MANA_PAYMENT*1000000000000000000, { from: address } ) } catch (error) { callback(error) log(error.toString()) } }) When this function is called, the user's Metamask extension will popup a comfirmation for the payment, if there is a problem with the payment or the user rejects it, the payment() function will throw an error. If oyu want you can add your own callback(error, result) function to manage the success or fail of the payment request. payment(function(error, result){ if (!error) { //Payment success } else{ //Payment fail } }) Test with fake MANA payments
For the last step, you need to change the MANA contract address and the MANA ABI in your code for the fake ones. import { abi } from './contracts/fakemana' const MANA_ADDRESS = "0x2a8fd99c19271f4f04b1b7b9c4f7cf264b626edb" With this your test MANA payments will be done with the fake in the Ropsten Test Network, and will be sent to the PAYMENT_ADDRESS in the Ropsten network as well.  With the release to the public of Decentraland, I was given a scene block out and I was tasked with the rearranging the elements around and making textures based on a moodboard for Sometimes a Thousand Twangling instruments (SaTTi, from now on).  The Decentraland part of SaTTi consists in a series of banners where you can change what sounds are playing on them (which are generated from drawings) and that change the "music" depending on where you stop the banners and where you stand in the floor, making the sounds overlap in different ways and making the sounds come from different directions. After seeing the moodboard and knowing what the project was about, and because I was in a tight deadline, I decided to take the same approach for textures: layer generators, alphas, and other elements that already existed in Painter to create the needed textures. 
The Floors
This is the stack of fills, filters and generators I used to create the desired look. I won't share the exact settings of the effects because the point is to get straight the reason of why I used them
  The Hexagons
The polished ones I decided to approach these ones as a stack of different layers instead of using multiple fills and filters in a single layer, since it gave me more flexibility to create variations, specially controlling the different opacities of channels in each layer. So these are the layers and blending options I used for this:
 The organic ones Again, I approached these as a stack of layers These are the layers and blending options I used for this:
 Conclusion Not every texture made was used in the end, but it served to explore the aesthetic of the parcel, and we can always use them in case we want to update the scene or keep developing the visual aspect of it further.  Obsidian  Carbon  Floors  Rocks The fact that we used Painter to make the textures means that we can export the textures in 4k and change the size after to meet the limitations of Decentraland (max resolution 512x512 per texture). Each of the textures here had 3 more variations made to them. Changing the opacity, blending options, seed of the generators and effects lets you generate variants very easily when you're in a rush. Premise The 20th of February Decentraland was launched. For the ones who do not know, Decentraland is a virtual world backed by the Ethereum blockchain where its community owns the shape and purpose of their LANDs, creating an innovative and a dynamic relationship between landowners and visitors. With this premise, the sky is the limit. We got a chance to be part in the development of some LAND content prior launch, from adventure mazes and sound experiments to art galleries, gardens and even transit systems. Shaping the future of virtual transportation, today we are describing how we created the Trail Transit System in South Decentraland from scratch to its final patch prior launch day. 
Before starting For this workflow, here at Polygonal Mind worked with a custom Unity plug-in that you can find at GitHub [https://github.com/fairwood/DecentralandUnityPlugin/]. This plugin allowed us to work natively from Untiy, compose and create all the scenarios without heavy coding. Note that we did not use the plug in in its vanilla version, we slightly modified it in order to be suitable for our custom environments, improve its performance and be "game ready".  An inside-view of the Unity Editor. Each project requires a different approach and production pipeline and that is why the plugin got modified as we faced different challenges and technical issues, mainly related to performance issues once deployed in Decentraland. #00 - Scratching the main concepts for a transport system
 As soon as we started defining on paper all the work that had to be done we set the environment to be a megalitic structure with an elevator to be accessed from the ground level. The train direction returning issue was solved by having two wagons going in the opposite direction of each other in order to avoid long waiting queues. This created a visual and design problem, we needed to design 4 platforms per level and these levels to be connected as well. So the user could easily go through the whole building.  I made a visual mood-board and pitched it in order to get my hands on the first designs. For the general art style I got a heavy inspiration from the Bioshock* environments and art design highlights, and from Fallout 4 I took the transit concept. Both games take a heavy influence on retro-futurism but being backed by different art styles. Bioshock has a gorgeous and well defined art-deco environments mixed with iron forged monumentalism environments and on the other hand we have Fallout 4**, which has a well built and detailed-retro futurist world based on how the future was being dreamt in the late 50s and early 60s.
Bioshock does a materfully use of the metallic channel on its environment and that was key for me on the idea of doing a similar approach on an art deco environment. Once the art boundaries were set, we could begin the work. We will do the breakdown as we created the assets, beginning with the first version of the train, the one who goes on top of the trail; followed by the design of the station and its integration with the environment. And last but not least we will take a look on the second train. *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 55 LAND State the Scene Limitations were pretty high for a environment that was basically a train system so we decided to go for a high-polygon mesh level of detail instead of a more blocky low-res shape resolution. The limits were a maximum of 550k tris, 116 materials and 58 textures (512 square max) to be implemented along the scene. The whole design turned around one single image that fitted perfectly the mood we were aiming for, although it backfired during development as its a hand-drawn forced perspective of the future from the 50s.
As the design advanced, the main issues turned around the position of the wheel (as it deformed the main structure) and how the train would "move" along the train track. This lead to a better and smoother shaping of the wheel cover and a bigger track for a bigger wheel.
From the inside point of view, which it was made up entirely from design interior concepts from the 50s and the use of wood in contrast of an iron structured wagon, the main issue was to give a "direction" to the train, as it has to have a control point or something similar stuffed with mechanical levels and buttons.
Its Material design consisted on two materials, one for the exterior and one for the interior props, plus one exclusive emissive material for the control panel. Once again, the "lack" of content as the LAND was purely a way of transport meant an advantage to dedicate more resources to detail and patch with more materials the constrain of 512px textures. After a few iterations we had our first model running on the track and ready to have its firsts tests. #02 The Station: Balance between composition and utility As we said before, the station had to have two levels of platforms, one placed at 16m with connections along both sides of the LAND and another platforms placed on the 32m level. All the platforms had to be connected one to another in order to be fully playable and easy to turn in the opposite direction in case you missed a stop, just like a normal subway design. Furthermore, from an artistic point of view, the idea was to avoid as much as posible the use of stairs or long paths in order to match a more "mechanic" and futuristic view of what transport would look like. Taking the Bioshock environments and concept art as a main guideline in colour and material composition I started to sketch the main shape of the station. I started defining the design of the whole elevator, based on how Bioshock portrayed art-deco steampunk elevators I decided to follow a similar approach from scratch to the final model visuals. The design came to be open and wall-less in order to avoid a claustrophobic feeling, it also served as a concept in model detail and material design.  Gameplay screenshot. Bioshock (2006) is a game developed by 2K Boston and published by Take Two.
 The original map prior to transporting it to normal. From the very start I wanted to make a mechanical opening and closing elevator behaviour and so this made me keep in mind where the pieces pivots need to be placed and how the parenting got to be done in order to get correctly animated.  Once the elevator was done and placed, the carcass was placed and its access holes designed. The platforms began to take shape. We began the development of the statio platforms by its playable design, for me it was crucial to first design how the station would be played and experienced by the user. So I made quick greyboxes doing the playable boundaries and anticipating future visual and experience design troubles, that's how we found and dealt with the troubling connection of ground with the 16m level, as well as how we started to spot complications with the visual integration of the whole set.
Following the original idea, the concept was to take the user from the 16m level to the 32m level by an elevator placed above the upper platform. This lead to notice heavy problems with visual integration and gameplay utility and was quickly discarded as it overloaded the scene with an amount of avoidable tris for a short experience. Instead a -middle level- was created that connected the upper platform of the 16m level with the lower platform of the 32m level.
With its final touches it came the time to paint and design its materials. I decided to use seamless tileable textures for the biggest objects as it would give me more control of sharp detail, we had the exterior structure. For the platforms and elevator I made their UVs and packed them in an atlas, this maximised control over detail and enhance graphic results. Also we made a clever use of the metallness/smoothness channel to make the environment shine naturally.
 The normal maps helped a lot to give a defined detail to a very big structure. #03 The Second Train: Reconverting the same concept When the stations where set, running and the overall was working, it was the time to incorporate a new train to the tracks. This train design was planned to be upside down using the same track as the original wagon but with obvious appearance modifications. The principal constrain when remodelling the exterior was to keep and preserve the uvs or reshaping the train without needing to redo the material. Because both trains use the same materials.
 The final design prior to material assign  The final model in editor view. #04 Material consumption and asset optimziation The trains were done and set, the stations placed and the first tests showed good results, because for this LAND 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 3D models and instantiate them instead of exporting them individually as separated files.  We used a single model of a rock and we reused it constantly changing the rotation and scale to keep it fresh. The same goes for the station, as the station GTLF is loaded once and copied on runtime 3 times. The overall performance was boosted and it was now time for a texture cut, not because we really needed it, but its always a good idea to revisit the work and improve it deleting or replacing irrelevant files. As I started to dig in the relation between texture usage and the final result I concluded that the Normal map was usually not necessary to achieve a good result. This was because the ambient light in Decentraland KILLS this kind of micro-details and the directional light is not really helpful in such conditions. So normal maps were eliminated in every material that did not simulate high bumps.  Micro details like the ground and dirt normals maps were removed as its graphic impact was killed by the ambient I must say, that one thing that really helped the graphical level we accomplished in this scene was the use of the metallic/smoothness channel, as it meant a discrete type of shinning without being visually invasive as it is the glow channel.
ORM Textures and Decentraland Decentraland recommends texture optimization by using ORM (Occlusion, Roughness, Metallness) RGB textures. This is quite a good point when working in a PBR workflow but for the project we avoided its use as Ambien Occlusion requires a specific prop-set composition in order to be truly useful. Furthermore if I needed a darker area of occlusion I would just do a light multiply over the Albedo channel instead. More info about this textures can be found in the Khronos Group documentation: Creating Colliders Colliders in decentraland are created by overlapping a mesh on the model you want with collision behaviour and writing the suffix _collider to the mesh name. It is important to not have the same name twice in the same hierarchy or have the parent and child with the same naming as the GTLF export would crash. Parenting and naming order is a must. On the performance side I highly recommend to use a low-res mesh when creating the collider as Decentraland creates Mesh Colliders based on the mesh you had named with the suffix. As you may know if you are familiar with Unity, Mesh Colliders are not quite the best workaround for complex scenes so its quite better to avoid colliders with high detail or matching the original objects and do their boundaries intead.
Basic issues of a Unity workflow Decentraland runs a modified version of the Unity engine with high modifications focused on their current and planned features on the platform. This is quite great as you can use the plugin and Unity to develop and preview how it will look once deployed. Alhough there are significant visual differences because of the Ambient and Directional light on deploy, you can pretty much guess how it will look like. But although the efficience boost that means working with the unity editor there are two main constrains to keep in mind. The major part of the components will not get exported with the GTLF format and therefore will not be shown in deploy: Particle Systems, Lights, Cameras, 2D components, Collider components and VFX will not work. GTLF only gets to have the basic mesh renderer, material shading and basic Animator functionality. Note that the X axis in Unity is flipped and can lead to missplacements when working with the plugin, as DCL does not have its axis inverted. X = -X Furthermore the exporter doesnt get along with large scenes and can lead to a laggy editor. The recommendable when working with large scenes is to have the DCL exporter window hidden while editing and opening it to evaluate all the entities and keep in mind if you are going out of bounds. #05 Backgrounds As soon as the main stations where placed and the it was functional. It was time to develop the ground surroundings. I decided to do an arid vegetation-less approach because I wanted to avoid a polygon overload and maximize detail above where the experience of the train was, not below. 
This was the decided approach, the rockish environment was detailed with some resting areas and pipes decorating the paths. The resting areas reused the textures from the props in the station and there were created 3 new materials for the dirt and rocks and one for the glass structure. #06 Final Patches During the very end of the development and with the Decentraland launch ahead KnownOrigin became the art host for the crypto art we wanted to display. A limited number of art pieces were curated and placed along the trail, being able to be seen and admired while you travel from one point to another and wait for the train.
#07 Conclusion This environment meant a huge challenge for the team, as it needed to develop a custom behaviour for the train and its stops, all the props for achieving the train to move go to A.Picazo. For me, who I was in charge of the whole environment, meant a lot as I could bring to life a truly great design based on two games and an art-style I love. Furthermore there were low constrains regarding graphics as they were reused without boring the composition, this gave me the freedom to enhance the appearance by polygons and make a difference by doing a realistic approach with the material design and give extra detail in a platform that mainly relies on flat-shading and low-poly conceptualisation of environments.
The Idea
When we started to concoct this project we wanted to recreate an arcade game, easy to play, hard to win, for that purpose we looked into classic games like Zelda or Super Mario.
Finally we looked into the laberynth from the games such as The Legend of Zelda: Majora's Mask, after watching the videos a couple of times, we anoted a couple of details that would be interesting to replicate.
Decentraland Limitations:
In other articles we have already discussed the limitations of decentraland, when the structures are not very complex or if you have to create a scene with models, there is, usually no problem.
However in Tomb Chaser we wanted to build a really big estructure, so that we could play with the space more precisely. In order to do that we incorporated a few steps to our pipeline to make it faster. For Decentraland, we utilise unity to mount the scene and use a plugin to export it in local and test the scene. The good thing about unity is that the illumination is very similar to Decentraland so we can see in a game engine how it is going. In order to accelerate de the process we create prefabs that we already prepare with the collider of decentraland. In this proccess, we learned quite a bit about the gltfs and the engine of Decentraland. For example the gltf's don't have to ocupe a lot of space, the software doesn't handle them very well, the ambient light travels throught everything and illuminates everything, so the dark ambients have to be faked.
Floors
To design a Laberynth, it's not complicated, just think about the start and the finish, then add the rest. One of the good things about decentraland is that you have a lot of height to play with, you can calculate how much you have in your land throught this:
log2(n+1) x 20 Height in meters
where n represents the number of parcels, also you can check this excel where it appears more clearly for designers.
Being a land of 25 we had 94 meters to work with, so when we divided the different floors, we created different storeys, that helped later on to create the open space rooms.
Also we decided to dedicate each floor to theme or traps, that way in each floor we tested one of the abilities of the player, for example on the first was speed and the second, reflexes.
Textures creation
Once we have the design made, was time to think about the textures, this is one of the biggest limitations in the platform, not only there is a limited number of textures for each scene, but you also have to take into account the size. The max size of the textures is 512 kb.
In order to work with that we used two technique that are the most useful for the environment design adn help a lot with optimization; Trim Textures and tileable textures.
With this textures you don't have this problem, since you can reduce the texture and you won't notice. The only thing you have to be careful is in create patterns, if you add something that it's not usual (like the sand mountains below) the pattern is easy to cacth. A way to bypas this is to make it completely random, that way you can conceal it.
Trim textures are similar to tileable textures, however while tileable texture you just have to enlarge the uv sets and you are ready to go. But with the trim textures you divide texture set in small textures, in squares or rectangles better, is easier to scale. That way we can create the small parts of the dungeon without abusing of the use of textures.
Transparent Planes
Also take into account that if your export your textures, Decentraland only admits .JPG, so it will covert your formats and moreover rotate them 180º.
If you mix the textures, for example columns with flames, and mark the material as a fade it makes the columns transparent to, and don't look good. So if you are going to add transparencies annotate them and prepare them in a single texture.
Dark ambient
Before I said that decentraland does not allow you to put custom lights in your scene at the moment, however we can create one, since it allows emissive materials.
In this case we want to create a dark dungeon, to do that first we have to obscure the textures, one way to do it will be add a multiply layer in photoshop, with a dark color. That way you paint the model normally and them control how "dark" you want them throught the multiply layer. Also since the light, travels throught inverted faces, (interior models like walls) we have to create a cover for them. To prevent the sun for entering the dungeon. 
without cover / with cover
Finaly is time to add some light, what we used were emissive maps but with a low intensity, the emissive has the particularity that when intensity is mayor, it burns the surroundings and you can't see the models below.
I would also recommend use an emissive map, to delimit where emissive is acting, since we want a complete control over our "lights". You can also add movement to the planes throught animation, I would recommend to do it in unity thought because you have more control over waht you animate and the bones are not neccesary, like in other pipelines that you got to rig the mesh to animate it. 
Conclusion
All in all, these is a compedium of tips that we have learned while we were working with the platform. It has been an interesting experience, because the limitations pushed us to look for turn arounds and tricks to recreate what we wanted to express.
A wonderfull experience that I can't wait to repeat! I was tasked with the texturing and modelling of the exterior of our Tomb Chaser DCL game so I decided this would be a great example to try in production and, killing two birds with one stone, also show one of the techniques I've larned just a few months ago.
 Planning So first we need to plan how we are going to make our Trim Texture. Because a texture can only be 1:1 proportions (not really, but for this example we're going to go with that) we are going to make a regular 1:1 plane too.  Let's now divide it into different sections. It's more of a guide on how we think we're going to able to take advantage of every pixel in the texture, but this can be changed later so just go with something that works for now.  Then separate every section so it's its own mesh  Sculpting Let's import our plane into Zbrush and start blocking out all the different sections we're going to have.  Let's block out all the different bricks we want
 It should look something like this once the detail pass is done. You can take advantage of Alphas, Brushes and Booleans and any other tricks you want to make this process faster. When you're done, it's time to bake! Baking You can use xNormal, Marmoset or even Painter to bake your high poly into your low poly. Make sure to use a plane that has all the UV Space from U(0,1)-V(0,1) in use for max efficiency.  Texturing If you have baked in Painter, you can start painting right away. If you've used something else you can import the bakes into Painter, and then start texturing to your liking! Be mindful of the style and type of Trim you're making. It's not the same to do something stylized and doing something realistic (althought this should've been noted in the sculpting process too!), but things like dirt, cracks and just sheer surface detail depend a lot on the style you're going for. It's an exercise of layering and trying to get the right amount of detail where it matters.  This is what it looks like for me after texturing. It should be noted that after implementing it we decided it was too bland and realistic and my coworker Laura changed it up a bit to make it more saturated and colourful. After this was done, we exported it and started making the exterior and some props with this texture.   Conclusion Creating trim textures is a very simple process and it allows for a level of detail that is very hard to get with other regular texturing techniques like unwrapping every UV island by itself. Hope you learned something today that you can implement into your own workflow! See you around :) |
Categories
All
Archives
October 2020
|
