Hi Y'all,
It seems like this poll is an attempt to give ourselves permission to add to the .ldr file format more aggressively - in the past, some combination of cultural inertia and the need for backward compatibility with end-of-lifed apps has made .ldr extensions "off limits".
So I'd like to argue for -direct- extension of the LDraw format. I think in the long run it will produce the clearest, most understandable .ldr files; if everything is wrapped, interaction between extensions and scope is going to be more complicated.
There are two kinds of possible extensions:
1. Extensions where backward compatibility is easy, because the extension can be ignored (e.g. the proposed META to re-specify the origin.
2. Extensions where backward compatibility is hard because the extension -replaces- existing functionality (e.g. you can have one META sphere command instead of 300 triangle primitives).
The current texture extension tries to be in category 1 by providing backup geometry - you can ignore all of the new stuff and just draw the backup geometry. But to be really useful the TEXMAP extension needs to be in category 2, e.g. there certainly shouldn't be a backup triangle-based pattern to the part, because the whole point of texturing extensions is to save work for authors by letting them use a PNG file for patterns.
With that in mind, we can (relatively) easily provide backward compatibility against category 1 extensions (that are DIRECTLY in the .ldr and .dat files) by making a processor that strips them out, and making a second downloadable edition of the library that is stripped of new stuff.
I like the idea of a post-processed distribution more than wrappers because a second distro is a one-time tax on development - we have to develop and deploy the tools, where-as having wrapper files is a tax on development of every single program that ever parsers a new .ldr file for as long as we go forward.
For category 2 extensions, there's no way to win - if the newly authored part is truly not backward compatible with older clients for some reason, we have to either drop the clients, author 2 versions of the part, or not use the new extension. But that's something that needs to be decided on an extension-by-extension basis. For example, texturing was authored to intentionally make the backward compatibility case "ugly but not fatal" - you can easily have a solid triangle replacing your textured triangle - the part looks unpatterned but doesn't look like a bug. As we add new extensions, we'll have to consider this.
With that in mind, at least some of the things that have been tossed around that are somewhat 'major':
- Better normal vector support
- LOD
- Connectivity
- Meta data to "fix" authoring issues
Are all pretty clearly in category 1.
Two more comments on this:
- I do have a plan^H^H^H^Hpipe dream of doing some kind of connectivity in Bricksmith in the next year or so...and I strongly believe connectivity is best served with an in-file-format extension. Because LDraw parts are constructed from primitives, we can (in some cases) annotate a small number of primitives with connectivity meta-data and get a pretty big win in terms of part coverage. Doing that with a wrapper is going to make such an extension significantly less intuitive than it would otherwise be. (I think you can demonstrate that a wrapper system is functionally equivalent to extending the format - but it still puts a tax on all programs dealing with the wrappers.)
- When it comes to LOD, there was some support for LOD via a parallel file system, instead of in-file-format extensions. It's already how LOd is partly being dealt with, so there's precedent, and it's very unobtrusive. I don't think this parallel-library idea is wrong, and it wouldn't be crazy to do LOD that way even if most other extensions are going to be in-file.
Cheers
Ben
It seems like this poll is an attempt to give ourselves permission to add to the .ldr file format more aggressively - in the past, some combination of cultural inertia and the need for backward compatibility with end-of-lifed apps has made .ldr extensions "off limits".
So I'd like to argue for -direct- extension of the LDraw format. I think in the long run it will produce the clearest, most understandable .ldr files; if everything is wrapped, interaction between extensions and scope is going to be more complicated.
There are two kinds of possible extensions:
1. Extensions where backward compatibility is easy, because the extension can be ignored (e.g. the proposed META to re-specify the origin.
2. Extensions where backward compatibility is hard because the extension -replaces- existing functionality (e.g. you can have one META sphere command instead of 300 triangle primitives).
The current texture extension tries to be in category 1 by providing backup geometry - you can ignore all of the new stuff and just draw the backup geometry. But to be really useful the TEXMAP extension needs to be in category 2, e.g. there certainly shouldn't be a backup triangle-based pattern to the part, because the whole point of texturing extensions is to save work for authors by letting them use a PNG file for patterns.
With that in mind, we can (relatively) easily provide backward compatibility against category 1 extensions (that are DIRECTLY in the .ldr and .dat files) by making a processor that strips them out, and making a second downloadable edition of the library that is stripped of new stuff.
I like the idea of a post-processed distribution more than wrappers because a second distro is a one-time tax on development - we have to develop and deploy the tools, where-as having wrapper files is a tax on development of every single program that ever parsers a new .ldr file for as long as we go forward.
For category 2 extensions, there's no way to win - if the newly authored part is truly not backward compatible with older clients for some reason, we have to either drop the clients, author 2 versions of the part, or not use the new extension. But that's something that needs to be decided on an extension-by-extension basis. For example, texturing was authored to intentionally make the backward compatibility case "ugly but not fatal" - you can easily have a solid triangle replacing your textured triangle - the part looks unpatterned but doesn't look like a bug. As we add new extensions, we'll have to consider this.
With that in mind, at least some of the things that have been tossed around that are somewhat 'major':
- Better normal vector support
- LOD
- Connectivity
- Meta data to "fix" authoring issues
Are all pretty clearly in category 1.
Two more comments on this:
- I do have a plan^H^H^H^Hpipe dream of doing some kind of connectivity in Bricksmith in the next year or so...and I strongly believe connectivity is best served with an in-file-format extension. Because LDraw parts are constructed from primitives, we can (in some cases) annotate a small number of primitives with connectivity meta-data and get a pretty big win in terms of part coverage. Doing that with a wrapper is going to make such an extension significantly less intuitive than it would otherwise be. (I think you can demonstrate that a wrapper system is functionally equivalent to extending the format - but it still puts a tax on all programs dealing with the wrappers.)
- When it comes to LOD, there was some support for LOD via a parallel file system, instead of in-file-format extensions. It's already how LOd is partly being dealt with, so there's precedent, and it's very unobtrusive. I don't think this parallel-library idea is wrong, and it wouldn't be crazy to do LOD that way even if most other extensions are going to be in-file.
Cheers
Ben