Results 1 to 9 of 9

Thread: Is there any example that uses other than TIME for sampler INPUT?

  1. #1

    Question Is there any example that uses other than TIME for sampler INPUT?

    Hello, I'm developing a COLLADA parser with JavaScript, and while I'm reading about the animation part of COLLADA specification,
    a small note made me confused.

    The COLLADA specification notes that (COLLADA 1.4.1, 2nd Edition, page 5-102)
    Keys are often TIME values, but they can be any other variable. For example, it is possible to associate the
    rotation of a wheel of a train with the position of the train on the track, so, by moving the train forward or
    backward, the wheel and other mechanisms can automatically move.
    However, I haven't seen any example doing this, and it doesn't seem to be possible since channel's target is specific channel - matrix, vector, etc.
    Furthermore, all other tags don't support specifying input channel - such as object position, rotation, etc. Only TIME seems to be possible because it's a global variable.
    Code :
    <channel source="#Box-Translate-X-Sampler" target="Box/Trans.X"/>

    So, is there any example that uses other than TIME for sampler input? Or, is there any COLLADA implementation supporting this feature?

  2. #2
    I am wrong here. I misunderstood the question, kind of. See #9 for my new answer.

    I don't know if I can be of help, but while I was working on the SIDREF selection function, TIME is listed among the possible targets. At first I included it among the targets, but ultimately decided that it was probably a false lead or that the list of all-caps properties that are most SIDREF targets might have some other application. Ultimately I removed TIME from the SIDREF default resolver. This could be completely unrelated to the animation samplers, which I don't yet have experience with. Still targeting animated parameters is almost always facilitated by SIDREF, so I would not be surprised if there is a connection.

    Somewhere else in the manual (perhaps in that table of all-caps properties) I got the impression that TIME would be like a "fourth" property in some circumstances where like a scalar, or vector, or matrix, is glued to a TIME forming a "key" as is commonly meant by "key" in graphics elsewhere, that is a value and its key, which in animation the key is usually a time, but in the sense of pacing and looking up the value as if in a directory, which is the more general meaning of a key in a database.

    My impression is COLLADA is very much rough around the edges, and I'd not be at all surprised if parts of its documents are in error or just don't add up...

    That said, my reading (and it's not so simple) of the situation is that if you want a factor other than a time table to drive an animation, then the <sampler><input semantic=INPUT source> would specify a <source> that is not time based. The <channel source> is actually a <sampler> and not a <source> it seems. Which is confusing in itself if so.

    That said, my understanding of <source> is that it's basically static data. That said, the only method I see to accomplish this is to use a <SIDREF_array> as the the contents of the source. And to be honest, in my experience, that's probably what the authors have in mind, even though the quip there gives no real impression everything that is involved.

    COLLADA was left unfinished. It's totally possible there are not examples. If you are working on COLLADA stuff today, you are practically at the ground floor of COLLADA, and you are arguably working on a technology that is fundamentally broken without a new generation of technologists that aim to see the premise/promise fulfilled 10 years after.

    Also, I wouldn't call a JavaScript implementation of COLLADA a parser. If you are doing something special perhaps, but JavaScript probably has a reasonable XML parser. After it is parsed, you are in different territory. That is what your application is. But it's not parsing
    Last edited by Mick P.; 02-06-2017 at 08:20 PM.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

  3. #3
    That's kinda sad to hear. I think I should only support TIME for now, since there are no other applications that use other than TIME for animation input.

    Maybe I can use IDREF_array to support other values, however, it doesn't look right since there's no way to interpolate values if there are more than two values in the IDREF_array. I'm not sure if <input>'s semantic can be duplicated too.

    I know COLLADA is kinda broken, but I didn't see any good alternatives for storing 3D models. Only COLLADA is widely used as an open 3D model exchange format - At least I think so. Recently I found glTF, which looks promising and lightweight. glTF's schema looks similiar to COLLADA's schema too. Maybe I should create glTF loader after finishing COLLADA loader, since I think a lot of code can be shared between them.

    And yes, I think I misused the word 'parser' - I was trying to mean loader. My implementation of COLLADA loader uses SAX style parser to convert XML to simple JSON (without using DOM), then the 'processor' converts the intermediate JSON to list of directly uploadable geometries, materials, textures, meshes, and node list, then finally 'renderer' bakes it into render tree, then WebGL renderer reads it and calls WebGL to render them. it looks quite inefficient, but I tried to reuse the code as much as possible.

    The code is quite a mess, but feel free to look around them if you'd like.

  4. #4
    I am wrong here. I misunderstood the question, kind of. See #9 for my new answer.

    I understand, but first, it's SIDREF_array, and not IDREFS (there is an IDREF like type in the schemas but it's not referenced.) Normally the reference to the <source> element would be an xs:anyURI type, which generally has open semantics, but for whatever reason the <source> reference of <input> is the custom type that restricts the URI-like reference to just a fragment, so that it must be local to the document. Presumably the requirement to use # is there so that a future revision/version might extend it to xs:anyURI. I don't know the rational for this.

    I wouldn't worry about how to treat an array with more than one SIDREF. Frankly it's not really necessary that the contents of the source are restricted to "_array" types, but the manual says it is, and I don't know but the menu of types is probably limited to the types supplied by the schema.

    That said, and assuming I am correct in my understanding, then the only real concern is that other software is unlikely to know what to do with such an input. But there is precedent for such handling in the <newparam> type, which can include <SIDREF> as a variant option. It's very possible that there is no other use for a <SIDREF_array> based <source> but the only way to know would be to scour the manual exhaustively. What I'm trying to say, is this use may be why it is provided in the first place.

    COLLADA isn't "broken" so much as left unfinished. It looks like there is a lot of support for it, but it's more like it was a fad for a while, so a lot of people worked on it enthusiastically, but then the bottom fell out. It gives the impression that it's well supported, but it isn't. In theory it might have good support under Maya and 3DSMax, but I doubt it. Still, files that come out of those tend to be better than the average application's. Problem with that software is it's out of reach for regular people, and so there are solid grounds for avoiding that software out of principle.

    But you are probably right. I could find no alternatives either last year. So I ended up spending all of 2016 to make COLLADA a viable technology. I didn't plan to, but the XML design makes it very heavy lifting. That's part of the reason it's failed to take hold. Another part is AutoDesk bought every commercial 3-D house, so the original thought behind COLLADA that it would help to be a bridge between these houses is kind of moot after there is only one house. Crazy hyper capitalist age we live in. Right now I think all interest in COLLADA is going to come from noncommercial interests, which for 3-D is kind of a new development.

    I think "SAX" is a very awkward technique. Programmers are by nature lazy and shortsighted, so they lean on it. But I find its backward logic tedious and counterproductive. I am busy rewriting the original COLLADA-DOM library, with a space age approach to XML for C++ that I hope will ingratiate COLLADA to the likes of Blender. Which even though it long dropped official support for COLLADA still has it as its default export/import target. Which goes to show you, there's no alternative to it. So we just either have to finish it or invent something from wholecloth. At this stage the former just makes more sense. Especially since we don't have a lot of experience with this sort of thing. That isCOLLADA itself is experimental/groundbreaking futuristic technology.

    When WebGL was brand new/experimental I developed a custom JSON loader that isn't SAX based for my own use. There's a design document here ( just to see what such a thing looks like. I only learned about glTF when I started investigating COLLADA. It didn't exist at the time naturally, and it's still relatively new. On the WWW glTF may make much more sense than COLLADA even though I think it's unproven. All of the existing standards are heavily OpenGL based, and glTF and COLLADA are really two different problem domains.

    I hope we are on the cusp of a COLLADA renaissance. I am thrusting myself in the middle of it. Slowly worming my way into the possibility of reviving it. It's not the most brilliant thing in the world. But it got a lot of publicity and so it seems like the best candidate for the basis of an open 3-D standard. We can use all hands on deck
    Last edited by Mick P.; 02-06-2017 at 08:21 PM.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

  5. #5
    BTW: Is your loader for web pages? Or is it more like a standalone application where JavaScript is the language of choice? Is a system the loader is plugging into? I've never heard of it. PS: There are some links on the page upstream from that link I posted with 3-D web applications. Just for fun. I did the project to determine what the performance of JavaScript would be like. I came away from it thinking that it would be a few decades before any substantial 3-D application could be hosted by JavaScript in a browser without a beefier computer than most people can have. Anyway, I feel you. (There are like a thousand 3-D models inside that website, in a database. They all came with an RPG maker made by From Software a long time ago. They are a popular Japanese company nowadays.)
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

  6. #6
    I found this ( just now. You might be able to find some examples in here if you've not already tried
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

  7. #7
    Oh my god, I totally forgot about this thread, I'm so sorry.

    I know that SAX is pretty awkward, but I just needed to convert COLLADA format into internal JS format, so even though many JavaScript environments support XML DOM, I used SAX for quick parsing. (Not sure if using SAX is actually faster though.)

    The loader I'm making now is for web pages, but there are some programs that allow to run Web application as a desktop application. (Basically, it's Chrome browser without fancy stuff) Also, webglue is just a simple WebGL wrapper, which allows using WebGL by creating JSON-like structure. But webglue-collader-loader doesn't really call webglue by itself, but requires applications to make call to webglue.

    JavaScript environment in a web browser is quite fast to run simple games, however, it kinda provides poor multi-threading support. (There is WebWorker support, but it doesn't support memory sharing, and it doesn't allow making WebGL call inside WebWorker in most browsers yet.) Other than that, it's fast enough. It kinda works pretty well, in all platforms, even in smartphones. I thought making simple 3D application that doesn't need an installation and running a binary in the Web is awesome, so I started doing 3D stuff in JavaScript, not using native applications. (C / C++)

    Also, thanks for letting me know about the test suite repository. I've been making few 3D models for COLLADA testing, which was really hard because I'm not an artist at all.

    In case if you're wondering what I've done, Recently I've finally successfully loaded simple cat walking animation on WebGL using the loader. The shader (or normal vector) is kinda messed-up, so artifacts can be visible. You can check it out here:

    Press middle mouse button (MMB) to rotate around, Shift + MMB to move around, Wheel to zoom, 1/3/7 to rotate to certain angle, 5 to toggle perspective / orthographic view.
    A Blooper for the cat animation interpolation:
    Last edited by yoo2001818; 02-04-2017 at 06:05 AM.

  8. #8
    I think it's very awesome too. In theory. The problem I have with JavaScript applications is mainly that when people make them they assume their audience will have a very expensive computer, because if they didn't use JavaScript then the same application would run probably 10 times better as a native application, and so not require such expensive computers. I have the same problem with people who make 3-D video games. They just assume that their audience has computers that cost a thousand or two thousand dollars, and so they are radically limiting their audience to a kind of hermetic order, at a time that's very interesting because every computer sold now has a GPU, and that means that 3-D applications should be able to reach everyone, even in developing nations. It's a very interesting time that is being squandered.

    Here are some easy to access demos of the project I did years ago:

    These models come from Sword of Moonlight. I found that using memory very aggressively, by precomputing everything animation wise, and so using a lot of memory, which is a necessary strategy to get good performance in JavaScript, because computation is so costly, that I could get a model viewer going, on a practical consumer grade computer, but that it was nowhere close to populating a 3-D game like environment with fully animated character models and sound effects, to get even a very minimal game to work at an acceptable frame rate. Unfortunately computers aren't really getting any faster now either. So I didn't expect the situation to change dramatically.

    I actually think OpenGL made a big mistake in removing display-lists. I think that would be perfect for OpenGL ES on WebGL now. Since JavaScript cannot process things properly, it would offload these things to the native-drivers, and you could do a lot more with it. Everything old is new again eventually. I'm surprised no one had thought about adding them back. I don't guess you've heard anything about Display Lists returning?

    EDITED: It looks like you are the principal author of Webglue also? That name so reminds me all of different OpenGL extension efforts. Glu, Glue, Glut, Glew, there's probably 50 of them. I think Glu/Glext are most critical, but I've never liked OpenGL for the extension side of it. I really prefer the stripped down OpenGL ES. I just don't understand why drivers aren't published for it for desktops. It's such a better API but you cannot even use it without inflicting OpenGL extension level pain on yourself.
    Last edited by Mick P.; 02-04-2017 at 03:20 PM.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

  9. #9

    I figured the OP question out I think

    I don't know why, I guess I thought the INPUT was driving the animation. Because it's called INPUT. I found the manual very confusing because it keeps referring to <spline> and POSITION for no reason. I don't know why the same semantics are not used frankly. It's just confusing.

    Anyway. The reading TIME is quite obvious, since the only place that appears in example is in <accessor><param name> and also I think that's very weird, because I don't understand why <param semantic> is not used instead, since "name" is supposed to be a meaningless "human" readable descriptor. And that's all it appears to be. Which is not supposed to be actional information to software. I think that's very bad practice.

    So, if "position of the train on the track" is supposed to drive the animation, then you'd just see <accessor><param name="position of train on track"> (EXCEPT THIS WON'T WORK IN 1.4.1: because NCName is used for name. So position-of-train-on-track instead or something.)

    "semantic" I thought could have spaces, but it's NMTOKEN which is apparently unrelated to token. I think it may have to be all-caps. So <param semantic="TRAIN_TRACK"> is maybe meaningful. But this is very application specific. So most likely you just get a "time" slider, and you can move it in a viewer to see what happens. Only if the data is specifically for a game or something that does this does it really make any sense to interpret the INPUT any differently. And really COLLADA shouldn't be so tailored. So in this example, I think "name" is actually more appropriate than "semantic" but normally I think where <param name> is used it'd be better to have used semantic, so that "name" could be a more flowery description.

    Bottom line is COLLADA doesn't provide a way to specify the animation's context and to have it driven like that. Theoretically it could be done with SIDREFs but this is not what the manual is suggesting. And it'd have to work differently from how I'd imagined it. (Multiple SIDREFs would have to work as timestamps.) And it would depend on how COLLADA would playback a movie with multiple animations being kicked off. I assume that's something it can do, but I don't know off the top of my head how it does, and so it's possible it cannot. I assume I just haven't come across the part that does that yet. It'd be a shame if it cannot.
    Last edited by Mick P.; 02-06-2017 at 09:04 PM.
    This account can Moderator spam in the COLLADA forum.
    ColladaDOM 3 (COLLADA-DOM 2016)

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
Proudly hosted by Digital Ocean