Should we keep one or more mesh,camera,light per node.

[fabrobinet]

No description provided.

[RemiArnaud]

I would rename node to transform. It was a mistake in collada to use node (discussed this at the time, but was too late to change) , as it is too much a reference to a scene graph, where node is a base type - and all kind of objects with conflicting behavior are created from this type.

-----Original Message-----
From: Fabrice Robinet notifications@github.com
Date: Tue, 19 Mar 2013 14:16:00
To: KhronosGroup/glTFglTF@noreply.github.com
Reply-To: KhronosGroup/glTF reply@reply.github.com
Subject: [glTF] Should we keep one or more mesh,camera,light per node. (#13)

---

Reply to this email directly or view it on GitHub:
#13

[fabrobinet]

Hum, sorry I don't get the conflict you are referring to.

[RemiArnaud]

The conflict is a design conflict.
node appeals to scene graph design, which neither COLLADA scene or glTF
format are.

-- Remi

On Tue, Mar 19, 2013 at 4:15 PM, Fabrice Robinet
notifications@github.comwrote:

Hum, sorry I don't get the conflict you are referring to.

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

[fabrobinet]

I believe it is easier to grasp that node carries a node a transform, than having a transform which is not only a matrix but carries also a mesh. I know there are some famous precedents who did that but I never found that explicit.
Node also carries children and references, I think it is too much meaning for just transform.

[RemiArnaud]

Well, that is if you have them carry anything .. which is back to your
original question.

an instance can point to a transform
a transform can be just that, a transform that can have child transforms
and one parent transform.
as far as transmission format, it may be easier to store the parent (one or
zero), so that it eliminate the need to think about what exact structure
the application will be using (tree, DAG, list, dictionary), and have a
very simple structure to export.

-- Remi

On Tue, Mar 19, 2013 at 4:21 PM, Fabrice Robinet
notifications@github.comwrote:

I believe it is easier to grasp that node carries a node a transform, than
having a transform which is not only a matrix but carries also a mesh. I
know there are some famous precedents who did that but I never found that
explicit.
Node also carries children and references, I think it is too much meaning
for just transform.

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

[fabrobinet]

Well, I believe you should propose to reformat an existing JSON with your proposal to see how it would look.
I don't think we can have the concept of parents and DAG at the same time BTW.

[pjcozzi]

I'm open to seeing example JSON for @RemiArnaud's propsoal, but I otherwise agree with @fabrobinet about the naming and structure.

As for the original question, I also considered only mapping one mesh to a node. However, there are a few problems:

• This doesn't allow the full structure of COLLADA models to be preserved if desired, e.g., an application may want to know what mesh was selected, not just what node. Basically, anything with a COLLADA name, which is application-facing, should be preserved structure-wise (ignoring flattening optimizations).
• If we emulate this by creating new nodes that all share the same transform, we force the application to issue extra uniformMatrix calls (or track transform changes).
• Containing an array, instead of a single mesh, does not significantly increase the complexity of the schema, spec, or application code.

Given this, I decided to keep the one-to-many mapping. I'm open to additional discussion though.

As for camera and light - these need more thought.

I don't see why camera is part of the scene graph at all. Is it just to position it? What if there is more than one camera in the graph? I could propose some changes were glTF has a list of possible cameras, and a default camera, similar to how a material has a technique. Let me know if you want to see example JSON.

As for light, we need to consider this along with materials and shaders in general. I want to suggest that this is treated outside the scene graph, but we need to consider animation. Again, I can draft up some example JSON if there's interest, but it will be very high-level since there's still lots of work on materials to be done.

[fabrobinet]

@pjcozzi lights and camera are part of the scene graph because their transform is impacted by transform of the node / and higher level nodes they are attached too.
It is very common in files coming from 3DSMAX to have multiple cameras, on the application side you typically select which is the active one. For that part we have the same constraint COLLADA have and I cannot envision to not support that. This is particularly important when a higher level node is animated you want to have the camera/light trassforms impacted.

Then I agree, light will be tied to materials tied also, just like for material parameters, light parameters will update technique. I need to draft something here. will enter an issue about light specifically.

[fabrobinet]

@pjcozzi for one to many relationships.

A advise to have a single light and camera per node:

• a never saw a COLLADA file with more than one light / camera per node
• it is practical from the application to refer to a node with a single camera or light so that you can designate that node as your viewpoint

I concluded for mesh, an array was fine. That way (when not flattening..) you don't end up with an artificially bigger scene graph. Came to that too: "Containing an array, instead of a single mesh, does not significantly increase the complexity of the schema, spec, or application code.
"

[pjcozzi]

@fabrobinet This sounds fine:

• node to mesh: one-to-many relationship
• node to camera: one-to-one relationship

As for lights, I'll need to see the whole material draft first, but I could see having multiple lights in a node for all the same reasons of having multiple meshes, but I'm not sure in practice how often it will be used - or even how often the model's lights will be used compared to the scene's lights. I guess many engines will use both.

[RemiArnaud]

I see a lot of mention of 'scene graph' that I don't understand. I see no need to have a scene graph, and certainly would not like to call what we have a scene graph.

Yes, cameras, lights ... all have a position, given by a transform (a TRS) that can either be absolute (no parent) or relative.

Yes, multiple objects of different type may have the same position in space. But unlike with a scene graph it does not matter if that position is given by the same transform or not. What is certain is that multiple objects sharing the same transformation will all be at the same place.

In a scenegraph, we would create a node object of type group, this would have a list of nodes that all contain one geometry and has the property to not have its own transformation. Here I would simply say that several objects may have the same transform.

This parenting changes at run-time. An object kinetic becomes dynamic and is detached from his transform hierarchy to become managed through its dynamic constraints, and they may very well be attached back to its transformed hierarchy.

Having the object pointing to its transform could be a good way to go. But before I propose something, I want to ask if we are designing a transmission format or a run-time format? Are we imposing a style of how the engine must be programmed, or just a way to transmit the information:

If the later - then we should be concise and complete. It should be directly usable (as proof of concept) by an application but that's a lower priority.

[tparisi]

No we are not building a run-time format, just a run-time friendly format. We should not be imposing how engines treat the content. That being said, hierarchy needs to be represented in order for us to preserve the intent of the author, otherwise a group of transformations can not be animated.

r/e cameras - We should not stray from COLLADA with the library concept e.g. libraries of cameras. Libraries are dictionaries, a good file format needs those. And Patrick, cameras need transform information because they are placed in space and potentially animated.

I personally like Fabrice's scheme for the hierarchy. It's not perfect: node-as-transform is based on the history of scene graph type of designs, vs. transform-as-component, which is a more modern game design concept. But everyone understands it.

[RemiArnaud]

I'm fine either way, but wanted to make sure we have this discussion.

++ If we are going with nodes where things are attached to, why not simply
having:
-> TRS (relative or global transform for this node - a transform may be
specified relative, or may be global (relative to the root) - since we
don't have a parent pointer, it is important to have that information
-> list of nodes (childrens)
-> list of 'objects' using this transform - why do we need to have a list
per type? just attach all the objects in there, regardless of their type.

++ If we are going with transforms
-> parent (or null)
-> TRS
(that's it)

and for each 'object' that need a position, id of the transform to use.

[tparisi]

I don't like that idea. (Separating out transforms) I prefer a transform belonging to a node.

I do agree with your comment that it should be a list of objects, not a list of meshes, list of cameras, etc. Just list the child nodes. A node can contain a mesh, or a camera, or a light. Just like most of the other systems I've seen. That's my preference.

[pjcozzi]

Renamed scene graph to node hierarchy in 583087e

[fabrobinet]

This has been resolved already.
We agreed to have:

• 0..N meshes per node
• 0 or 1 camera / light
  If we ever have more than one camera/lights coming from COLLADA (I have never seen that anywhere..) we would have to duplicate the node to hold them, but that's really a edge case.

I'll reflect these changes in the converter.

[pjcozzi]

@fabrobinet is the converter updated now? Is this just a spec issue?

[fabrobinet]

converter not yet updated.

[fabrobinet]

pushed in dev-2 branch for now acdce2c
only had to to lights -> light in node`

[fabrobinet]

converter fix: now on master.

[pjcozzi]

Schema is up to date. @fabrobinet can we close this?