Results 1 to 2 of 2

Thread: SEROIUS DEFECT: Core, FX, Physics interdependencies (orthogonality)

  1. #1
    Senior Member
    Join Date
    Mar 2016

    SEROIUS DEFECT: Core, FX, Physics interdependencies (orthogonality)

    I know there is a section in one of the Collada PDFs that lists these basic divisions or domains of Collada.


    I may be leaving one out. Core is essentially geometry and animation. I do know know off the top of my head if it includes IK, or if that is considered Physics. FX is materials, textures, and shaders. Lights and Cameras are Core, even though they feel a little FX-y. Physics is everything else, unless I am forgetting?

    Now! The big problem with Collada in the wild is FX.

    Most software implements Core. Can handle import and export at least, even if it makes no attempt to preserve the contents of the file...

    But FX is where things break down. Dumb software doesn't know which profile to pick if there is more than one. Most won't prompt. And none that I've found venture outside of profile_COMMON.

    Ignoring Physics, here is a problem.

    In theory Collada could be used to link documents. So in theory an FX oriented piece of software, could link a file with FX information, to a file that is purely Core. Since 3D modeling software knows what to do with Core generally, this could be a way to work around the poor support for the FX feature set. And would free the FX/shaders oriented visualization software from needing to provide a 3D modeling feature set. And the 3D modelers then who are never implementing FX could just continue in this way.

    Except Collada cannot make these kinds of links, because FX and Core are not orthogonal to each other. At best the linking document can include <instance_geometry> but inside this element is <bind_material>. So this can work in a simple case, however <instance_geometry> goes inside of <node> and so to do this you cannot have nodes. You'd have to instance the nodes in the linked document one by one, but then you cannot change the material of the geometry--or that is, implement FX properly--with <instance_node>!

    THERE may be another option. I don't know. I was surprised to notice the <bind_material> can also appear under <instance_controller> which is something I'd not considered until I just looked up bind_material just right now!

    Nevertheless, I think it's a good design principal to try to make these divisions/domains completely orthogonal to one another. It allows applications to only implement one of them at a time. It's something to consider in future versions. Either as new ways of organizing elements, or by making the original ways obsolete.

    (edited: here by "applications to only implement one" I mean that the applications will alter the files they touch. So the XML files could in principal be broken up so that applications that can only be trusted with Core can only alter the file with the Core elements, and so on. Most likely applications that do Core/Physics are likely to have poor FX support. And applications that do FX may not have any modeling or physics support, and limited animation playback if any.)

    Now: I have to do more research into using <bind_material> with <instance_controller> I have not yet studied carefully the Controller elements. I will be very, very pleased if it's possible to wrap geometry in a controller and use it this way. But I've learned better than to get my hopes up
    Last edited by Mick P.; 03-03-2016 at 08:50 PM.

  2. #2
    Senior Member
    Join Date
    Mar 2016
    Quote Originally Posted by Mick P. View Post
    THERE may be another option. I don't know. I was surprised to notice the <bind_material> can also appear under <instance_controller> which is something I'd not considered until I just looked up bind_material just right now!
    I see. The controller isn't a macro object. To treat it as such the underlying geometry must be artificially converted into a unified "skin" mesh. And this would forbid multiple logical meshes taking part in a single macro object.

    I believe this is a real weakness. There needs to be a type of element/library that can designate multiple instances as a logical link target. This can be done with a instance_node, however a local set of materials cannot be applied to the contents of the node. There are probably other applications for this...

    The simplest fix is probably to let <bind_material> override the materials of <instance_node>. (Something like <instance_object> might better communicate intent.) In the meantime the best that can be done is to use <instance_controller><bind_material> and artificially smash all of the meshes together into a skin
    Last edited by Mick P.; 03-04-2016 at 05:57 PM.

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