Parsable Meta-Data for High-detail vs. Low-detail parts and primitives


Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives
#22
Chris Dee Wrote:Why should we have to update p/cyl5-16.dat when p/48/cyl5-16.dat is added to the library?

Hi Chris,

I am sympathetic to the desire to minimize cross-file changes, although I think the extent of them would be contained (e.g. you could think of every version of cyl5-16.dat being a "family" of levels of detail, and edits would be contained within the family).

For a fully path based approach, what about specializing a part or sub-part? For simplifying studs having search paths on the /p/ directory works, but if I want to produce a _really_ high-speed 1x1 brick, I need to be able to replace 3005.dat with a new version with "stuff" cut out.

What do you think about parts/<lod>/ being a legal part search path, and or parts/s/<lod>/file.dat being a legal search path for sub-parts?

My concern is the search rules might get a little bit weird, but for "draft" quality rendering, I think we need LOD access to the parts, not just the primitives.

Cheers
Ben
Reply
« Next Oldest | Next Newest »



Messages In This Thread
Re: Parsable Meta-Data for High-detail vs. Low-detail parts and primitives - by Ben Supnik - 2013-08-18, 15:09

Forum Jump:


Users browsing this thread: 1 Guest(s)