Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 4,675
» Latest member: Cjacker
» Forum threads: 5,812
» Forum posts: 49,590
Full Statistics
|
Online Users |
There are currently 366 online users. » 1 Member(s) | 362 Guest(s) Bing, Google, Yandex, Cjacker
|
|
|
Problems with Windows 8 |
Posted by: warwick holden - 2013-08-31, 18:38 - Forum: Help
- Replies (16)
|
|
Hi! I have tried searching the forums for this problem, but without success! If I've missed a post - I apologise. I tried to install L Draw All-in-One installer onto a laptop running Windows 8. The laptop is a Sony Vaio with Win 8 Professional 64 bit installed. The install went OK, but towards the end of the install there were a number of error messages along the lines of "Can't find file". At the end the final install a message said that Pov-Ray had failed to install. The main programs were installed in the 'Program (x86)' folder. Should I have installed elsewhere?? Such as direct onto the C drive?? Any help appreciated. By the way - all other programs worked fine!
|
|
|
Clips and Minifig Radio |
Posted by: Roland Melkert - 2013-08-31, 16:23 - Forum: Parts Authoring
- Replies (1)
|
|
I was playing around and noticed that the Minifig Radio parts (e.g. 3962a) don't fit onto clips (or minifig hands).
Also the 61252 clip seems to have a bfc problem.
Just reporting in hopes somebody picks this up.
|
|
|
Aligning Categories to user expectations |
Posted by: Allen Smith - 2013-08-28, 21:34 - Forum: Parts Authoring
- Replies (25)
|
|
Someone just posted the following to a local LUG mailing list I'm subscribed to (emphasis added):
Quote:Thinking about it, I can remember what derailed my learning LDraw/Mcad/ et al... it was the parts management system… [T]he hundreds of variations with a surface graphic made the whole stack completely unmanageable.
While I don't know the author, I really have to agree with the sentiment. Regular bread-and-butter categories one uses all the time for building are clogged with enormous numbers of decorated parts which are almost never used. Over the years, the single most-requested feature for Bricksmith was to add a "Favorite" category, and I can't help bust suspect this was part of the reason.
A couple years ago when I was adding !CATEGORY support to Bricksmith, I came to the conclusion the situation was actually getting worse. Notably, Duplo elements were being piled into the regular categories like "Brick". The !CATEGORY keyword was also inconsistently applied, so some bricks fell into defined categories, and some fell into implicit categories based on the first word of their description. Some logical first-word categories were being exterminated for inexplicable reasons, but only in a piecemeal fashion. Since it was all inconsistent, it was insanely difficult to find anything. I actually gave up and intentionally ignored !CATEGORY for any single-word category name.
I would like to take a cue from Bricklink here. Separate decorated elements out of the most commonly-used categories of Brick, Tile, and Slope. I think this would be a huge win for regular users.
I would also like to see !CATEGORY be dependable. When I last checked in on the situation (at least a year ago), every Categorization was potentially subject to a review squabble (and endless limbo) on the part tracker. That was the point at which I gave up on implementing the feature and went back to using the description for almost everything.
|
|
|
SubFile resolving |
Posted by: Jan Jirout - 2013-08-26, 22:49 - Forum: LDraw File Processing and Conversion
- Replies (6)
|
|
Hello,
I'm trying to write simple program that parse .dat files and build tree representation of LDraw model in memory. I have problem to read some sub file references. For example line:
Code: 1 16 290 0 230 1 0 0 0 1 0 0 0 1 stud.dat
This line is reference to file "stud.dat". Problem is that this file doesn't exists. I can't find advise how to resolve "stud.dat" to existing file name in LDraw part library. Is there any way how to resolve it?
Thanks
Jan
|
|
|
OpengGL color / material properties |
Posted by: Roland Melkert - 2013-08-25, 19:45 - Forum: Parts Authoring
- Replies (23)
|
|
Hi all,
I'm playing around with making the difference between plastic and e.g. rubber parts visible in LDCad.
I've found some nice OpenGL material references but was wondering if there is some kind of 'standard' floating around. Especially for determining the diffuse, ambient and specular components based upon the single rgb supplied in LDConfig.ldr
Up to now I'm using the rgb for both diffuse and ambient, and have a static specular of 1,1,1 and shininess of 128 (which is more appropriate for chrome I'm realizing now).
I'm doing this with the standard lighting model (not shaders) for now (LDCad runs on OpenGL as low as 1.1), so I only can play with the base four components for now.
|
|
|
Quick question regarding stud4fns's |
Posted by: Jude Parrill - 2013-08-24, 23:16 - Forum: Parts Authoring
- Replies (1)
|
|
Is there a reason why we don't include the inner-bottom (where it connects with the adjoining part) edgeline on stud4fns's? At least the part I've been using recently (stud4f4s) doesn't include this line, meaning I have to add it individually for each stud, which is a pain and clutters up larger parts which use lots of them. Was this an oversight? If I were to update and resubmit this primitive, would anybody have a problem with it?
|
|
|
LDD Brickset vs. LDraw Library and Parts Tracker |
Posted by: Rolf Osterthun - 2013-08-22, 15:16 - Forum: Parts Authoring
- Replies (26)
|
|
Hey,
there are a lot of LEGO bricks that are available in the LDD, but not in LDraw. I created a list that compares the design-ids known in the LDD Brickset 1128 with the part-numbers that are currently available in the official LDraw Parts Library (up to update 2013-01) and with the part-numbers that are currently on the Parts Tracker (Server time: 2013-08-22 10:11).
The LDD uses pure numeric design-ids but LDraw sometimes has numbers with an alphanumeric appendix. To compare these two (three) lists I used the following regular expression:
Code: ^<LDDDesignId>([a-zA-Z]+[0-1a-zA-Z]*)*$
E.g.: when I am looking for the LDD design-id 2041 this expression will match 2041, 2041a, 2041b and 2041ps3 but not 20411. If I find a match, I assume that the part exists in LDraw, too. My results can be seen on this web-page: http://www.digital-bricks.de/en/index.php?site=nil.
Since it is possible to convert LDD data to LDraw compatible data, I will gradually provide all parts that have a design-id in the LDD and no matching part-number in the LDraw Universe. Anyway, some of the provided parts might already exist in the LDraw - but I claim that they have a different part-number (we need an alias).
Please remember: These are unofficial parts. They may be incomplete, or inaccurate, and it is possible that when they are officially released one day, they may be changed in ways that could mess up any model you use them in. All these parts are redistributable under CCAL version 2.0. Anybody is welcome to use these files to prepare the parts for the LDraw Parts Tracker.
I am grateful to any kind of comments, suggestions or hints.
Rolf
|
|
|
|