 | | Re: LEGO's Internal colour palette
|
|
(...) Yeah the full list is much huger. This is just the ones available at present but it gives an idea of eg. the best colours to focus on for renders and potentially other forms of restriction. Tim (15 years ago, 29-Jan-10, to lugnet.cad)
|
| |
| | Re: LEGO's Internal colour palette
|
|
Thanks for the heads up Tim. Looks like that is a list of the colors that are currently in production; as it is almost 100 colors short of the complete historical list. Also, they seem to match closest to the colors found in the instruction manuals (...) (15 years ago, 29-Jan-10, to lugnet.cad)
|
| |
| | LEGO's Internal colour palette
|
|
Hi guys, Not sure if this is really that interesting but I figured I should give a heads up to .cad. TLG have released their internal colour pallette (URL) Good luck finding something to do with it ;) Tim (15 years ago, 28-Jan-10, to lugnet.cad, FTX)
|
| |
| | Re: Instead of ~Moved to
|
|
In lugnet.cad, Allen Smith wrote: <SNIP> (...) Depending on their viewpoint and experience with LDraw, different users might argue that either inclusion OR exlclusion can be confusing. By including both in the library and providing a way to identify (...) (15 years ago, 25-Jan-10, to lugnet.cad, FTX)
|
| |
| | Re: Problem when rendering custom colors
|
|
(...) I tried to add my custom colors to the lg_color.inc file. It works now This is how my lg_color.inc looks: ___...___ // 0 #declare lg_black = texture { pigment { rgb <33/255, 33/255, 33/255> } finish { lg_solid_finish } } // 1 #declare lg_blue (...) (15 years ago, 23-Jan-10, to lugnet.cad)
|
| |
| | Re: Problem when rendering custom colors
|
|
(...) It looks to me like a texture issue rather than the color itself. I would recommend adding your color directly to the lg_color.inc file. Copy the definition for the existing blue and change nothing but the RGB color values for the pigment. (...) (15 years ago, 22-Jan-10, to lugnet.cad, FTX)
|
| |
| | Re: Problem when rendering custom colors
|
|
(...) SNIP (...) I am not very familar with POV-Ray. But could it be that the color 162 is not completely described or that is uses the slope surface here? The problem occur only at that place at the object where the light direct reflect. So I (...) (15 years ago, 22-Jan-10, to lugnet.cad)
|
| |
| | Re: Problem when rendering custom colors [DAT]
|
|
(...) Hello Eric, to further explain my problem Ive rendered a scene. (URL) left part of the fig uses the normal blue (color 1). Teh right part uses my personal color 162 (a darker blue) As you can see, the color 2 part of the torso front looks (...) (15 years ago, 22-Jan-10, to lugnet.cad)
|
| |
| | Re: Problem when rendering custom colors
|
|
(...) It's pretty hard to say what is happening without seeing your files. I need to see the portions of the POV-Ray file which define colors, or the include files which show colors. You could also post an example *.ldr file. Eric Albrecht (15 years ago, 22-Jan-10, to lugnet.cad)
|
| |
| | Problem when rendering custom colors
|
|
Hello, Im new to LUGNET. Although I use LDRAW yet for some years, I recently got interested ib creating and using custom parts (especially minifig torsos). I've created some easy to use template so I can create custom minifig torsos via bmp2ldraw32. (...) (15 years ago, 22-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
In lugnet.cad, Chris Dee wrote: snip (...) The zip archive's chief virtue is not its familiarity, but its cross-platform portability. It's very important to maintain that. (...) I fixed that Bricksmith bug about a year and a half ago, so you don't (...) (15 years ago, 22-Jan-10, to lugnet.cad, FTX)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) I think there is some part of your equation that we don't realize/understand? I can view all my LDRAW models without any updating, thanks to the "moved to" concept. The models doesn't become obsolete even though the part numbers are updated. (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) I was going to start my response with "I don't understand", but Orion beat me to it. It is absolutely not necessary to update existing models with the replacement file referred to by the "~Moved to" file, but maybe I am missing something about (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) You should take heart from the fact that this phenomenon has slowed a GREAT deal in recent times, the number of possible renumbers is way way down, and number accuracy is way up. TLG doesn't tend to switch from solid to hollow studs anymore, (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) Hmmm, subparts are used by many parts so I can see how they might be referenced a gazillion times by an extremely large model file like Datsville. (...) What tool makes the movedto.log file that's giving you such trouble? Can it be adjusted to (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) I don't understand what you're saying here, Tore. The ~Moved To files prevent the need to update already existing files by providing a back reference to the old part number. This prevents a part from disappearing from a model simply because (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) Yes, I know my suggested approach has its obvious downsides. But the current system really makes me Yike!, too. When do we reach the point where the downsides of the current system overturn the advantages? I think we've already passed that (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) <snip> (...) (the "fake" number 111 sticks around, and the official design number 2222 points to it) Yikes! So you want everyone stuck with 111 for all eternity? With the current system, I'm free to remove 111.dat if I don't want it, and end (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) <SNIP> (...) The problem is that it doesn't. As I pointed out in my latest post, (URL) , almost every single existing LDraw model file ever made needs to be updated with every parts update realeasd. That has absolutely nothing to do with true (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
| |
| | Re: Instead of ~Moved to
|
|
(...) For some reason, those 18 "moved to" files in parts\s make a lot of noise for me. I know they shouldn't but they do and I haven't figured out the reason yet. There is another problem. It is kind of subtile, so I don't know if I'm able to (...) (15 years ago, 20-Jan-10, to lugnet.cad)
|
