LDraw.org Discussion Forums

Full Version: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Pages: 1 2
Wow, I'm pleasantly surprised to see this suggestion. I never would have thought anyone else would go for it either.

XML parsers are widely available, which reduces implementation time. XML is also well-documented and thought-out, which reduces arguments about how to future-proof features. Those seem like big wins to me.
Chris Dee Wrote:My initial thoughts were to suggest XML rather than continuing to develop the LDraw style of keyword-value syntax, but I didn't think I would get much support here.

I think XML would be a great choice -- and I think using an off-the-shelf syntax is a good idea vs rolling our own.

My personal view is that the .ldr/.mpd/.dat file conventions make sense within the scope of actual "documents", be they LDraw models, MPD models, or parts/primitives.

But for the meta-data floating around the system, there's no need to shoe-horn it; the meta data is unlikely to be edited by an LDraw editor and if it is, the editor will have to have separate UI for it.

Chris, what are the next steps with this? Is an LOD spec under the auspices of a particular committee or someone's supervision? Are we reaching a point where someone needs to write a spec?

I'd be happy to do the leg-work of writing a draft spec if that is useful. (I'm also happy to shut the heck up and let someone else do it if that's more efficient.)

From a practical standpoint, LOD support is something I would like to integrate into Bricksmith relatively soon to further push the performance envelope.

I also think XML is a good choice. In my opinion, this is a different situation from the color definitions in LDConfig.ldr. LDConfig.ldr uses LDraw syntax to define colors because that allows for the same definition language to be used by users in any LDraw file. If we decide that we don't want LOD information to be inside LDraw files (which we have basically done here in this thread), then using XML makes sense.
Strictly speaking only the LDraw spec and the meta-commands comes under the remit of the LDraw Standards Committee. The library organisation has normally been handled by the Library Admin following consultation. Four of the five Standards Committee members (Allen, Roland, Travis, me) have been actively involved in this discussion and at least three of us seem to agree on XML, so I think we are good. Roland, do you agree with XML?

A "spec" doesn't need to be over-complex, but if we want applications to use the new LOD config file properly we should publish its structure and usage assumptions. For example
- All primitives will always be found in the DEFAULT folder: ldraw/p;
- Different resolutions may be present in other LOD folders
- STUDLOGO folders, if defined, can optionally be used to enhance the selected LOD
Chris Dee Wrote:Four of the five Standards Committee members (Allen, Roland, Travis, me) have been actively involved in this discussion and at least three of us seem to agree on XML, so I think we are good. Roland, do you agree with XML?

I have no problem with a new XML config file, but if we go the extra file route maybe we should keep it open for more then just LOD? That way we have an LDraw 'global include'' file and a general config file.
I agree with the global config file notion. Although ldconfig.xml as a name would be considerably confusing. I kind of wish we could just ~Move LDConfig.ldr to LDColors.ldr. Tongue
Do "Curve quality" and "Flat Shading" make any difference to the level of detail when exporting to a 3DS file from LDView?

Also, I was wondering if there are high-quality parts for:
- Minifig Hand - 3820.dat
- Minifig Head - 3626* parts

If there are higher quality versions of the minifig head, is there an easy way to convert existing patterned head parts to use a higher-quality head (i.e. a smoother, more rounded head)?

No. The only exporter that is affected by "Curve quality" is the STL exporter. None of them are affected by the "Flat shading" setting.
nice to see that the change now appears on the PT
Pages: 1 2