If you rig your character up as a standard SineSpace avatar and getting it working properly, then any clothing purchased (or that you make) in SineSpace should just work properly (if not, file a bug report). If you're rigging up your Daz3D content as a costume replacement (also known as a bypass avatar, since it bypasses the entire avatar, clothing, and attachment system), then you're on your own.
play game happy wheels
Nice article. I would love to know if there is any cloth rigging tutorial or tool/plugin that could solve the typical mesh bleeding issue. For reference, I have issues with getting custom or bought clothes on a custom animated Daz3D Character in Unity. So far, the character looks good and work. The clothes fit in T-Position but once the animation starts, the vertices from the character bleeds through certain parts again and again. I've looked into the bones skin-weights but was not able to see anything to improve there. the problem grows once certain body-morphs alter the character (giving him more weight or muscles)
Deus Ex: Mankind Divided is a truly unique experience – it has its own amazing dense world that makes it one of the best RPGs the industry has to offer, providing the feeling you won’t find anywhere. We present to you our series of interviews with extremely talented team of developers from Eidos Montreal, who were kind to enough to share some details on building Mankind Divided.
Let’s start by discussing building the game’s world with the Environment Director on Mankind Divided, Hubert Corriveau. The developer talked about the density of Deus Ex, the way this game evolves around its story, using Dawn Engine, optimizing the game and other important details that make the game a masterpiece.
I started working on architectural pre-vis at 18years old, went to the NAD center for a few months (a Montreal CG school) and then had my first gaming job at Microids, where I worked on Post Mortem, Syberia II and became a lead artist on Still-life, all of them point and click adventure game featuring pre-rendered visual. Then I worked for about a year at Gameloft on various mobile projects, at Ubisoft on Rainbow Six Vegas and Prince of Persia 2008, and then landed the job at Eidos Montreal on DX: Human Revolution in 2009.
Deus Ex: Mankind Divided
Deus Ex is about choices and consequences. We’re building this world, where we hope you won’t simply get to your next objective. We hope you will stop and explore a bit, and you can do it in various ways. To me, the most important bit that makes it unique, is the various details we build for the game to make it “coherent” – we want the narrative and visuals to fit together. You read an email or one of the many pocket secretaries and, you can piece together that we’ve worked on to make it feel like it’s all part of the same universe. I think we are doing this more than other game developers.
The very first step is to agree on the main mission flow… and this is tough to define in DX because two players won’t have the same flow in the same mission, but we expect a simple and straight walkthrough from a player. At this point we might say “Jensen lands on the rooftop, gets a few floors down, finds an incriminating document in a banker’s office, then goes out through the parking lot”. We draw a very crude drawing of what we mean by this sentence. We then scope out how many “art palette” we have time to build for that environment – this is what we count at first and how many different looks we give to a map. In this case, let’s say we have one rooftop section, one office section, and one parking lot. This is a large scale information that can be scoped and planned for. Then we start what we call the gate process.
Then we aim for our alpha state – we try to fill the entire environment with the basic modules required for each art palette. At this point, the rooftop looks like a rooftop, the office like an office and so on, but it looks very repetitive, very modular. We add a bit of props here and there to avoid having an environment that looks too empty, as this tends to bog down the review process (people always get stuck on the empty look of an environment instead of looking further ahead).
And then we polish. This is when we concentrate on storytelling. At this point we can play the game and talk to the characters and get a sense of the story, and we start adding personality to the environment. We get a lot of feedback from the narrative team, the side quest team and the creative director on that aspect. The side quest team’s feedback is invaluable as, to be fair, we don’t really know what they are cooking on their own and we cannot guess what we would need to add to tell their stories. We plan some time ahead for them… but we don’t know what kind of things we’ll have to add.
For example, when we started working on Prague, it took about 6 weeks to build all of the streets and buildings there. Then it took about 2 years to customize everything and add all the extra requirements from the level design, side quest and main story. And then few more months of extra polishing when we added the final storytelling element. The idea of having everything in there so soon is that, in practice, from the level art point of view, we could get into shipping mode anytime. I don’t want to have a debt where I’d have to tell the creative director “I wish we could build that burned down building, but we have to finish the third district first”. I prefer to give him a choice, to let him know that he is trading off polishing on vanilla buildings in the third district in exchange for a specific burned down.
The main strength of Dawn is how it can manage almost infinite amount of entity at the same time. Not infinite though, we did hit that wall at some point, but it is very well-suited for a large game. More than that, its entity-driven architecture means artists have control over many things that were in the hands of programmers on HR. We have a team, lovingly called the “smart object” team, that is dedicated to all what is interactive in the game. They are responsible for anything from the guns and all their features to robots, cars and books on a shelve that explode in a rain of paper when shot at.
Every part of the world works with the gameplay. Your environments gives tons of possibilities to build your own experience – stealth, pure combat or something else. How hard was it to model your environments so that they work for the players?
Environment wise, we have to talk about the relationship between the level designers and the level artists. Level designers are responsible for the mission scripting and the “multi-paths” element that Deus Ex is well-known for. They have a responsibility for the environments’ layout. Level Artists have to model and texture that world, organize it to fit with memory and GPU, and I’d have to say, try to keep the layout as architecturally credible as possible. Whereas the level designers see a level as the player’s playgrounds and the stage for the story, we (the level artists) see it as the expression of the Deus Ex world’s first. This brings a certain element of contradiction, a tension between artists and level designers that, I would say, is critical for the success of those environments. One team should not overwhelm the other, we need to find the best compromise between both viewpoints. We learned that during HR and we “embraced” this difference of viewpoints in Mankind Divided.
One specific detail is the cover system and the switch from the first person to the third person view it triggers. We do have a ton of “world dimension” rules to work with… more than most of the games I’ve worked on in the past. Imagine that you need a one meter cube to be clear at every corner of every single room you have, anywhere. Imagine this one meter cube of clear room also applies to couch and desks and cars. Imagine designing a car with a one meter cube that can stand both at its front and its back to support cover. We try to deal with that.
Another usual ingredient in Deus Ex are air vents. We can’t really make them architecturally credible. They are used as joker cards from the level designers to get from point X to Y and it is hard to justify air vents every time they are required. We did build a few variants this time around, the in-between walls, the cable ducts (technical variant of the air vents), the inside-ceiling modules in order to have more than just the air vents at the level designer’s disposal.
You had to built scenes that would look good with different scenarios – day in the beginning, then night and something special in the end. Could you give us some details on working with this element?
The main element here is lighting of course, but also the entity-driven system of Dawn, which lets us script every single entity in there if we want, so we can apply a behavior to anything. In this case, it’s a simple fetching of a value, say 2 for night and 3 for rain, and deciding how an asset behaves with that value. This is easily doable everywhere with Dawn. We can modify on the run runtime any given parameter of a window’s material or in the case of Prague Rain, we can replace on the fly the material applied to the floor to give the sense that it receives a lot of rain. Some systems require specific engineering but we can pretty much always find a way around. Then it becomes a question of how much time we have to customize this behavior.
Your scenes are filled with different objects. I’d say it is a unique handwork with so many additional details that enrich the universe. And so many easter eggs! Could you talk a little about this part? How did you manage to add so many little elements, making sure that they look organic in the end and do not overcrowd your scenes?
We focus a lot on that aspect. Clutter was a big element that we spent time on in Human Revolution. And with technology moving forward, now it feels like every other game can do clutter too… So we really had to work a lot on this. Golem City is a highlight here, being such a staple of cyberpunk imagery, we had to push the cluttering to the maximum. When we started, we asked the level artist in charge of Golem, Michel Lanoie, to put as many wires and cables there as he could. Almost dared him to put too many. Turned out, he loves doing those wires and cables everywhere and he really did put a lot of them. I believe it’s the environment with the most wires the game industry has to offer now :).
More than that though, we focus on storytelling elements as much as possible. This is where the coherence of the universe takes shape, this is where you find a location that was generic in alpha, and is now a kindergarten in the middle of a high-tech dystopian slum. Did you notice that kids were making little dolls with coat hangers in that kindergarten?
The world of Deus Ex is dense and complex – it has so many levels and locations with absolutely no stitches! How did you work on optimizing your scenes? The game works really well on all the platforms, managing to look so amazingly good.
Credits goes to the engineering team, the tech artists, and everyone responsible for the Dawn Engine. There are a few things we are doing to help though. Doing custom assets for so many details in a very dense area like Prague leads to a shortage of memory, fast. If we were baking even a few of our assets from high-res models, we would never be able to deliver this game. This is because a mesh that has completely unfolded UV coordinates (the kind of UV you do for a baking process) requires large texture to cover all of the asset’s surface. In the first person shooter setting, this texture requirement is at least twice as large because pieces of environment are often right in front of your face, right there on your nose, compared to the third person game. Especially in the first person shooter where you can stack fridges on top of cars and jump four meters high or grab ledge on a rooftop using a teleport augmentation. You can get anywhere.
The Housing Block is a mesh built by Michel Lanoie, Level artist in charge of Golem. It is a good example of how we “compress” texture with UVs. All of the mechanical details are on the set of texture represented by the albedo file. We stretch the UV coordinates of UV1 for every single detail that can be stretched.
An extreme example, which we avoid doing because they are quite time-consuming, are the normal textures used for all of the architectural assets in Hengsha (Deus Ex: Human Revolution). We don’t use such extreme UV compression anymore, but this texture is a good way to show how we are stretching details. The Hengsha normal image was used for the vast majority of details in lower Hengsha.
Look at the “stretched_uv_process” – we took a sample from the Hengsha texture and “stretch it”, using extra vertices, and we did this to a rather extreme level. This means that a very very small set of texture can get you a very large asset at a very large resolution. But the trade is the amount of time required to cut this geometry. Those are represented by the thin grey lines. Imagine the housing block was built with the same method we used for Human Revolution. It would have been extremely dense with mesh.
The housing albedo
We never do this to “such” an extreme level as HR anymore, but we still use that method with most assets, including guns, cars, robots, furniture, anything larger than a chair, except for the objects that don’t have any specific details (like… a large rock or a block of concrete). The housing albedo texture represents a very good example of how to mitigate the work required on mesh by saving larger samples of mechanical details, and then stretching “batches” of details instead of a single detail over and over.
For bevelled edge, we actually break the vertex normal. We cannot afford texture memory to map the bevel’s normal unto the texture, so we build a tool that defines which bevels you want to have a nicely bent bevel normals on. This tool remembers all of the bevels on any given mesh in max, and it remembers them forever, you can give a solid beating to a mesh and the “bevels” are still located in the tools memory, coherently. This is important because breaking vertex normal is risky as any modification to a mesh generally modifies the normal greatly. Instead, we remember what we want to be bevelled, and we automatically reprocess these normal every time we export. This does cost a bit of vertex memory, but we save a lot by not putting this information into textures.