+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: General (https://forums.ldraw.org/forum-12.html)
+--- Forum: Official File Specifications/Standards (https://forums.ldraw.org/forum-32.html)
+--- Thread: Proposed Flexible Part Language Extension (/thread-23048.html)
Proposed Flexible Part Language Extension - Orion Pobursky - 2018-11-30
The proposal for flexible part extension is now ready for discussion. I basically copy, pasted, and wiki formatted Roland's LDCad spec.
https://wiki.ldraw.org/wiki/Flexible_Part_Language_Extension
Here are some thoughts/notes for discussion:
- The wiki has a talk page for discussion. Please do not use that and have all discussions here.
- I removed the LDCAD prefix, should we add something else?
- I think we should officialize any unofficial donor parts Roland uses in LDCad
- I think we should require auto-generated fallback code. Thoughts?
RE: Proposed Flexible Part Language Extension - Lasse Deleuran - 2018-11-30
(2018-11-30, 21:19)Orion Pobursky Wrote: The proposal for flexible part extension is now ready for discussion. I basically copy, pasted, and wiki formatted Roland's LDCad spec.
https://wiki.ldraw.org/wiki/Flexible_Part_Language_Extension
Here are some thoughts/notes for discussion:
- The wiki has a talk page for discussion. Please do not use that and have all discussions here.
- I removed the LDCAD prefix, should we add something else?
- I think we should officialize any unofficial donor parts Roland uses in LDCad
- I think we should require auto-generated fallback code. Thoughts?
Wow! Great work structuring it nicely like this. As for you point regarding fallback code, I completely agree. Other extensions, such as 'texmap' and 'buffer exchange', work nicely because of the fallbacks.
By the way. Would it be possible to include some visual examples directly in the page? It is always nice to have some test files to check with when you develop the viewers.
Examples would also have been nice to have in the 'texmap' specification, but luckily we have some good threads with examples.
RE: Proposed Flexible Part Language Extension - Travis Cobbs - 2018-12-01
(2018-11-30, 21:19)Orion Pobursky Wrote: The proposal for flexible part extension is now ready for discussion. I basically copy, pasted, and wiki formatted Roland's LDCad spec.
https://wiki.ldraw.org/wiki/Flexible_Part_Language_Extension
Here are some thoughts/notes for discussion:
- The wiki has a talk page for discussion. Please do not use that and have all discussions here.
- I removed the LDCAD prefix, should we add something else?
- I think we should officialize any unofficial donor parts Roland uses in LDCad
- I think we should require auto-generated fallback code. Thoughts?
I think a FLEX prefix would be appropriate in place of the LDCAD one. That groups the PATH and SPRING metas together.
Could you explain what the utility is of having these show up in official parts? I'm not sure I'm understanding the use case in the official library.
I also don't understand what you mean by auto-generated fallback code. LDView doesn't support any of these metas, but it was my understanding that they were designed to be used by the editor to then generate standard LDraw geometry. So only editors would have any need to support them. Am I missing something important?
RE: Proposed Flexible Part Language Extension - Orion Pobursky - 2018-12-01
(2018-12-01, 4:59)Travis Cobbs Wrote: I think a FLEX prefix would be appropriate in place of the LDCAD one. That groups the PATH and SPRING metas together.
I was thinking something similar
(2018-12-01, 4:59)Travis Cobbs Wrote: Could you explain what the utility is of having these show up in official parts? I'm not sure I'm understanding the use case in the official library.
The official parts won’t really need this. I think the main use for these will be to standardize flexible part generation across editors/viewers. I feel this is one of the largest outstanding (aside from part snapping) in the LDraw system.
(2018-12-01, 4:59)Travis Cobbs Wrote: I also don't understand what you mean by auto-generated fallback code. LDView doesn't support any of these metas, but it was my understanding that they were designed to be used by the editor to then generate standard LDraw geometry. So only editors would have any need to support them. Am I missing something important?
Fallback code is optional. The entire part can be generated and displayed by the editor using only the info in the METAs. I believe LDCad actually does this and only generates the fallback code if requested. Where the fallback code is useful is for legacy editors.
RE: Proposed Flexible Part Language Extension - Roland Melkert - 2018-12-01
(2018-11-30, 21:19)Orion Pobursky Wrote: I basically copy, pasted, and wiki formatted Roland's LDCad spec.I think you forgot the CONTENT meta, its properties contain the global options like wire thickness for springs etc.
RE: Proposed Flexible Part Language Extension - Orion Pobursky - 2018-12-01
(2018-12-01, 18:42)Roland Melkert Wrote:(2018-11-30, 21:19)Orion Pobursky Wrote: I basically copy, pasted, and wiki formatted Roland's LDCad spec.I think you forgot the CONTENT meta, its properties contain the global options like wire thickness for springs etc.
Ok. I’ll add it.
RE: Proposed Flexible Part Language Extension - Travis Cobbs - 2018-12-02
(2018-12-01, 6:08)Orion Pobursky Wrote:(2018-12-01, 4:59)Travis Cobbs Wrote: I also don't understand what you mean by auto-generated fallback code. LDView doesn't support any of these metas, but it was my understanding that they were designed to be used by the editor to then generate standard LDraw geometry. So only editors would have any need to support them. Am I missing something important?
Fallback code is optional. The entire part can be generated and displayed by the editor using only the info in the METAs. I believe LDCad actually does this and only generates the fallback code if requested. Where the fallback code is useful is for legacy editors.
I don't think "fallback" is the correct term here. I think "results" is a much closer term to what you mean, unless I'm still misunderstanding. The META commands indicate how a flexible part should be generated, but in order to have an LDraw file, the editor needs to actually do the generation and create an LDraw file with geometry. And it seems to me that this is not at all optional. Put bluntly, I never plan to support any of these METAs in LDView, and I don't think it's appropriate for flexible parts not to display at all in LDView simply because it doesn't support these META commands.
Maybe I'm still totally misunderstanding what you mean.
RE: Proposed Flexible Part Language Extension - Orion Pobursky - 2018-12-02
(2018-12-02, 2:54)Travis Cobbs Wrote:(2018-12-01, 6:08)Orion Pobursky Wrote: Fallback code is optional. The entire part can be generated and displayed by the editor using only the info in the METAs. I believe LDCad actually does this and only generates the fallback code if requested. Where the fallback code is useful is for legacy editors.
I don't think "fallback" is the correct term here. I think "results" is a much closer term to what you mean, unless I'm still misunderstanding. The META commands indicate how a flexible part should be generated, but in order to have an LDraw file, the editor needs to actually do the generation and create an LDraw file with geometry. And it seems to me that this is not at all optional. Put bluntly, I never plan to support any of these METAs in LDView, and I don't think it's appropriate for flexible parts not to display at all in LDView simply because it doesn't support these META commands.
Maybe I'm still totally misunderstanding what you mean.
I agree that it would probably be pointless for LDView to support these METAs since it's not an editor. These statements are intended to standardize the flexible part structure for editors there by allowing consistent generation between editors. This will allow someone to take a model built in LDCad and open it in another (future) editor and be able to easily edit said model's flexible parts. This is not the case now as different editors use different methods and the underlying constraints aren't saved to the file.
RE: Proposed Flexible Part Language Extension - Orion Pobursky - 2018-12-02
(2018-12-01, 18:42)Roland Melkert Wrote:(2018-11-30, 21:19)Orion Pobursky Wrote: I basically copy, pasted, and wiki formatted Roland's LDCad spec.I think you forgot the CONTENT meta, its properties contain the global options like wire thickness for springs etc.
I read the CONTENT META. A couple of thoughts:
- The add fallback is probably not required since I think the generated (to use Travis's more precise terminology) content should always be added to the subfile.
- Since "fallback" isn't needed, is there a good way to fold the path and spring values into their respective metas? Or maybe a new meta for each?
RE: Proposed Flexible Part Language Extension - Roland Melkert - 2018-12-02
(2018-12-02, 21:22)Orion Pobursky Wrote: I read the CONTENT META. A couple of thoughts:The meta was initially setup to help LDCad choose a handler class for the subfile (model, part, spring, path, etc).
- The add fallback is probably not required since I think the generated (to use Travis's more precise terminology) content should always be added to the subfile.
- Since "fallback" isn't needed, is there a good way to fold the path and spring values into their respective metas? Or maybe a new meta for each?
To get this same effect we could also add a new type to !LDRAW_ORG, e.g.
0 !LDRAW_ORG Spring
and
0 !LDRAW_ORG Path
LDCad also expects a flexible subfile to be ether a spring or a path and it will basically ignore any other content.
The fallback property is mostly there to keep templates clean as those don't need the generated fallback code. And I was thinking sometimes you want to keep a mpd small by not including the flattened HQ fallback code. But in practice nobody uses this option.
I added the path and spring options to the CONTENT meta as it was there already anyway. We could move those options to dedicated !SPRING and !PATH metas .
If we do the above then we could leave the CONTENT meta out of the spec.
I also forgot to mention the GENERATED meta, I think this is what Travis is missing to understand the fallback approach.
An editor can use the SPRING/PATH matas to update the LDraw code after the GENERATED meta in a subfile.
Any normal LDraw viewer will knowingly or automatically ignore all the unknown metas and only process the normal content trailing GENERATED.
So LDView does not have to understand these metas at all, unless it wants to display higher quality versions of them.