Post by fs on Jan 30, 2019 1:41:49 GMT
I hit a snag/gotcha on the test yaml file for the new "Bonus Chapter: Bounding boxes and hierarchies" due to unexpected behaviour (to me, anyway) in the macro expansion/instancing.
An "add:" that expands a macro and also specifies a "transform:" in the "add:" block referencing the definition doesn't replace any transform that was in the macro definition, it pre-multiplies additional transform elements to it.
For example, the front-most dragon definition is:
The "transform:" at the end is augmenting the two transforms that are in the earlier dragon macro definition, not replacing them.
[ There's a similar construct in bbox which augments instead of replaces the transforms that are in the raw-bbox definition ]
The net effect for this dragon is that it should end up with this final transform:
In these specific cases, I think I would have expected the additional transforms to be specified using a wrapper group around the object to be transformed (as is done to transform the combined dragon and bbox pairs for the other instances).
In the absence of a concrete definition of how the macro expansion should work in all these cases, I've been trying to keep my implementation straightforward and generic, without needing special knowledge of how to handle individual named keys during expansion.
So far, I'd handle an expansion like the "add:" above by:
a) making a recursive copy of the expanded macro from its definition ("dragon" in this case)
b) applying any top-level entries provided in the "add:" block, and setting/replacing them in the copy of the macro expansion (like "material:" and "transform:" in this example).
The set/replace approach made sense to me (so far). If I supply a "material:" in the "add:" block, I want it to entirely replace the material definition from the macro definition if it had one, instead of creating some composite material (or some other rule, like adding/subtracting values to the individual fields - eg "ambient: -0.2" meaning reduce the ambient value specified in the macro definition by 0.2).
I think my next tweak to (b) is to append-instead-of-replace if the value of the key is a yaml sequence instead of map type in both the copy of the definition and the "add:" block. That would append the transform sequence entries to any existing transform sequence entries [but presumably, only for the top-level keys found in the "add:" map...].
[ But maybe there are cases (later) where I do want to replace if it's a sequence? Then it'd be case-by-case basis depending on key name ? ]
Based on the examples I've seen to date, that rule tweak is my next step/new assumption about how the yaml "should" work.
That rule tweak might make adding multiple macro expansions to the "children:" section of a "group:" more pleasing instead of needing to add nested groups for each macro child in that case.
But, I think the nub of what I'm trying to get to, is that IMHO it's time to properly document the emerging YAML format and especially how macro expansion is supposed to work, rather than everyone who goes to implement it discovering/ bumping into behaviours (or changes to) and maybe making the wrong assumptions etc just based on the example files currently available.
It feels like it's important to do something here, as more scenes get published (and maybe by others too).
Thanks for all the great work - and sample scenes - so far. I know from personal experience how time consuming they can be to create
Edit: After doing that tweak, I got a render passing
An "add:" that expands a macro and also specifies a "transform:" in the "add:" block referencing the definition doesn't replace any transform that was in the macro definition, it pre-multiplies additional transform elements to it.
For example, the front-most dragon definition is:
- add: group
transform:
- [ translate, 0, 0.5, -4 ]
children:
- add: pedestal
- add: dragon
material:
color: [ 1, 1, 1 ]
ambient: 0.1
diffuse: 0.6
specular: 0.3
shininess: 15
transform:
- [ rotate-y, 3.1415 ]The "transform:" at the end is augmenting the two transforms that are in the earlier dragon macro definition, not replacing them.
[ There's a similar construct in bbox which augments instead of replaces the transforms that are in the raw-bbox definition ]
The net effect for this dragon is that it should end up with this final transform:
transform:
- [ translate, 0, 0.1217, 0]
- [ scale, 0.268, 0.268, 0.268 ]
- [ rotate-y, 3.1415 ]In these specific cases, I think I would have expected the additional transforms to be specified using a wrapper group around the object to be transformed (as is done to transform the combined dragon and bbox pairs for the other instances).
In the absence of a concrete definition of how the macro expansion should work in all these cases, I've been trying to keep my implementation straightforward and generic, without needing special knowledge of how to handle individual named keys during expansion.
So far, I'd handle an expansion like the "add:" above by:
a) making a recursive copy of the expanded macro from its definition ("dragon" in this case)
b) applying any top-level entries provided in the "add:" block, and setting/replacing them in the copy of the macro expansion (like "material:" and "transform:" in this example).
The set/replace approach made sense to me (so far). If I supply a "material:" in the "add:" block, I want it to entirely replace the material definition from the macro definition if it had one, instead of creating some composite material (or some other rule, like adding/subtracting values to the individual fields - eg "ambient: -0.2" meaning reduce the ambient value specified in the macro definition by 0.2).
I think my next tweak to (b) is to append-instead-of-replace if the value of the key is a yaml sequence instead of map type in both the copy of the definition and the "add:" block. That would append the transform sequence entries to any existing transform sequence entries [but presumably, only for the top-level keys found in the "add:" map...].
[ But maybe there are cases (later) where I do want to replace if it's a sequence? Then it'd be case-by-case basis depending on key name ? ]
Based on the examples I've seen to date, that rule tweak is my next step/new assumption about how the yaml "should" work.
That rule tweak might make adding multiple macro expansions to the "children:" section of a "group:" more pleasing instead of needing to add nested groups for each macro child in that case.
But, I think the nub of what I'm trying to get to, is that IMHO it's time to properly document the emerging YAML format and especially how macro expansion is supposed to work, rather than everyone who goes to implement it discovering/ bumping into behaviours (or changes to) and maybe making the wrong assumptions etc just based on the example files currently available.
It feels like it's important to do something here, as more scenes get published (and maybe by others too).
Thanks for all the great work - and sample scenes - so far. I know from personal experience how time consuming they can be to create
Edit: After doing that tweak, I got a render passing
