Reality development update


If you have watched live the Apple event a couple of days ago you know of how badly that live broadcast went. It pained me to see that because it’s so uncharacteristic of Apple. But that shows that even the best, most quality-obsessed companies, can fail when some part of the development chain goes awfully bad.

I read that the issue was caused not by over-capacity but by the addition of the live tweets in the same page that showed the video. Apparently some JavaScript code was causing very frequent page refreshes to capture the tweets. The trouble was, the code would refresh the whole page, including the video stream, which caused an overload on the server. Basically Apple DDoS-ed itself.  DDoS is “Distributed Denial of Service,” and it’s a technique used by malicious hackers to bring down a web server by overloading it with more requests that it can handle.

This accident shows the dangers of not testing an application in all situations and of not thinking things through. If the analysis that I read about the accident is accurate then it shows some serious oversight by the web developers. Causing a whole-page refresh every few milliseconds is quite the mistake and shows a level of inexperience with development that is, quite frankly, appalling.

The reason I’m telling you all this is to explain why we are testing Reality as deeply as we do. Last week I thought I was done with a certain feature regarding material management when I hit a snag. Strangely enough the Automatic Presets for two completely different products where getting mixed together. It turned out that some products use very ambiguous names for their geometry files. Reality’s Automatic Presets apply a set of materials to a model automatically. You don’t have to apply the presets, you don’t have to search for them. They just happen. For example, let’s say that you load Victoria 4 and add the Rio skin to it. Reality will automatically load the Rio preset instead of using a generic skin material. How does it do that? The key is to find a way of uniquely identify an object, Victoria 4, in this case, and to do it in the same way with the Poser and Studio edition of Reality. Keep in mind that Poser and Studio handle files in a completely different way, internally.

My first implementation, the one that is in Reality 3.1 for Poser, used the name of the geometry file without the extension. In the case of Victoria 4 it’s blMilWom_v4b. The full file file name is blMilWom_v4b.obj. This is all OK with something like Victoria. Genesis works as well. It has the name “Genesis” or “GenesisFemale” and “GenesisMale” for Genesis 2. All good there. Unfortunately I found two different models of pants that have been saved as “pants.” That caused the mixup since Reality could not differentiate between the two. The best thing, for every content maker, would be to use unique names for all the assets in their products. It’s not difficult and it has long term benefits. Unfortunately I cannot count on that practice and so development came to a screeching halt in order to solve this issue. I found a solution and implemented it in both the Poser and Studio version of Reality. It took about two days to write it but it works beautifully. Unfortunately now there is the issue of 260+ shader sets not working anymore because all the identifiers for the associate models are different.

So, I had to write another piece of code just to convert the existing ACSEL database to the new one. It’s a laborious task that requires collecting by hand the new identifiers for each product that we have handled before. Half of it is done and the other half is getting prepared as we speak. We should be able to have everything converted in a couple of days.

It’s a snag but that is what happens during development all the time. People who are not familiar with programming think that we just put the instructions together, one after the other. That could not be further from reality and this issue is showing one of the many things that we face every day.

But what would be the alternative? As we witnessed with the Apple broadcast fiasco, diligent testing is the only way to develop bug-free software. With more than seventy testers on board I’m confident that the next Reality will be a solid product that will give you great results. A product that you can count on. I appreciate your patience while we sort out these bugs.


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