Proposed converter and optimization pipeline

[pjcozzi]

We've done some mockup diagrams and had some discussions, but here is a proposed flushed-out architecture for the converter and optimization pipeline. Once we reach an agreement, I suggest making changes sooner, when they will be easier, rather than later.

The guiding principles are:

• Move as many optimization stages as possible to a general optimization pipeline for COLLADA models. Although not initially required, we can image a command line utility generally useful for COLLADA models built on this.
  • What is the state of the COLLADA Refinery? And is it useful here?
• The core COLLADA to glTF conversion routine takes a COLLADA model (in memory or from disk) conforming to a subset of COLLADA that glTF can handle, e.g., polygons to triangles, unsigned short indices, etc. The bulk of the transforms happen in the optimization pipeline beforehand.
• COLLADA2GLTF is implemented as a C++ library. A separate command line utility uses it, which is COLLADA2GLTF as we know it today.
• An example REST API built in node.js or php (looking for input here) uses the command line utility to convert COLLADA to glTF. Khronos will host this.
• Finally, as discussed at the meetup, a simple website would allow folks to convert COLLADA to glTF. Again, Khronos will host this.

[pjcozzi]

Also, the diagram doesn't show all the third-party libraries, e.g., image conversion, texture compression, mesh compression, etc.

[RemiArnaud]

yes, COLLADA refinery is very useful there. at least the source code.
but it is a COLLADA-DOM module, not a openCOLLADA.
Which BTW makes total sense, as doing those optimizations with openCOLLADA
is going to be REALLY hard.

I agree that the build of transforms should be collada-in / collada-out.
(or whatever in, collada out).
That way any format can be converted, optimized, and glTF transformed.

On Fri, Apr 5, 2013 at 10:57 AM, Patrick Cozzi notifications@github.comwrote:

We've done some mockup diagrams and had some discussions, but here is a
proposed flushed-out architecture for the converter and optimization
pipeline. Once we reach an agreement, I suggest making changes sooner, when
they will be easier, rather than later.

[image: image]https://f.cloud.github.com/assets/782098/345160/d2cb577e-9e18-11e2-99f3-ff6fdd22bde9.png

The guiding principles are:

• Move as many optimization stages as possible to a general
  optimization pipeline for COLLADA models. Although not initially required,
  we can image a command line utility generally useful for COLLADA models
  built on this.
  • What is the state of the COLLADA Refineryhttps://collada.org/mediawiki/index.php/COLLADA_Refinery?
    And is it useful here?
    • The core COLLADA to glTF conversion routine takes a COLLADA model
      (in memory or from disk) conforming to a subset of COLLADA that glTF can
      handle, e.g., polygons to triangles, unsigned short indices, etc. The bulk
      of the transforms happen in the optimization pipeline beforehand.
• COLLADA2GLTF is implemented as a C++ library. A separate command
  line utility uses it, which is COLLADA2GLTF as we know it today.
• An example REST API built in node.js or php (looking for input here)
  uses the command line utility to convert COLLADA to glTF. Khronos will host
  this.
• Finally, as discussed at the meetup, a simple website would allow
  folks to convert COLLADA to glTF. Again, Khronos will host this.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55
.

[fabrobinet]

I know that code well, it's extremely dependent of the DOM and makes a lot of allocation/reallocations.

glTF is not just about converting COLLADA, so having these functions separated (as they are in glTF) makes them reusable to convert FBX / OBJ...

But yes, it's a plus if the COLLADA model come well formatted already...

[fabrobinet]

@RemiArnaud this assume that people will be willing to convert assets to COLLADA which is not always the case, or they might just miss an exporter...

[fabrobinet]

Ideally, a glTF lib separated from OpenCOLLADA will allow to centralise all these transforms. (and maybe in a C++ meshtool lib)

[RemiArnaud]

glTF is not just about converting COLLADA, so having these functions
separated (as they are in glTF) makes them reusable to convert FBX / OBJ...

that's my point

FBX/OBJ/DAE -> COLLADA -> preprocess -> COLLADA -> gltF

that's the minimum amount of work

