I’m not a game developer, just an interested layman, so I don’t know much more about content creation applications than what I can glean from press releases and the occasional forum thread or youtube video, all squeezed through the bottleneck of a dial-up connection and a dedicated sneakernet. But a lot of this procedural content creation stuff, and similar “shortcuts” are pretty intriguing. Like CityEngine - if it works as advertised, it sounds like a real handy shortcut to roughing in vast urban environments. Add in terrain from World Machine, or any of a plethora of terrain creation/importation tools, and you’ve got a serious canvas to go into and paint your world on.
One question I have is about low poly foliage, the final piece of the structure/terrain/foliage trifecta. I’ve heard the word “SpeedTree” for years, like everyone else, but don’t know much about its viability for low poly game content. And other than SpeedTree, I’m not familiar with any foliage creation tools suitable for games.
Another question is about interiors. I assume CityEngine doesn’t create interiors. Is there anything similar that picks up where GIS data and CityEngine leave off, facilitating rapid prototyping/blocking in of interiors?
Also, anyone know anything about the viability of extracting data from Google Maps for game dev?
Any comments on the state of the art, the tools I’ve mentioned, viable content creation tools for game development, the distance between marketing hype and game development reality concerning same, or any other related thoughts, sources of knowledge, etc., would be very welcome.
If narrowing the subject would help, I’m mostly concerned with what I think of as “medium-fi” 3D content, like in State of Decay, or your typical MMORPG, as opposed to “next-gen” hi-fi graphics.
Hm… If you want something that’s not necessarily a shortcut but will give you way more power than City Engine or World Machine, check out Houdini. You can go as big or as small as you need to. Full disclosure: I work at Side Effects. That said, I’d still turn to Houdini before I picked up any of those others, but I’ve got the benefit of multiyears of experience in using it and creating content with it.
For actual level creation no, for scenery yes. If used for level creation game should emphasize on procedural gen, like minecraft.
AAA proj will spend more time cleaning up and testing levels, indie will probably have no resources to polish such extensive systems.
State of Decay i think are developing procedural houses and towns, but as is the whole game built around that paradigm.
Not in 5 years i think, but the tendency to simplify everything in terms of content creation on the side, can lead to such systems
created and maintained by large “solution” providers, and still it has to be eather unique for each project/franchise or so extensive
and big that is flexible enough to work everywhere. Yeah it’s a new field that soon be filled, keep an eye on kickstarter or something.
hey kinda talking on a few threads about this so since you work for side effects, whats your cost to get moving with houdini for smaller studios ? been on your website and to be quite honest pretty confusing on what a company would need to buy and get moving with. also whats the support with unreal at this point or in the future? was at gdc and spent some time at houdinis presentations. learning curve ? thanks for any info, been looking at city engine, speedtree, etc. so a full work around would be awesome especially if it was priced for indies.
Care to talk it up a bit? Or recommend some videos? I’ve heard Houdini talked up for years wrt procedural content but that’s as far as my knowledge goes.
I confess I’m intrigued by “way more power” and feel like that demands some elaboration. I’m interested in hearing the answers to Leucus’ questions, too.
If you mean it won’t create your game for you, then I agree. I was thinking that CityEngine would basically rough in an urban environment for level designer, who then goes in and actually makes a “level” out of it. Though I’m thinking more along open-world design lines than level design lines. CE gives the LD a shell that he goes in and adds interiors, doors, breakable windows, moving elevators, working light switches, traffic lights, physics, etc.
State of Decay almost seemed too small to have needed something like CityEngine, though you’re right that Undead Labs made SoD as a prototype for an MMO. I hadn’t heard that they used procedural methods, but it makes sense that they would. I’ll have to go a-searchin’ to see if I can find details.
TL/DR = Houdini is way more flexible and controllable, but there’s some assembly required.
“Way more power” in this case is synonymous with “Way more flexibility” and “Live data.” With Houdini, your workflow is more in the nuts and bolts of how the content is created, by stringing nodes together that are essentially C++ objects, which should be familiar to blueprint users. The flipside is that “with great power comes great granularity.” That means there’s no such thing as a “building maker” in Houdini, although you could tear apart one of the assets from labs.sidefx.com or Orbolt.com, and use it as a starting point to make your own Building Maker asset or node network that can be tweaked specifically for your game, i.e. all doorways are a minimum dimension, all floors are a specific height, all windows provide X amount of cover, that sort of thing.
Basically, every widget and plugin and gadget out there that actually creates data or modifies existing data is procedural, technically, but they’re black boxes: you drop them in your setup and you get the result the sliders (and the developers) give you. The “procedures” are encapsulated in the app/plugin, and that’s as far as you go. Houdini’s way less opaque about it, but not as targeted to a specific solution as something like EasyRoads for [that other game engine] or FumeFX for Maya/Max. Houdini lacks the GIS functionality inherent to to CityEngine, but there are ways: Any ASCII file (even ESRI’s) can be parsed with Houdini’s python, and Houdini could probably handle GeoTIFFs as well, although I haven’t tried. Houdini has native JSON support as well, so GIS isn’t entirely off limits. Neither is LIDAR, and you can get a lot without going to the full C++ SDK.
As for supporting Unreal, you can currently use Houdini python to generate .t3d files. Just Google Freek Hoekstra and Jan Pijpers and you’ll find some pretty cool stuff.
Given what I know about game production (admittedly less than most on here, but not completely void), a lot of software development time is spent crafting specific art solutions targeted at a specific title for a specific engine. Houdini is all about the building of things based on rule sets, which lends itself readily to things like kit creation/assembly, organic shapes (full and robust support for volumetric data), placement of art assets according to mesh attributes or texture maps, modification of existing art assets to conform to a new set of mechanics, etc. The idea is to enable artists and tech artists to do that stuff and free up engineers for the hardcore engine and optimization development.
It’s also about building tools: The node based workflow can be encapsulated and shared, a lot like blueprint macros. I don’t want to anger the gods by rattling off the marketing push or something that sounds like it, but I would recommend going to sidefx.com and checking out the tutorials, and downloading the free version. The only drag about the free version is that you can’t save out FBX or EXR files and your rendered images are watermarked. But you can save .obj’s (I think) which you can bring into Unreal and check out. Just remember to set Houdini’s viewport to be Z-Up in the preferences before you start building stuff.
This brings me to Leucus’s questions:
The way it works is this: The commercial versions have a base price and an annual maintenance fee, more or less a subscription. So the base price gets you the product and the first year of maintenance, major and point version upgrades, and support for free, then subsequent years, you pay the fee, which we call the Annual Upgrade Plan because as long as you pay it every year, you get upgrades and support.
You can go off the subscription and your license will still work, you just don’t get support or major/point version upgrades. If you let it lapse for too long, you need to re-buy at initial price but that doesn’t mean your old version stops working.
Let me make that clear: Your purchased license will always work for the version you purchased.
It sounds steep, but we have an awesome retention rate (that I’m not allowed to disclose here) because our support is so good. You also get access to daily builds (13.0.xxx) and the issue database where you can directly submit bugs, RFE’s, and questions.
The difference between Houdini and Houdini FX (and the reason for the diff in price) is that Houdini FX includes all the world-class VFX tools like rigid bodies, cloth, wire, destruction, pyro, fluids, particles, etc. The irony is that those features are less useful to game devs, because they’re not realtime/runtime solutions; they were designed to make feature film FX, which means you throw them to a render farm and go have coffee.
The other prices have to do with whether or not the license is on a single workstation, a local license server, or a globally-available license server. The type of license that’s best for you is determined by where your Houdini artists sit and how often they move to different workstations. A small studio can get great value from a single Houdini workstation license and crank out phenomenal amounts of stuff.
Given that, what is it you want to do? You need to make procedural roads, bridges, buildings, fences, trees, and other art assets, with infinite variations on them, or filtering/processing acquired data? Base Houdini works fine. If you need to do crazy dynamic simulation for set pieces and cinematics, or pyro simulation to make sprite sheets, you’ll need Houdini FX. If you want to use your Houdini-authored tools in Maya, you’ll need a Houdini Engine license as well.
The learning curve is sometimes described as steep, but it’s really not that bad. If you can learn Blueprints, you can learn Houdini, especially for creating procedurally-generated meshes and instance location data. I’ve been using it for a long time, but honestly, the stuff that’s most compatible with game art creation is the stuff I learned 17 years ago in Houdini 1 and is the most basic and easily understood part of Houdini. You’re also not going to care much about lighting and rendering, unless you want to get crazy and bake lightmaps or pre-lit texture maps out of Houdini (doable, I’ve done it). But definitely go through the tutorials on the sidefx website, they help a lot. Not only that, check out the sidefx Vimeo channel, lots of cool stuff there as well.
With that out of the way, I’ve got a few cats in a few bags that I’m not allowed to let out, but we are, as a company, very excited about Unreal 4 and we are committed to serving the game development community in the many forms that it takes, including hobbyists and small studios.
Having said that, as someone who has been working with houdini professionally for 6 years (Film and TVC vfx work) I can back up pretty much everything that has been said and also double triple back up one particular element. The support you get from SideFX is second to NONE. As head of 3D at a medium sized vfx house I have to deal with sideFX, Autodesk, Adobe, and The Foundry regularly and I can say that the difference in the level of support directly from the company is chalk and cheese. You put in a bug report or RFE and generally you’ll get a reply very fast (I’m on the other side of the world…) and quite often the bug is fixed and a new daily build released at extraordinary speed, they really do go out of their way to help.
As for learning curve, yes there definitely is one. But it’s more about adjusting the way you think of working in 3D rather than being a particularly complicated piece of software to use. Having only recently picked up unreal working with the blueprint system is very similar to working in houdini overall but specifically to an extremely powerful aspect of it called “vops” wherein you have a set of nodes set up running from left to right and affecting geometry or shaders or fx systems. I felt instantly at home picking up this stuff in UE4, i’d imagine it would work similarly the other way.
There are a lot of great tutorials out there, i’d recommend searching for Peter Quint on vimeo and CMIvfx has a great series as well (inlcuding some procedural city\road generation assets) that will introduce the major concepts.
Go and grab the apprentice version (free) and have a play around, you should have your first “OMG I can do that?!?!” moment fairly soon after using the software I know I did.