 | | Re: What does a subpart with color=24 mean?
|
|
(...) Well, one that I have gives a warning message that says it can't handle color 24 and substitutes 16 for such lines. But I wasn't sure if that was correct behaviour. Another one that I've played with quietly accepts such lines, but appears to (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Actually, that grep doesn't return anything. '^[ \t]*1 24' does return hits from three files, though. Every single place in the library that this is used, it's used in a reference to one of the edge primitives. The edge primitives use color 24 (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) In the case of some kind of direct color, I guess the rendering program is free to do whatever it wants. The simplest action would be to default to black (either LDraw 0, or RGB #000000). I'd be interested to hear what actual rendering (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
Okay... that makes sense. But what if the contrast color for the current file's main color is just an RGB value rather than a color index? What should the subfile's contrast color be set to in that case? Thank you for your help, by the way. >> Mark (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) The contrast color within the subfile would be defined in the normal way - use the main color for the subfile, and look up the contrast color from the color table. The fact that the originating linetype 1 used color code 24 shouldn't matter by (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Right... but what should the contrast color be defined as within the subfile? The same? >> Mark (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Not exactly -- just use the current contrast color as the main color for the subfile. Whenever a subfile is rendered, it should already be looking up the local contrast color based on the local main color. Steve (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Does that mean that it would be appropriate for a renderer to just swap the main and contrast colors when it encounters such a line, or what? I just want know what a renderer is supposed to do. (...) Well, doing grep '^1 24 ' on the parts (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) It will be the constrast color for the constrast color. Which may be the same as the main color -- but it may not. Also, some viewers (like L3Lab) may balk at rendering a file which uses color 24 in a line type 1. Steve (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) OK, I was partly right. There actually is a standard defined for colour extensions, you can view it here (URL) it only applies to colours defined either in ldconfig.ldr, or in the part files or model files themselves. And it is still up to the (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Hi Mark, I'm pretty sure there is no standard for that, and it depends on which renderer you use. ROSCO (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | What does a subpart with color=24 mean?
|
|
How is the contrast color defined for line type 1, when color=24? >> Mark (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Proposal for MLCad.ini Enhancements
|
|
(...) hi allen, many thx for the .ini file fixes you sent me via mail. I'll load them up asap. the rest is michael's territory as I'm only the maintainer of the data. bye, w. (18 years ago, 19-Aug-06, to lugnet.cad.dev)
|
| |
| | Proposal for MLCad.ini Enhancements
|
|
In the course of writing a minifigure generator for my Bricksmith program, I've really come to appreciate how nifty it is to have something like the MLCad.ini file to work with. I've very grateful to the people who designed and maintain it. However, (...) (18 years ago, 18-Aug-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) Yes, basically. It wouldn't make any sense to add the parts\s directory, because those files are segments of parts -- they aren't complete objects in any sense. They are only intended to be used by part files, which should refer to them (...) (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) <snip> (...) Is it correct to assume because of this, the 48 and s dirs must not be added to the part search directories list? Roland (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) I've decided to drop the whole option for now, so the 48 dir is only used if parts reference to it by 48/xxx.dat . Roland (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) <snip> As might be expected, Steve's replies were correct (as far as I know, anyway ;-). (...) While it's true that this isn't all that useful, it can still be done, even though some parts reference primitives from the 48\ directory directly. (...) (18 years ago, 30-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) Not exactly. The files in the ldraw\p\48 directory are all based on a 48-faceted approximation of a circle. The regular primitives in ldraw\p are all based on 16-facets. Just because a file is in one directory does not mean a corresponding (...) (18 years ago, 30-Jul-06, to lugnet.cad.dev)
|
| |
| | 48 directory and non filename only line 1 part file names
|
|
Hello all, Still working on the LDraw loader. The 48 directory in ldraw\p, as far I understand it, is a 'alternative' source for primitives, not? Jet I see some (unofficial) files using type 1 lines with the 48\ attached to the part name reference (...) (18 years ago, 29-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) It's my work system, but I rarely use 2005. Most of my customer projects demand use of Delphi 6 Pro. Because that's what the customer itself owns. I maintain their code so I have to use their tools. Because of this I don't justify spending (...) (18 years ago, 27-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Probably. As I was reading the thread it was *loading* the MPD file that was considered two-pass, and my algorithm is definitely only one-pass for that (and no extra fixups after reading it all). OTOH, if the file should be rendered on screen (...) (18 years ago, 27-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Don't know about that, source-wise (all my work projects are still Delphi, Win32 only). In .NET you definitely don't have to care about the language an assembly was written in, you just use it. (...) If that is your work development system, I (...) (18 years ago, 27-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) I suspect there's two definitions of "pass" at work here. I would consider a two pass algorithm to be anything requiring two loops (which we must have either way as their is no reference order specified in MPDs). Another way of considering it (...) (18 years ago, 27-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Actually I can't get my head around 'searching for a file in the cache' as equivalent to 'do a second pass of the source file'. Every part is searched for in the cache. Each source line is only read and parsed once. What am I not (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Delphi 2005 (9) is part of Borland Developer Studio (BDS) 2005. It also contains C# Builder and Delphi for .net compilers. But I mainly use Delphi for win 32 development. Since BDS 2006 C++ Builder is also included in the suite. But I decided (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Is Delphi 2005 Delphi (Pascal) only? I've got BDS2006 at work and that contains both Delphi and C++ and C#. Going .NET would make it easy (?) to use a C++ library from Delphi, I think. (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Thanks for the pointers, I'm working with Delphi 2005 Pro win32 at the moment (LD4DModeler was written in Delphi 6 Pro). So I can't use you're library. But I will certainly take a look at it. I sometimes write stuff in C++, but for a living (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
Lars C. Hassing wrote: [snip detailed explanation] Thanks for the insight of you're L3P ldraw reader routines. (...) If you mean by public, public to all children and not the whole world, this fits perfectly in Anders Isaksson vision. See my reply (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) This is actually very logical. And it fits in the description from the 2000 post pointed to by Lars. So all objects in the mpd are available for recursive children of the main part, being the first place to search. (...) I don't think stuff in (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) That is a two pass algorithm. It's optimised by only searching files that have already appeared but the search in stage II is a second pass. Tim (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) What about the following algorithm (assuming everything is cached): - whenever a file reference is read, search for the file in the cache. if not found, add it as an empty file and flag it as 'incomplete' - whenever a 'file' is seen, search (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) It seems to me that an MPD is functionally equal to a disk folder which has been added to the (beginning of the) search path for parts. No more, no less. If a part is found in the search path it is used, if it is not found it is ignored (with (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) You're right, but Jacob invented the MPD, so I guess I just followed his wish, though I would have preferred the scoping. Also he suggests a way to get scoping anyway: "0 FILE house1/house1.dat" which nicely reflects the storage on the disk. (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Wow, that's impressive. I'm pretty sure it's accidental, too. (Accidental on my part; your L3P parser was obviously there first.) (...) LDView only has one file open at a time also (unless I'm mis-remembering my implementation), since the (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) You're welcome. (...) I think local scope is the "correct" thing to do as long as local scope means that only files inside an MPD file can access other files inside the MDP file. Files stored external to the MPD shouldn't, in theory, be able (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) I actually consider that to be two-pass, and that's essentially what LDView does. The only extra thing it does is that it checks for 0 PART meta-commands in the first pass, and puts the file data for the sub-files into their own separate (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Well, if you read all postings on MPD through the last seven years you should be able to piece the correct answer together :-) I believe the L3 parser (used in L3P, L3Lab and "ldglite -l3") reflects that information. > However, I can tell (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Sorry, you're right every part in the mpd should see any of the other parts. May be Ldraw.org should post a set of 'testcase' files to be used as a reference for programmers. For each file there should be a description of the expected results (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: MPD file loading search order
|
|
(...) Is that what I said? I didn't mean to... If an MPD contains main.dat, a.dat, and b.dat, then a.dat should be able to 'see' b.dat. I make heavy use of the MPD format while working on part files. Inside a single MPD, I typically have long chains (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
|
