LDraw.org Discussion Forums
Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Printable Version

+- LDraw.org Discussion Forums (https://forums.ldraw.org)
+-- Forum: Models and Parts (https://forums.ldraw.org/forum-18.html)
+--- Forum: Parts Authoring (https://forums.ldraw.org/forum-19.html)
+--- Thread: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives (/thread-9613.html)

Pages: 1 2 3 4 5 6


Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Ben Supnik - 2013-08-14

Hi Y'all,

A while ago someone pointed me at the low-detail versions of the stud primitives, which cut the polygon prism side count in half.

I just want to confirm that there is no machine-readable way to determine which files are higher or lower res versions of each other, either via a meta command or a separate index file.

I am interested in coding Bricksmith to dynamically swap between high and low res primitives to improve rendering performance without having to hard code a list of "known swaps".

cheers
Ben


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Chris Dee - 2013-08-14

There is no meta-statement within the file, although meta-information is effectively embedded in the file name, but this functionality in confined to stud primitives. Each primitive (files in ldraw/p) that matches stud*.dat will have an equivalent stu2*.dat partner in the same folder.

This dates back to the original LDraw implementation and is probably not how we would do it now. In concept it is not that different to the hi-res primitives which are stored in ldraw/p/48 and (when present) can be substituted for normal-res files of the same name. I wouldn't have an issue moving the ldraw/p/stu2* files to ldraw/p/8/stud* except that MLCad has a hard coded expectation and whinges if a stu2* file is not found.


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Magnus Forsberg - 2013-08-14

Have you tried doing that? I did, and it seems to work just fine.

I renamed and moved my P/stu2.dat to P/8/stud.dat and made a new P/stu2.dat as a move to-file, refering to P/8/stud.dat.
I also changed the description to "~Moved to Stud". No problem.
I even moved that new file to unofficial/p-folder. No problem
The only thing I can't do is to remove stud.dat from P-folder, and move it to unofficial/p-folder.
Then MLCad just stops working.

I don't know if this little test is of any relevans here, but I tried it and it seems to work.
Is it so that MLCad only need a file called stu2.dat in any P-folder to stay quiet, and the content of the file is not relevant?


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Chris Dee - 2013-08-14

I imagine all MLCad needs is a stu2* file in ldraw/p for each stud* file in that folder. Even if we move the physical lo-res studs to ldraw/p/8/ it doesn't release us from needing to issue a stu2* every time we add new stud* variant.


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Travis Cobbs - 2013-08-14

I'm not exactly sure if it's a good idea or not, but having a p/8 folder would allow for all the other circular primitves that aren't n/16 to be put there for software to use as desired. If p/8 were created, I think Magnus's suggestion of turning the stu2* primitives into moved to files pointing to p/8/stud* makes sense.

If you want to have some idea of what effect this would have on the look of models, you can mostly simulate it in LDView by going into LDView's preferences, enabling primitive substitution on the Primitives tab and then setting "Curve quality" to its minimum setting, and then checking the "Flat shading" check box in the Misc box of the Effects tab. (Note that "Flat shading" and "Smooth curves" are mutually exclusive; they're check boxes because they can both be disabled at once, but only one can be enabled at a time, so checking one unchecks the other.)


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Steffen - 2013-08-15

Oh, that sounds like a Good Idea ™ to me.
Keeping the "stu2" MOVED-TO's for a while (until MLCad has been updated........) would be tolerable for me.

Especially, putting the low-res stud variants into a dedicated folder
opens the way for ANALOGOUSLY treating their HI-RES variants:

JC Tchang has created a bunch of VERY NICE, VERY HIGH-RES studs,
which of course are somewhat redundant to LDViews internal stud replacement,
but they allow to use ultra high res studs also in other tools. They are here:
http://jc-tchang.philohome.com/manuel/part_hd.htm#studlogo_tchang
His current solution is, for switching between the studs resolutions,
to invoke a batch which replaces stud.dat etc.
I would better like to have his files included with the library normally as primitives,
and as hi-res-replacements for the normal studs, analogously to their low-res replacements "stu2*".

This additionally would solve ANOTHER of our currently pending problems: see
http://www.ldraw.org/cgi-bin/ptdetail.cgi?f=parts/3334h.dat
There, duplicates of our parts have been created, just to have better, hi-res underside studs.
This is a bad idea ™. Instead, we should analogously to the hi-res/low-res top studs,
offer hi-res/low-res underside studs, and applications should be enabled to switch between them
at runtime.


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Ben Supnik - 2013-08-16

Hi Guys,

Maybe I'm off in outer space on this compared to the rest of you, but....

It seems really fragile to have part substitution done by file naming conventions and not by a meta directive or something else that is "data driven" (meaning information about the availability of parts at differing resolutions is part of the part library download).

In other words, moving the stu2 parts to a folder solves this one problem once for now, but if any more res-specific parts are added, everyone's applications will need to be updated. :-(

What I was originally going to suggest (given that such a thing apparently does not exist) was a proposed meta data command that could point from the canonical mid-res part (e.g. stud.dat) to its high and low-res variants.

Thus programs could determine at load time from the currently library what resolution variants are available. If authors wanted to create additional versions of the parts, no software mods would be needed. LDraw viewers could write the code to detect variants once and then leave it alone.

cheers
Ben


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Michael Heidemann - 2013-08-17

Maybe I am wrong, but why do we need a new meta command?

If we are going to have two separate folder trees for high-res and low-res, then it would be easy to handle.

Every application reads the standard resolution. Now if you have an application that allow for low or high-res then the user has to inform the application that what kind of resolution should be loaded.

Benefit of this solution:
All current application work like at present (AFAIK)
The user chooses the resolution.

The only bad thing is that we need to define high and low-res standard. If we would like to have more resolution as the three current, then it would get complicate.


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Steffen - 2013-08-17

we from the beginning should care about different levels of high-res.
for example, for jc's beautiful studs I mentioned,
he already offers "3 increasing levels of detail and beauty".

sometimes they will not increase, but simply be alternative.
like "logo modeled by lines" vs "logo modeled by projected texture" vs "logo modeled from real 3D objects"


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - Chris Dee - 2013-08-17

Ben Supnik Wrote:It seems really fragile to have part substitution done by file naming conventions and not by a meta directive or something else that is "data driven" (meaning information about the availability of parts at differing resolutions is part of the part library download).
Ben

Yes, it is a bad design, but it dates back the the very birth of LDraw, and has unfortunately been hard-coded into MLCad (at least).