Site wide search powered by YaCy*

Exit: A month ago,

-- A month to go.

May 29th, 2016 by Holy at

It’s been another month already, with nary a peep here, and so, this month, I should try to explain what this work of late is, and what it is-not, and what it means in practice to Sword of Moonlight.

As you must realize — if you’ve been following the proceedings — this COLLADA-related work is to have bearing on the 3-D art side of Sword of Moonlight (SOM) development. But how? This isn’t a simple question, and for now it needs to be restricted to just the work that has been underway so far; as this project is expansive in scope, as much so as SOM is: and, so far I’ve not been able to escape the gravity of “planet-COLLADA!” I’d not expected the job to be so great, but I had anticipated that it might go this way; COLLADA is, or was, a grand project that began about a decade or so ago. It hasn’t fallen off the face of the planet — yet — but it’s only that nothing’s come along to fill its shoes, it hasn’t.

COLLADA hasn’t been a success, and it’s sputtered for years. It hasn’t been taken seriously. There are too many temptations, and the problem it’s meant to address is an old problem, that people are just used to, and so so-easily accept the status-quo. Part of the problem is COLLADA is titanic in its ambition. Its originators believed it would run on its own gas, and that titans of industry would see its promise clearly, and do all the heavy lifting for them. This is an easy criticism of groups like Khronos and other standards committees to begin with. But the problem with COLLADA, is that although it sought to fulfill a need that titans-of-industry have; it also has in it seeds of these very industries’ destruction — It’s more attractive to industry outsiders, like us, and so no one has taken it to heart, or needed to, enough to.

The COLLADA standards (there are actually two) are based on “XML Schema,” or a recommendation by the group that seems to manage many, but not all, of the various standards surrounding software-related technology that is used in large by the Internet. XML Schema is not the only thing like it, but it’s what COLLADA used, and is what the biggest names on Internet guiding principals came up with. COLLADA’s use of this schema is very complicated, and the schema itself is very complicated. It’s not directly applicable to programming. XML computer files look a lot like HTML files; except they are more strict, as XML is more geared toward the needs of software programmers, than that of people who would’ve made the first webpages, and I still make webpages by hand myself, to this day. (There probably isn’t a better way.)

When you visit a webpage on the Internet, and it has parts that you can interact with, that are not part of your web browser’s basic facilities, it is most likely doing so via what is called the “DOM,” or Document-Object-Model. This is part of a process where the HTML in the webpage is made available to scripts embedded in the webpage — most likely JavaScript — that have the express purpose of animating, or rewriting the page, in real-time, so-to-speak. Now the page itself probably was not originally created by such an animation-script; although it can be. But for COLLADA, it’s not something that can be readily written by hand. Parts of it could be. But ultimately there are fields that must be filled with lots and lots of data, that are not written text at all. So you can say, for COLLADA, to begin with, animating it, and creating it, are fundamentally the same.

You can approach it in different ways. The way we weak-willed humans are wont to, is to treat the COLLADA file, as if it’s a written text, and then manipulate little differently from a demoniac, code-driven text-editor. It’s one way: but not a good way, or the right way. Text is the lowest-common-denominator in the world of software; the furthest you can get away from it, the better you known you’re doing. In a word, to trade in text, is unhealthy: it signifies weakness, and frailness.

In the world of software, there are two main disciplines or philosophies where programming is concerned. One is “strong types,” and the other, is “weak types.” The COLLADA-DOM project actually happens to use both. It has its DOM (mainly databinding) library, which is written in C++, that is well-known for its strong-typing; and it uses PHP, which actually looks superficially like C++, but in fact, it is perhaps a strong contender for the throne of king of weak-typing. The difference between the two is worlds apart. Ironically the project uses PHP to generate configuration files, which are in-fact C++ files, in order to implement the C++ library, which caters to C++ development. That is; the real goal is C++, and not PHP.

PHP’s weak-types do make it somewhat nimble, and easy to get started with, but the greatest praise I can afford it I guess, as it relates to COLLADA, is that turning to work on the PHP-side of the project, serves as a regular reminder of just how critical C++’s type-strength really is! What it means to be “strong,” is at its base, that your written code is ill-formed if the “types” of things or concepts therein are not compatible with one another. It’s apples-and-oranges so-to-speak. It really is. If your program does not have this level of introspection, then you do not find out you’ve been mixing apples and oranges until your program is turned on … and even then, the parts of the programs that are mistaken may not interact with one another on a given round of use. The problem can go unnoticed in other words. This can happen with strong-types as well, only the greatest class of errors is taken care of, and the turn-around of write-code, test-code, is much more productive. Even still C++ is known for necessitating long development cycles. But it also scales naturally, and outperforms the alternatives at every step of the way for the most part. (The PHP-based generator can take all of the time it needs; here is a case where “outperformance” is of no importance. Still it is beguiling to develop for! I should add that this website makes generous use of PHP.)

And so, the first leg of this journey, is to translate COLLADA into C++, and to abide by its strictures absolutely — which, as near as I can tell, has never been done before! (It has many strictures.) To do this, the PHP-based code-generator is fed the XML Schema-based schema, published by the COLLADA standards group. From which it produces C++ files, that represent the schema. These files are little more than configuration files, because their relationships are already defined by the COLLADA-DOM library. The library first-and-foremost implements databinding vis-a-vis C++’s very strong-type paradigm. Secondly the library functions as a basic DOM. Notice that the DOM that scripts in your webpage’s use does not share in C++’s virtues. E.g. JavaScript scripts are just a cut-above working with straight text; although not all schema enjoy the high degree of structure that COLLADA’s does: very often XML and HTML files describe highly-unstructured content, in which case the trade-offs of weak-v-strong do shift ever so toward the weak, as where there is not structure, there is nothing from which to draw strength.

This process does not spring to form something that looks like a 3-D modeling package or viewer; but it does plant a strong foundation, to serve as the basis for future works. COLLADA itself, I believe is more like a foundation, or something to hang our hats on, because there is nothing particularly COLLADA about this library. It’s in the service of COLLADA, but as already explained, COLLADA is a schema that describes XML files, and at almost no point in this description is there anything uniquely COLLADA about it: So, in fact you can say that the library is really an XML-library — and by no means the first; but one dedicated to COLLADA, but to this end, I’ve taken the opportunity to divorce the library-and-generator from COLLADA as much as possible, ideally completely so, that Sword of Moonlight can use it for more. And indeed within COLLADA and XML itself is the promise of extensibility, and I think without this extra-added flexibility, COLLADA simply is not-COLLADA, and cannot realize its real potential, or even fulfill its own prescriptions.

And so in conclusion, this work is to do something like what JavaScript does for webpages, only with C++, for XML, for COLLADA — and everything and anything else that can be factored into this paradigm: which can mean developing and publishing our own XML schema for our own needs, and also integrating others, as they develop, all while having a very fine development framework for doing so; and all thanks to having been prepared at the very beginning!! It’s all kinda interesting in a way, insofar as an XML file, describing a schema, is converted by a generator, into software code, as if a programmer had pored over the schema and reproduced it, and then that code, mixes with non-generated code, to enable the development of new code, in order to work with — drum-roll — yet-another XML file! Only in this case each file is an artwork, or something else, depending on the schema it is based upon. These files can also hang off of each other, much like the structure of the WWW (World-Wide-Web) itself, and even incorporate each other inside each other. (And sometimes it feels like everything is spinning out of control. It’s evolving faster than we can pretend to be abreast of.)

Forum Discussion

Leave a response

Exit | Forum | Sitemap | Main Index | Ex | Top