It is in Poser format and is going great guns. Although with care and attention it is possible to convert for D|S, it seems that some people have been having difficulty, so we are at work in order to produce a D|S-only upload too. Sorry for the delay - RL keeps butting in.

It may be remembered that when the Castle Combe model was under development a year ago, considerable trouble was experienced with textures. The cause turned out to be one that is inherent in many (or perhaps all) computers, where deep down in the operating system at Assembler Language level, they confuse words found in user data (such as texture names) with commands or part-commands that occur within their own operating system. In the case of Castle Combe, the problem proved to be the word "stack" and whenever it cropped up, the program got its knickers in a twist and swapped textures. (Well, what do you expect? It's only a stupid bunch of wires.)

A similar thing occurred recently with the Buckingham Palace model, but this time around, errors did not occur nearly so frequently or so obviously, presumably because the errant word or command was not often used by the system. Nonetheless, errors did occur from time to time but having been led to regard computers as being almost incapable of error, one wasted many hours or days in search of mistakes of one's own - sometimes non-existent. Then it happened that one day the stonework of the BP model turned a violent blue and close inspection revealed it to be texture from the police box. A moment later, the stone turned jet black, while the police box vanished entirely. Oh wow. At last one realised the depth, nature and cause of many errors - the computer itself consistently screws up. The new offending word was "port" and it happened because I had used the words "portland stone" as the name of a texture. Portland stone is a very beautiful almost white stone that occurs only at Purbeck in Dorset; most of London is built of it, so of course one used the correct name in order to distinguish it from granite, basalt, sandstone or whatever. Obviously, we would have the same problem if we used the words "portland cement" or "port wine", or maybe words that simply contain the offending letters such as "transport", "export", "sportsman" or even "top or toe." The solution was obvious - one had to replace each and every occurrence of "portland stone" with the simple "stone." That was easily enough said, but time-consuming in the extreme to carry out. It worked though, and having cleared an accumulating backlog of errors, at last one was able to complete the model.

The very worst kinds of errors are those that are intermittent in nature - those that happen only sometimes and yet often do not. If a machine stops working completely or misbehaves every time that we take a particular action then it is relatively easy to uncover the cause and to correct it, but intermittent problems can be the very devil to sort out. There is also the worrying thought that when the computer swapped textures the results had been immediately obvious, but what about unobserved effects? Could objects be moved, changed in size or distorted without my knowledge? Could my printer cache be purged or my e-mail lost? These things are not likely, but neither was it likely that my stonework should turn blue. It might very well be that Poser, Daz Studio and many other programs all commit atrocities that we know nothing about - unseen and unsuspected - not as the result of some programmers' malice or incompetence but simply because of a fundamental weakness at the very heart of the system. This is infuriating and erodes confidence in what one is trying to do and the medium in which we are trying to do it. Perhaps one should abandon all current computer art and return to brush and canvas? At least the means are completely under our control and do not go wandering off on spurious missions of their own. I do not load a brush with titanium white and have it turn red when I apply it to the canvas, nor do I need to remember to pick up charcoal with my left hand before transferring it to the right for fear it be a Tuesday with Mars in the ascendant, for we all know that such a combination of circumstances can cause one's chair to collapse very abruptly.

Mornington Crescent !!!!! (Yay!)

As with custom and usage within society, so one learns a mass of unwritten rules only very slowly. Clearly, "stack" and "port" are words to be avoided at any cost, but what others are there? How many of them and in what context? Can you be sure about that? Without an intimate knowledge of the operating system, we can only guess and be alert to the possibility. As a good prophylactic measure, from now on it should be one's habit to avoid plain text wherever possible and in any of the known human languages. Certainly, I intend to exclude vowels from texture names in the future and will probably add a number or symbol. Thus, "yellow brick" might become "yllwbrck2" or "ylw_brk7". One cannot see a computer confusing that with anything else in its environment, but you never know. Aye, there's the rub; computers are developing language and rules of their own. They're not going to tell us about it - oh no - we have to learn them for ourselves through a long and painful process of trial and error.

In rebuttle to your comment above, maybe that is why many textures are named with just numbers and unless the number 666 does not send your computer to hell, though confusing for tracking down certain textures, it seems to work real good. MEPS!

What operating system managed to translate plain English words into machine language? Machine language is hexidecimal numbers, and eventually it gets down to binary. Only very "high level" programming languages use English words. Assembly language and machine language are all digits. It has to be that way for the speed that is required at that level in the computer. With all the operations that a computer is expected to perform per second, it would fail miserably if it had to translate English words into the machine language first! I suspect that the operating system is not the culprit, but rather it is indeed the 3D application that is not coded correctly. The word Portland should be able to pass from one module to another within the application without being sent to the operating system. It sounds like the proper method for passing a string was not used somewhere. I don't know about Poser, but it seems to me that DS is written in C# or C++, because that's what you need to use the SDK. I know that in C++, you have to be very carefull how you pass some parameters to functions...done the wrong way and you can really mess with memory in other areas of the application, and if you really do something wrong you can crash the operating system. Anyway, this seems very odd, very odd indeed.

Maybe I have the terms wrong, but I remember that 50 years ago one could write in English, for example instructing the CPU to transfer the contents of to the register, add contents of and save the results in . I always thought of this as assembler language, automatically translated into binary and acted upon, but it may have been called machine code. Whatever it is called, it seems to me that this is the level at which things are going wrong.

And it DOES, believe me. I have not invented the examples that I have given. Poser, Daz and countless other programs have inherited this 50 yo system and only lately has one seen signs of a new generation of programmers doing something about it.

Maybe I have the terms wrong, but I remember that 50 years ago one could write in English, for example instructing the CPU to transfer the contents of to the register, add contents of and save the results in . I always thought of this as assembler language, automatically translated into binary and acted upon, but it may have been called machine code. Whatever it is called, it seems to me that this is the level at which things are going wrong.

And it DOES, believe me. I have not invented the examples that I have given. Poser, Daz and countless other programs have inherited this 50 yo system and only lately has one seen signs of a new generation of programmers doing something about it.

Maybe I have the terms wrong, but I remember that 50 years ago one could write in English, for example instructing the CPU to transfer the contents of to the register, add contents of and save the results in . I always thought of this as assembler language, automatically translated into binary and acted upon, but it may have been called machine code. Whatever it is called, it seems to me that this is the level at which things are going wrong.

I have no doubt that these errors are happening. But for the computer to act upon machine language or assembly language from English words, there would need to be a translator in between. My suspicion is that something that is being done within the software is being translated because of improper programming practices, or perhaps the bad practice of using "undocumented features" which are undocumented because you can't depend on them being there the next time there's an update to the OS. Those kind of things often lead to very odd happenings. They are popular for some because they give an "easy" way to get something done. But easy isn't always the best practice.

I don't really know of these situations, because I've never run into them. I don't know what operating system(s) in which the errors are happening, either. Some older OSs are no longer supported and some of the changes in newer versions may be used by modern programming languages and are breaking in older OSs. Even Windows XP Pro is just barely supported...it's minimal. They were going to drop support, but they got a lot of complaints. It's a possibility. *shrug*

Thanks for the input, folks.
.
Anyone who has formatted their hard drive and rebuilt the entire system layer by layer from the bottom up begins to see it all like an inverted pyramid. We are all busy, busy, busy, tinkering with the topmost facade, but each frothy layer depends entirely upon the correct functioning of a smaller layer underneath, down and down, until at bottom everything depends on a few binary operations, like a handful of bricks supporting a vast structure.
.
I often wonder why it is that the team-heavy associations like Microsoft, Daz, Smith Micro and all the rest do not set a bunch of their guys to ensuring the complete integrity of these bottom layers, or why - having seen or experienced the problems outlined for themselves - they fail to see that it is not in their own best interests to allow this precarious state of affairs to continue. Wouldn't that be better than pursuing the latest sexy gizmo? Why fuss about the topmost fancy pinnacle when a brick in the basement may crumble at any moment and bring the whole thing down?
.
But there - we may philosophise, shrug and tut-tut as much as we wish, but in the end we have to cope with what we have. As I have said, one of the best ways is to avoid English words in texture names.
.
I wish that at the >> VERY LEAST << a list of these dodgy words could be published.</p>

Unfortunately, sexy sells, whereas building blocks that are not seen by most are considered boring. Why else would people run to buy cars that fall apart, blow up, tip over, but look so damned cool? This can be seen in every facet of society. Sexy sells. :roll:

LOL. You're right, of course. Heigh ho.
.
On the same topic, I had hoped to get the DS-only version of the palace uploaded yesterday (or today at the very latest) but - lo and behold!!! - displacement mappings are appearing all over the place and entirely wrongly. Could it be - damn! - that the same deep-laid error is screwing me again? Like regular textures, displacement mappings are also .jpg and loaded under the scene/surfaces tab. I'm getting fed up of this. I'll eat, have a beer, calm down and review it all.

If you mean the Poser version, you are very welcome. It loaded without a hitch and bids fair to become a favourite. I hope that it brings you and everyone much joy. Unfortunately, the D|S version has turned out to be a huge problem - not the fault of Daz themselves, nor even mine, but of something inherent and deep within the program. (See posts above.)
.
Let me summarise the current situation. With one thing piling on top of another, I have been almost compelled to rebuild the two end sections of the Palace. I don't really mind this (although I grumble) because the result will be more professional and efficient. It's all part of the learning process, which is usually absorbing. Right now, the entrances are being rearranged and my guess is that by tomorrow night the new D|S-only palace will be assembled and done. Fingers crossed. If all goes well, it should be uploaded soon thereafter.
.
May I take this opportunity to thank YOU, Perlk, for your help and kindness and for your work with the render competitions. I do not make an entry because I am usually too busy building, but I watch with interest and know how much you do.

If it uses English language to generate commands, and it converts this to binaries, what would it do if it got hold of some Japanese? And what about symbols that arise? It would then have to pass through a translator to English for it to be read. If that is the case and all pass through the translator, maybe the problem is with the translator and it is screwing up the English text. A possibility perhaps?

Yes, an assembler language is so-called because it translates language (English, Japanese, what-have-you) into binary and assembles it all into a binary program. It follows that each human language will have had someone write an assembler especially for it. From that we may deduce that different assemblers will (or may) contain different faults.
.
The particular fault that we are concerned about hinges around the method used (in binary) to transfer data. All binary can be either command to the CPU or data to be worked upon and just by looking at it, neither you nor I can tell the difference. Neither can the CPU - that is the important point. If data is confused with a command, all hell breaks loose. That is what has been happening. Properly followed, established protocol keeps a sharp distinction between data and commands, but it is abundantly clear that somewhere along the line, proper protocol has not been followed.

Work is proceeding slowly, I am afraid, so the D|S-only version of BP will not be uploaded for a few days.
Sorry about that - I know that a lot of people are waiting for it. We do what we can.
.
(Later) This is so bad that it has become a joke. Here is the latest error thrown up by D|S - a displacement mapping gone haywire. The normals of the building are correct, otherwise they would be black. Besides, the whole thing has been carefully redone and the normals are all double-checked. Nevertheless, the displacement mapping appears to follow rules of its own. I have never seen anything like this before and I doubt if anyone else has, either.
.
It is hardly likely that English names (data) have leaked into commands again - the structure is called BP99.obj and the displacement map called BP99_DISP. The texture is called BP50.
.
My thoughts at the moment are that I must try every alternative export from Hexagon and UVMapper and if that fails, remove the facets of the front and replace them in a different arrangement. I would be glad of any other suggestions.

Skipper, have you tried uninstalling and then reinstalling DS? Are you using the new DS4Pro? I've honestly not seen these errors before. I have yet to install and try DS4Pro, and now I'm wondering if I should bother.

I have uninstalled/installed quite frequently, but not lately. Perhaps I should. Actually, despite recent problems, I like D|S both for its facilities and the interface, although it is to be confessed that the gilt is going off the gingerbread. Certainly, I find myself thinking about saving my pennies and buying something really, really good.
.
I guess that it's all down to what you want to do and how much you are willing to pay for it. D|S is (or has been) free, so you cannot ask for better than that. Over three years or so, I have managed to produce some first-rate models with it and learned an awful lot. I still prefer it to Poser, for example. Are the current difficulties an aberation - something encountered only rarely - or can I expect a recurrence as my ambitions grow and I produce more elaborate models? I don't know. We must wait and see. For now, I shall press on, trying to find a cause and a solution.
.
For you and anyone else learning about 3D (and yourself) then all I can say is that D|S will give you a lot of fun.

DS is all I've used so far. But a few months ago I picked up Poser Pro 2010 for cheap at Amazon. I've yet to have a go at it, though. But I haven't done much of anything, so that doesn't mean anything. :red:

In my experience - for what it is worth - Poser is very good indeed with textures, which makes it a favourite among those who like to make fabrics or pretty complexions, but neither Poser nor D|S are very good when it comes to construction. For that, you need Hexagon. However, much is personal preference - there is something about one's way of thinking and working that either engages with a program or does not. Personally, the greatest problem that I have with Poser is the English language. I am a native English speaker and well educated, yet the way that Poser uses English (both in the program and the manual) constantly jars with me, leading me astray. "Oh, by 'xxxx' they mean 'yyyy' " I find myself saying. Nor is this simply because the authors are American - far too often, the very LAST consideration of manufacturers is the instruction book for users.
.
Try it. You may like it or you may not.

Well, I have Hexagon 2.5, so that's what I'd use for modeling anyway. However, there has been a lot of talk about Silo lately. A lot of people seem to like it very much and find it easier to do things with than Hexagon. I don't have money to throw around on new things like that, so I'll stick with Hexagon. They say it's better since the update late last year.

The other thing that's nice with Poser is the cloth room...you can make your own dynamic cloth! I don't know how difficult it is to do so, but those who have recently tried rave about how easy it is and how much nicer dynamics are over conforming items.

Oh, and on the English language...I find that the literacy rate is much lower than advertised. At least that's my determination based on what I see in forums and emails and even professional advertising and news articles. I can't believe some of the things I see coming from big businesses and top news agencies!

As for Poser's manual, I haven't read through it yet. But at least it comes with a manual! :P

LOL. I have not tried Silo, but if it is more stable than Hexagon, then it will be very well worth trying. Even the latest version of Hexagon will crash if you just wave your mouse at it! (And I'm not kidding.)
.
I agree entirely about literacy, but my main complaint about Poser rests upon the fact that in 50 years of life, it has been subject to countless revisions under loads of different teams, one of whom has gone into print saying that the program is so complex that even they (the programmers) do not always understand what it is doing.
.
As for the manual - good luck. There are countless passages in it - even whole pages together - when having read, I have laid it down and asked, "OK - what has he/she actually SAID?" I have published several books on computing and even after retirement continued to lecture on the subject. I once gave a fellow-lecturer the Poser manual and asked him to comment. He returned after an hour with two huge sections circled. "This is meaningless," he said, "and this is fine if you know it already." Exactly. The manual is not written with the tyro in mind but with the intention (it appears) of impressing the user with the status of the writer(s).
.
BTW, your instincts appear to be sound. Last evening I reinstalled D|S and so far today there have been no more ghastly errors. Keep your fingers crossed.

LOL. I have not tried Silo, but if it is more stable than Hexagon, then it will be very well worth trying. Even the latest version of Hexagon will crash if you just wave your mouse at it! (And I'm not kidding.)

I agree entirely about literacy, but my main complaint about Poser rests upon the fact that in 50 years of life, it has been subject to countless revisions under loads of different teams, one of whom has gone into print saying that the program is so complex that even they (the programmers) do not always understand what it is doing.

Also not good to know. :down:

As for the manual - good luck. There are countless passages in it - even whole pages together - when having read, I have laid it down and asked, "OK - what has he/she actually SAID?" I have published several books on computing and even after retirement continued to lecture on the subject. I once gave a fellow-lecturer the Poser manual and asked him to comment. He returned after an hour with two huge sections circled. "This is meaningless," he said, "and this is fine if you know it already." Exactly. The manual is not written with the tyro in mind but with the intention (it appears) of impressing the user with the status of the writer(s).

Even less good to know, although I've seen quite a few people saying the manual really helps them.

BTW, your instincts appear to be sound. Last evening I reinstalled D|S and so far today there have been no more ghastly errors. Keep your fingers crossed.