By kami
Hi Jeremy
I just found out that if we insert a MXS reference which has special characters (like an ÜÄÖ) it shows them correctly in rhino but does not render them at all (without any error messages).
They don't show up on the block manager as well.
Seems to be a bug?
The Maxwell SDK does not support such characters; they may work in some, even possibly most cases (for instance, I'm not able to reproduce the described behavior here, neither by having such characters in the path, or the filename, of the referenced MXS), but you would still do best to avoid them.
By kami
These characters are used a lot in my language and we use them often in file names (for path, for textures etc).
For scene MXS or render path and even for textures, HDRI etc. it works fine. The network render also has no problems with it.
I do not mind if I'm not able to use them for MXS references, but there should at least be an error message. My collegue has spend a few hours trying to figure out, why his MXS reference did never show up in the render but just in the viewport.
That would mean writing an error message whenever a non-ASCII character is used; this would be unhelpful for two reasons: a) in most cases, it would warn about a problem that doesn't exist, and b) since it would be shown so often, and because it would usually end up being wrong about there being a problem, it would tend to be ignored.

The reason for (a) is that it depends on how the machines involved are configured; if you type a Ü, it is encoded to an integer, and then later, decoded from that integer, back to a Ü, if the regional settings on the machine are the same as those that were in effect when it was encoded (I am simplifying things a bit here). If the regional settings are different, though, it will be decoded to some other character. In other words, it is not possible to know, when writing a file, whether it will end up being problematic later on, when it is read, because that depends on the machine being used to do the reading, not the one doing the writing.

We are working on things, here, to prevent this being a problem in the future (namely, changing all of Maxwell to use UTF-8 internally), but that work takes awhile. Even when we are finished, though, it will remain likely that there will be various softwares that you use, which have this limitation. There are only two ways of dealing with this: 1) making sure every machine that sees your files uses exactly the same regional settings, or 2) avoiding the use of non-ASCII characters. Ignoring the "moral" question of whether this should be something you have to think about, the fact is that from a business perspective, restricting yourself to using ASCII is likely to more reliably make you money, by reducing uncertainties in your workflow.

It is a bit like the decision whether to use something like Microsoft Word for your business documents, or to use plain text files; the former will be prettier, but will also likely cause problems at some point, when you run into someone who doesn't have Word, or who has an older version.

For more information on what is involved here, technically, you may like to read a bit about ASCII, Extended ASCII, Unicode, and UTF-8.
Help Volume RED

I found that best way to assign a maxwell material[…]

Materials Library not working

Do you mean via web? Or on a particular software?

I'm writing a converter for curves from Houdini to[…]

Free HDRIs for everyone

Thank you!