I have the utmost respect for each of these developers. I must say I think they’re mostly incorrect in their assessments of why the Dreamcast failed. The Dreamcast’s ultimate failure had so little to do with the way Sega handled the Dreamcast. Sega and their third party affiliates such as Namco and Capcom put out so many games of such stellar quality, that the Dreamcast won over a generation of gamers who had previously been diehard Nintendo or Sony fans. They even won me over, who had been a diehard Sega fan since the SMS days, but was so disillusioned by the Saturn’s handling that I had initially decided to sit the Dreamcast out. At that time, the Dreamcast launch was widely considered to be the strongest console launch in US history. In my opinion, the three issues leading to the fall of the Dreamcast were (in inverse order):1)piracy, 2)Sega’s great deficit of finances and cachet following the Saturn debacle, and 3)Sony’s masterful marketing of the PlayStation 2. Piracy’s effect on Dreamcast sales is a hotly debated topic, but I’ll say that the turn of the millennium, most college and post-college guys I knew pirated every bit of music or software they could. Regarding the Saturn debacle, the infighting between SOA and SOJ is well known, as are the number of hubristic decisions Mr. Nakayama made which left Sega in huge financial deficit. They were also directly responsible for erasing a lot of the respect and good will Sega had chiseled out worldwide during the Mega Drive/Genesis era. With the Dreamcast, Sega was digging itself out of a hole. They had seemingly done it as well, and would have surely continued along that path, had it not been for the PS2. There is no doubt in my mind that the overwhelming reason the Dreamcast failed was because of the PS2.
Great stuff Fran!
What the hell are you saying? I can't make sense of it.
One of the creators of the Blacksmith demo (download from Unity Asset Store) for Unity 5 Veselin Efremov recently presented a very interesting talk during the SIGGRAPH event in LA. He talked in much detail about the usage of procedurally generated landscaped in game production. In our exclusive interview, we’ve discussed his work on procedural generated imagery in games and the way you can integrate these technological solutions in your project.
I’m from Bulgaria, currently living in Sweden. I have been dealing with computers and drawing for as long as I can remember – from the Apple II drawing and animation programs in the 80’s; Topaz 3D, 3D Studio, PhotoStyler, CorelDraw, and so on in the early 90’s, to the fancy tools we have nowadays. My educational background is in animation direction. Before starting in the game industry, I worked as a graphic designer.
My first job in the game industry was in 2001, when I joined an indie startup to work on the RTS PC game Knights of Honor, a macro strategy game set in medieval times. After that I became the studio art director and we made the game WorldShift, a sci-fi tactical RPG/RTS title. After its release we got acquired by Crytek to work on a big ambitious project, which was never announced. In 2011 I left the company to look for new challenges and joined another small team to work on first person shooter games for iOS.
We called the studio Scattered Entertainment (after our distributed and flat model of working) and released The Drowning and Isolani. After spending almost 3 years there, I pitched the Blacksmith short film to Unity and, after it was Greenlit, joined the team.
My talk in Siggraph was about a pipeline for creating procedural environmental assets, with mostly automated steps. That was the workflow we used for our cliffs in The Blacksmith film, which was used to demo Unity 5’s new graphic capabilities, mostly focusing on the new realtime GI lighting system and the physically based materials.
The talk focused on the pipeline we built – using Terragen to generate the high poly models, fix the meshes and optimize them automatically in Meshlab and zBrush and unwrap the low polies, project normal and AO textures in xNormal, make the rest of the textures in Quixel dDo, add texture details in Substance Painter. There was also a section about making a reusable set of textures that allowed for easily creating a variety of backdrop objects, using displacement and a small tool to project vertex normals.
Procedural Graphics in Games
In most cases, a procedurally generated landscape is much superior to anything an artist can manually create. Tools like World Machine and GeoControl have enabled terrain artists to create amazing environments, utilizing powerful noise generators and excellent algorithms for erosion, that simulate the natural processes of the real world, giving very realistic results. Talented people from the community keep extending these tools, and the quality gets better and better.
There are many opportunities to be creative when using these tools – start from a roughly sculpted base, or even a crudely drawn heightmap; or use actual satelite data as a base, or use external procedural algorithms to get started. Having a good set of tools in the engine you’re working in is also important. Editing an existing heightmap is usually destructive, and adjustments are always needed, especially where gameplay is involved. Having a good workflow for iteration, texturing and adding detail (preferably procedural) is a must.
This all covers heightmap-based landscapes though. And even though they’re wonderful and cover lots of needs, especially the big scale terrain, it lacks some very important features, like steep cliff faces, overhangs, and so on. This is what we wanted to address.
Programs like Terragen and Vue take these heightmaps several steps further. They can create cliffs where needed, they can populate the environment with smaller objects where it makes sense, they can do that for vegetation, too. Small tools can be written to use this data in the game engine to get the environment artist started with distribution, which can be a huge help, as the bulk of the work will be done procedurally.
We used Terragen, which I have been following closely for many years. I hadn’t used it in an actual project for more than a decade though, because I find it a bit too complicated, as a more scientific technical mind is needed. So, what I did instead, was contact one of my favorite Terragen artists – Martin Huisman.
He has been a very passionate landscape artist for many years and has exactly the right mind. Having a scientific brain is a great start, but for great results, something more is needed. Martin not only has a deep understanding of the natural processes that shape the different kinds of terrains, and not only knows how to build an enormous procedural chart of generators and filters in Terragen that can give you vertigo, but is also an artist with high standards for quality in every aspect – landscape, details, vegetation, lighting, atmosphere. Long story short, I was really happy he agreed to work with me on that project, first to come up with a robust and efficient workflow, and then to create the actual high-poly assets in Terragen and export them, so I can work on the next stage of making them usable for realtime rendering.
Unity 5 Integration of Procedural Content
In this case there was nothing specific from the engine side, we just ended up using meshes. Torbjorn, our graphics programmer, wrote a shader that allowed us to mix several materials through an RGBA mask, and a different on that would add a second material set based on normals direction.
Optimization of the Blacksmith Demo
The vista shot where the Blacksmith exits his smithy was the most challenging one, because there was too much on screen – the highly detailed character and foreground environment objects, the demolished village in the mid ground and the distant backdrop cliffs and mountains kilometers away. Unity managed to hold up, even though we didn’t have any LODs. Afterwards, when we were shipping the standalone player and wanted to support low end hardware like laptops, we added Medium and Low quality settings where we had some LODs for the houses and even removed a few. Using a terrain system would optimize the terrain based on distance to the camera and type of features, so this should be taken care of automatically. I don’t think a smaller team needs to take special care, if the engine they’re using is well equipped to handle these issues. Realtime shadows can be an issue with long view distances, so sometimes it makes sense to bake the distant shadows, or use a separate camera for the backdrop, and so on. It very much depends on the specifics of the project.
Making Better Games With Procedurally Generated Assets
Well, better graphics don’t necessarily mean better games, but surely our approach can help developers build better looking games. Generating assets procedurally can not only often produce superior results, but also help reduce the amount of work tremendously. There are so many things you can do – generate models and PBR texture sets (the Ready At Dawn guys made some amazing materials in Substance Designer for The Order 1886); create cloud texture elements to be lit dynamically in the engine, distribute natural objects based on rules or physics; populate the environment with vegetation (Inigo Quilez is an absolute master, his work on Pixar’s Brave is so inspiring); destroy, weather and age buildings by simulations, and so on and so forth. A good tool in the hands of a small talented, driven and passionate team can do wonders. Being more technical is very important, too. Programs like Houdini are so powerful, but you need a technical artist and a creative programmer to utilize their full potential.
Smaller teams absolutely must have that close relationship between art and tech. In big AAA productions we see a complete detachment of engineers and content creators, and that’s so bad for productivity and final results. Coders work so much more efficiently when they understand content and know how their technology is going to be used, and what the ultimate goals are. Artists are able to do so much more when they know how things work, what restrictions are there and, most importantly: how to communicate with engineers. Good communication is crucial, solving problems together is crucial.
Ultimately, I believe the best approach is to mix real-world data, procedural rules and artistic taste, skill and vision. The real-world base (photogrammetry scans, photos, terrain height data from resources like usgs.gov, etc.) is super useful both in quality and speed. Then come procedural algorithms to grow it, modify it and adapt it to project-specific needs. And we shouldn’t forget that we’re artists, too, we don’t just operate tools. Knowing what you want to achieve, being able to visualize the final result and guide the process is very important. Often the tools can lead you in unexpected directions and help you discover surprising things you didn’t anticipate when you started, but after all, they are just tools. They need to be led by a creative desire.