This week I want to give you a tour behind the scene of the development of Reality and explain what’s happening. In these days there is a lot of talk about non-programmers wanting to learn more about programming, and the use of the word “coding”–the act of writing a program–is becoming common.

At the same time I heard some of you asking why it’s taking this much to develop Reality 3 for Studio, so I wanted to put the two things together and give you a look “inside the sausage factory.” I hope that this article will provide a better picture of what’s happening in the Reality world.

We write programs using computer languages, which are not too dissimilar to spoken languages. There are grammar rules, there are predefined “words” and so on. A language, human or computer-related, is a tool to express ideas and concepts. When we write a program we express a series of ideas and describe them in steps that are executed by a machine. Designing the concepts and resolving the conceptual challenges are the most demanding activities about writing a program.

I started designing Reality 3 when I was writing Reality 2 for Studio. The idea was to create a converter that was not bound by a single application and that could be easily adapted to work with several 3D applications. Since 80%, or more, of the code written for an application goes in the User Interface, it was clear that solving the UI concept was key and the solution to porting Reality to different apps.

For that reason the UI became a stand-alone application, and in doing so it was possible to break the confines of what a plugin can do. But that solution introduced another challenge: if Reality is a separate application how can it communicate with Studio or Poser? I’m not going to bore you with the technicalities, suffice to say that the Reality UI communicates with the Reality plugin which runs inside the host application, being that Studio, Poser or something else. Writing that host-side plugin is the task at hand today, with Reality for Studio.

But what do we mean when we say “writing a program?” What does computer code look like? The following figure shows you an excerpt from the LuxRender code, written in a language called C++:

LuxRender Code excerpt

You don’t need to understand what that does, the important concept to bring home is that people write that type of text by hand, line by line. And writing is not the hardest part. We don’t seat at the desk writing down something that is dictated to us. Before the writing begins the thought had to be formed in the mind of the programmer. The solution has to be found before the writing happens. It’s a bit like writing music. You have to have the music in your mind before you can write it down. For example, at line 296 we can see a if statement that tests for a condition. The lines starting with “//” are comments inserted to document what the code does. The “Dade” prefix is the signature of David Bucciarelli, one of the developers of LuxRender.

Reality 3 for Poser, which was written from scratch in C++, was about 193,000 lines of code. Keep in mind that most of the program, more than 90%, is in common with the Studio version. Today, with the current code for Studio, it’s at about 208,000. That is an increase of 14,000+ lines of code. For comparison, LuxRender has about 374,000 lines of code. So, Reality is about 55% of LuxRender, in lines of code. This means that in about a year and a half a single developer, myself, has written more than half of the code that has been written by several developers, no less than five, in about seven years.

I’m not comparing myself to the developers of LuxRender, who, by the way, are doing an amazing job. They develop LuxRender in their spare time and I work on Reality no less than twelve hours a day, every day. Often I work more. I’m just trying to give you, the reader with no programming experience, a measure of how fast Reality is growing. Writing the equivalent of 55% of LuxRender in 18 months is a tour de force and this is while I support the program and manage the sale activities. But those 14,000 line of code are not the end of the story. I still have to write the geometry exporter for Studio and the new implementation of ACSEL and ACSEL Share. By the time I’m finished the code will be several thousands of lines larger.

Reality 3 has a lot of new features. The material editor is incredibly more sophisticated. While Reality 2 had just two textures types available, solid color and Image Map, Reality has no less than fourteen! Here are the texture types that are supported by Reality 3:

  • Band, also know as agradient
  • Bricks
  • Checkers
  • Clouds
  • Color math (multiplication, addition, subtraction between any two textures)
  • Constant color
  • Distorted noise
  • Fractal noise
  • Grayscale
  • Image Map
  • Marble
  • Grayscale Math
  • Mix
  • Wood

Each texture type has its own full-fledged editor and previewer. For example, here is the Clouds texture editor:

Reality for DAZ-Studio - Cloud texture editor

All this needs to be thought out well, written, tested and then generated for Mac OS 32-bit, Mac OS 64-bit, Windows 32-bit and Windows 64-bit.

Writing for multiple OSes is not simple. Mac OS and Windows arenot at all alike. Inside they are not even related. When we write something that calculates a function we don’t have any problem because C++ works unchanged on many OSes. But when we need to create something as simple as a push button and make that button have the native look on every OS the challenge is huge. Remember that 80% of the code is in the UI? That gives you an idea of the enormity of the task. There are tools that we can use to write the UI once and then generate the program for several OSes but even with those tools it’s not a walk in the park. It take a long time, at least a year of practice, to become proficient with those tools. That is working with the UI tools every day. Your mileage can vary but I don’t spend every minute of my day studying UI components, there’s code to be written for the material converter, the storage routines, the geometry transformations etc.

So, that’s were the time goes, that’s why it takes what it takes to create a program like Reality.

I hope you enjoyed the tour of the “sausage factory,” next week I will give you more details about the storage system of Reality 3 and how it integrates in DAZ Studio.

If you are not yet a subscriber of this blog please consider becoming one. By subscribing you will receive automatic updates about Reality.


Pin on PinterestShare on FacebookTweet about this on TwitterShare on Google+