There are AwesomeBump that is written in QT and do not require .NET Framework and has code open.
Интересно, не понятно зачем, но круто. Я бы хотел поучаствовать в проекте
Already have ndo, b2m, knald, and others.. Why another one?
Øyvind Fiksdal shared the details of the procedural pipeline for building a house and a landscape in Houdini and talked about the advantages of the approach.
My name is Øyvind Fiksdal, I am a Norwegian artist with a background in more or less traditional art. In my late 20s, I decided to focus on 3D full time and enrolled in a 2-year eduction in 3D and animation. A short time after this I landed a job at one of the larger advertising agencies in Norway.
Working with the advertising industry was a door opener, but the lack of exciting opportunities serving a single company led me to become a freelancer. After two years of freelancing me and a previous college decided to team up and formed a company named Trollskog.
Procedural Approach to the Project
Houdini‘s procedural nature always intrigued me, but on an artistic level more than the typical use common for the program. After watching a large number of tutorials and presentations I started to comprehend the power housed within the open frame.
When working with fully procedural assets in Houdini or any other software there is very little room for artistic input other than to change seeds and hope you get something that is to your liking. Working with art directors or even your own direction, being at the mercy of randomization might work for background assets, but for hero assets or even a carefully crafted village this will be an insufferable challenge for the most of us.
Even working with traditional modeling and sculpting conjuring up a whole village serves a massive undertaking, in particular editing the asset after its completion.
The concept behind my idea was to create simple low poly assets that are carefully crafted and have the same procedural tool-set read the geometry and create a finished model with all details, textures, and refinement, this would normally take days to complete in a traditional manner.
It is also worth noting that this was a project I did about a year ago trying to extend my knowledge of Houdini, using VEX and determining the viability of using Houdini in a production pipeline.
House Building: Procedural Pipeline
The procedure that generates the completed house from the low poly base is built up of a series of modules. When speaking of modules in Houdini it’s often referring to a chain of nodes that perform a specific task. For example, the first module reads the low poly geometry and figures out what is roofs, walls, doors, and windows. This branches out into several subsequent modules that perform secondary operations, For example, the roof is then sent to the next module that finds the roof saddle and checks if it can detect a spire. Further, this gets sent to a new module that creates the roof tiles, then to create moss, then another for creating grass and so on.
The finished model has few to none prebuilt assets but rather generates these out of the underlying surface and this is the underlying concept behind the project. As you can see in this example of how the walls were created using nothing but simple low poly geometry.
The process begins by importing a single mesh like shown in my initial video. From here the model is as I mentioned above, procedurally detecting roof, walls, windows, and doors. These are further sent to the main creation phase. The input model is also used to create the ivy witch not only grows over the surface, but it measures the volume of the model to avoid overgrowing it or not having enough vegetation.
Each of these elements read the input file path and this is passed on down as an attribute so that the finished model is eventually written out as Houdini native file, so by only choosing a model to work on it allows me to create a finished model by a single click.
Procedural Approach in Combination With Handcraft
By using a 100% procedural pipeline without having the hand-crafted input it is possible to achieve organic or erratic looks, but it would be very complicated and unpredictable. But by joining the two worlds it becomes easier and makes you feel more in charge of the final outcome.
There is, of course, need for leaving some things to chance such as creating all kind of random values for the scale, rotation or position of the objects as well as using noise patterns to simulate rocky surfaces and such, but this is basic operations for a workhorse like Houdini.
As seen in the wall creation video, a large amount of these materials are geometry rather than textures. The rest of the materials are made using color data from the meshes as well as curvature measurement and other tricks using attributes. Most of the actual textures used are very basic textures made using COPs (Houdini built-in compositor).
The low poly was UV mapped before import and this is used in the model process such as making roof tiles. Even though I am not using any of these in the final product it could be applied to bake out textures to be used with the low poly version, but there are better ways of making a game model of this which we will get back to later.
The final model is mainly UV mapped procedurally using the game dev tools, while other parts such as beams and door frames are mapped using sweep and skin on curves that has UV coordinates.
The landscape is generated by reading the ground floor of the imported model, the final geometry is made using VDBs by layering different noises.
After the landscape is completed, we can measure all type of topological properties; occlusion, curvature, slope angle and so on. This is what determines where grass will grow, how tall the grass would be and where its likely flowers or trees would grow.
The materials are made using a combination of images and color data for variation.
The actual plants and grass are instances that are procedurally made using a combination of nodes and VEX. Then these are made into Redshift proxies that are instanced out based on the attributes on the landscape.
Is the Project Ready for the In-Game Use?
The setup is both viable and not viable for game production. To make it viable it would have to go through another set of operations, but this would be a fairly simple and straightforward task. These are too high poly for in-game use, but by converting the high poly model to a VDB object to make it airtight and then use the polygon reduction tools, it would be as simple as just baking out the rest in textures.
I think that using procedurally generated architecture in games are fairly common these days, but I have yet to see people using pre-made simple models and then generating all the bells and whistles from there, but maybe we will see more of it in the time to come.
When it comes to bottlenecks for the project, the first would be the limitation of my own knowledge in Houdini. This was a project I started because I was learning the program and had an idea I wished to carry out. In retrospect, there are many things I would have done differently with what I have learned from this and other projects in recent time. The other bottleneck is RAM, using Houdini and especially working with VDB you want a lot of it and simply don’t.