Last week I introduced a few fundamental concepts for 3D artists:
- A 3D artist should be able to express herself using artistic tools instead of being forced to delve deeply into technical issues.
- A 3D artist should be able to change the materials in a scene by herself, taking control of all aspects of the material. If the artist needs green glass, then there should be a, relatively, easy way of changing any material to “green glass.”
- The node system used by many programs, including Poser, presents an un-natural constraint in the creative workflow; it does not fit the artistic mindset.
- A long list of parameters spanning multiple screens is also difficult to manage and very technical in nature. This is the solution used by DAZ Studio.
The conclusion was that artists using Poser or DAZ Studio have been intimidated by the material editors in those programs for years, with the result of convincing 3D artists that editing materials is not something that they can do . To be completely fair, the issues are not unique of Poser and DAZ Studio. The node system, for example, is widely regarded as the way to edit materials at the professional level.
User interfaces evolve of the years and the material editors of today have deep roots in the technology of 20-25 years ago. Reinventing something from scratch is a daunting task.
The problem of editing materials is very complex, and finding a solution requires a major departure in the design of the user interfaces defined so far. I’m not claiming that I have solved it, yet, but there are steps that can be made to make the problem less complex, with the result of making the practice of editing materials approachable by any 3D artist, with just a little bit of training.
Before we look at the proposed solution it’s interesting to understand how we arrived to the current situation.
As we saw last week, material editors today are mostly designed to be machine-friendly instead of being artist-friendly. Programs that favor the machine instead of the human user are common when the complexity of the problem is overwhelming or the technology is undeveloped. For example, punch cards were the system for entering data into a computer in the 1950s because, at that time, interactive terminals were not available.
When the Graphic User Interface was invented by Xerox, and then adopted by Apple, Microsoft could not solve the technical problems of painting overlapping windows, and so Windows 1.0 used tiled windows. You can imagine how much the user experience suffered. The Mac, with its overlapping windows, became a success while Windows 1.0 was nothing more than a curiosity.
Renderers are very complex programs that take a multitude of parameters. In fact, each material definition is a small program in its own right. This small program is called a shader.
Faced with the task of interfacing a renderer with the user, a solution was found, a few decades ago, in the use the node system, where each node represents a function of the shader. Each node has some input parameters; for example, an Image Map node will accept an image file to be used for painting a surface, or to control things like bump mapping and specularity. The node performs the function on the parameters and then produces some output. Each node’s output can become the input of another, compatible, node, giving the user the power to string several nodes together to combine their functions.
In theory, this is a great model and one that naturally appeals to programmers. In Computer Science there’s a lot of use of graphs. A node system is basically an editable graph. Most people with little or no mathematical background are not familiar with graphs and artists are known for not being fans of math. That is a detail often overlooked by software architects when designing a 3D application.
Graphs look natural to programmers and therefore they are embraced as a good solution almost instinctively. The fact that almost nobody is questioning that approach is baffling and shows the blind acceptance of a practice just because “this is how it’s always been done” or because finding an alternative solution is an extremely hard problem to solve.
Building a visual editor for a node system is a fairly difficult task. Case in point, Poser’s Material Room is lacking some crucial functions, a fact that makes it even harder to use. For example, there is no zoom function, which makes it often impossible to have complex material fit inside the view port. There is no automatic re-ordering of the nodes, forcing the user to spend a lot of valuable time dragging nodes in place just to read what a certain portion of the shaders does. There is no highlighting of a node branch, to see all the connected nodes. And so on.
Building a good node editor is a complex task, and at the end of the day you are still stuck with a system that is not well suited for artists.
Let’s now take a look at the DAZ Studio side of the story. The development history of Studio is varied. Started in 2005, Studio was initially designed to make DAZ independent from the fate of Poser. As a free program, free as in gratis, not as in OSS, it was built by a small team with limited resources. Over the time it evolved into quite a sophisticated program and it has some good foundation in modern software design. I say this based on my own experience with the plugin SDK and with the use of the program. I don’t have any insight into how DAZ works internally, and I am not privy to their management and software development process. I can only speculate a little bit, based on the final result.
For example, Studio has both a C++ API and a scripting environment. The C++ API is a great feature that allows to extend the program in a modular way.
Given the difficulty to make a node system, an alternative solution was found in listing all the parameters of a shader in sequence. This is the Surfaces tab. As we discussed last week, the solution is hardly optimal, but I can understand the constraints that the developers had. The solution is a bit similar to how LuxBlend works. It’s basically giving all the parameters to the user and say: “here, have fun with them.”
While access to all the parameters in a more or less ordered list is a powerful tool, it’s also overwhelming, difficult to read, it requires a deep knowledge of the underlying technology, and it’s quite inefficient. Inefficient for the user, as in: it takes a lot of effort for the user to arrive to the solution of the problem. The thinking, probably, was that only advanced users would be really using that portion of the program.
Advancements in program architecture are generally promoted by the developers. In a technology-driven company the developers are able to drive the evolution of a program. For example, in Borland, a company that developed computer languages, many features were decided directly by the development team. We rarely consulted with the upper management about design and features. The result was that our products were the most advanced in the market.
In a marketingdriven company, like DAZ, development is generally more reactive, based on the perception of what the user needs. Given that DAZ’s business model is based on selling content, and not software, the lack of development of the Surfaces editor leads to the proliferation of material presets made by expert users. Given that such presets are then sold in the marketplace, it’s seems logical that there is little incentive in evolving the material editor into a solution that allows the end-user to customize the materials quickly and easily.
Now we have a clear understanding of where we are and why we arrived here. Next week we will discuss how we can approach material editing with ease.