• FBX/OBJ -> COLLADA is already done, and free.
• preprocess -> lot of it already done in conditioner pipeline

On Fri, Apr 5, 2013 at 11:27 AM, Fabrice Robinet
notifications@github.comwrote:

I know that code well, it's extremely dependent of the DOM and makes a lot
of allocation/reallocations.

glTF is not just about converting COLLADA, so having these functions
separated (as they are in glTF) makes them reusable to convert FBX / OBJ...

But yes, it's a plus if the COLLADA model come well formatted already...

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/55#issuecomment-15972448
.

[pjcozzi]

If I am following correctly:

1. We are in agreement that it will be useful to have the optimization pipeline separate from the final glTF conversion.
2. We may be able to reuse some algorithms from the COLLADA Refinery, but not necessarily the architecture.
3. The missing piece is we need a DOM to keep the model in-memory between pipeline stages. We discussed this before with an idea being add a layer over OpenCOLLADA that is a DOM. It doesn't need to be part of OpenCOLLADA core (but it could be). As long as a reader can create the DOM, it will work with our optimization pipeline. Using COLLADA DOM is an option too if we are OK with users having to convert to COLLADA.
   • It would also be nice to have an optimization so the glTF converter can take the DOM in memory instead of having to write it to disk after the optimization pipeline and load it again for glTF conversion (granted the OS will cache it).

Is (3) the only thing we need to flush out?

[fabrobinet]

1. yes, probably.
2. as said, the code is just to tied to COLLADA DOM. I didn't find the algorithms particularly efficient there, but I just saw the deindexer and triangulation.
3. if we have the model in JSON objects that reflects the JSON output as it is today in glTF then we have everything we need to perform all kind of transformations. I find that having a DOM based on OpenCOLLADA is a bit orthogonal to this. When I create the glTF framework all this will appear clearly (with a cleaner API), but I don't think that's a priority now.

[pjcozzi]

I'm OK with this not being a priority now (although I just see it getting harder as we write more code), but it would be good to converge on the direction, especially if it helps direct outside help.

It sounds like you are suggesting that the JSON objects would be the DOM. I don't see how this is possible because we want to optimize much more than what is defined with the JSON objects, e.g., triangulation.

[fabrobinet]

Well, reading this again...
First I would distinguish between 2 kinds of transformations (and I believe you did too).
Optimizations (vertex caches/flattening etc...) and what is mandatory triangulation / unification of indices to produce a valid glTF asset. The later are so tied to glTF that the glTF framework should be able to handle them directly.

We are just brainstorming here, but I don't see why working directly with the JSON objects would be a problem.
What's the issue with triangulation ?

It would give consistent objets/api wether you work on object that you just imported from say OpenCOLLADA or FBX, and even once you have a glTF asset if you want to optimize it more.
What I am suggesting is that, because glTF is much more retrained that COLLADA the optimization pipeline can be more focused/simple and also common for all formats imported to glTF.

[pjcozzi]

First I would distinguish between 2 kinds of transformations (and I believe you did too).

Agreed, but the line is blurry. I see almost everything as an optimization or "conditioning." For example, triangulation is really an optimization because it adds very little overhead (just indices), and makes the model much easier to load at runtime.

I would make the distinction that anything that can fit in the optimization pipeline should be part of the optimization pipeline to make it useful for the widest possible audience and still useful to glTF, of course. I'm still working through my notes, but I'll have a better idea of what is where soon, e.g., I'm on the fence about shaders right now, but it is probably glTF specific because of the metadata.

Also, some optimization might need to happen very late in the pipeline, like, for example, vertex cache optimization requires deindexing, so the interop between the optimization pipeline and glTF converter needs to be good.

I don't see why working directly with the JSON objects would be a problem. What's the issue with triangulation ?

For triangulation, our JSON representation doesn't define a POLYGON primitive. Maybe I misunderstand what you mean by JSON objects - are you talking about a glTF representation or the COLLADA XML converted directly to JSON? If you are suggesting the later, that could be a reasonable option.

Give me a day or so to go over my notes on the potential stages, including what you have on the wiki, which should help this discussion.