Welcome, Guest |
You have to register before you can post on our site.
|
Forum Statistics |
» Members: 5,146
» Latest member: math
» Forum threads: 6,075
» Forum posts: 51,205
Full Statistics
|
Latest Threads |
Hi-res logo primitives
Forum: Official File Specifications/Standards
Last Post: Magnus Forsberg
34 minutes ago
» Replies: 10
» Views: 363
|
Colour Request: 15 Lemon ...
Forum: Official File Specifications/Standards
Last Post: Willy Tschager
2 hours ago
» Replies: 8
» Views: 259
|
LDraw.org 2025-06 Parts U...
Forum: LDraw.org Announcements
Last Post: Orion Pobursky
Yesterday, 15:38
» Replies: 4
» Views: 575
|
Part 5561, Door 1 x 4 x 1...
Forum: Part Requests
Last Post: Zach M
Yesterday, 14:48
» Replies: 0
» Views: 80
|
Updates of the Bricklink ...
Forum: Parts Authoring
Last Post: Manfred Schaefer
2025-07-06, 19:28
» Replies: 6
» Views: 565
|
Modulex parts
Forum: Parts Authoring
Last Post: Chris Böhnke
2025-07-06, 18:29
» Replies: 24
» Views: 3,159
|
Minifigure Head 3626pb307...
Forum: Part Requests
Last Post: Knud Ahrnell Albrechtsen
2025-07-06, 16:41
» Replies: 3
» Views: 303
|
Minifigure Head 3626pb181...
Forum: Part Requests
Last Post: Knud Ahrnell Albrechtsen
2025-07-06, 16:34
» Replies: 2
» Views: 261
|
500 Server error
Forum: Website Suggestions/Requests/Discussion
Last Post: Lisa Winter
2025-07-05, 7:11
» Replies: 5
» Views: 275
|
23763 axl torso
Forum: Parts Authoring
Last Post: Jeff Jones
2025-07-04, 13:48
» Replies: 14
» Views: 5,492
|
|
|
Points on a circle primitive |
Posted by: Tim Gould - 2012-01-08, 21:51 - Forum: Parts Author Tools
- Replies (3)
|
 |
Hi all,
Below is a perl script to take a bunch of angles and convert them to points on the edge of a circle primitve (ie. a 16 or 48 point polygon). The comments up top describe how to use it. It's designed to make generating rims on the bottom of curved parts relatively easy when there's only a few segments required and hand-coding makes more sense than using Philo's wonderful toys.
Tim
Code: #! /usr/bin/perl
# ang2point.pl [-r RAD] [-t THICK] [-s SEGS] ang1 ang2 ... angn
#
# RAD defaults to 20
# THICK defaults to none
# SEGS defaults to 16
#
# Projects the angles onto a circular primitive of radius RAD
# with SEGS segments. If THICK is specified it also shows the
# points on an inner radius of RAD-THICK
#
# It scales the radius at each angle to ensure it lies on the
# SEG-sided polygon that approximates the circle.
#
use POSIX;
$rad=20;
$segs=16;
@angs=();
$thick=0;
for ($ia=0; $ia<=$#ARGV; $ia++) {
$opt=lc($ARGV[$ia]);
if ($opt eq '-r') {
$ia++;
$rad=$ARGV[$ia];
} elsif ($opt eq '-t') {
$ia++;
$thick=$ARGV[$ia];
} elsif ($opt eq '-s') {
$ia++;
$segs=$ARGV[$ia];
} else {
push @angs, $opt;
}
}
$nang=$#angs+1;
print "0 // ang2point.pl ".join(' ', @ARGV)."\n";
print "0 // Calculating $nang points at outer radius $rad on $segs segments\n";
if ($thick>0) {
$radp=$rad-$thick;
print "0 // Also calculating inner radius $radp\n";
}
@reffs=();
@rieffs=();
$kk=3.141592635/180;
foreach $ang (@angs) {
$f=$ang/360;
$a0=floor($f*$segs)/$segs*360;
$ar=$ang-$a0;
#print "$a0 + $ar\n";
$c0=cos($kk*$a0);
$s0=sin($kk*$a0);
$cf=cos($kk*($a0+360/$segs));
$sf=sin($kk*($a0+360/$segs));
$ct=cos($kk*$ang);
$st=sin($kk*$ang);
$scale=($c0*$sf-$s0*$cf)/(($sf-$s0)*$ct-($cf-$c0)*$st);
$reff=$scale*$rad;
$rieff=$scale*($rad-$thick);
#print "Effective radius $reff\n";
push @reffs, $reff;
push @rieffs, $rieff;
}
@pts=();
@ipts=();
foreach $ia (0..$#angs) {
$x=$reffs[$ia]*cos($kk*$angs[$ia]);
$z=$reffs[$ia]*sin($kk*$angs[$ia]);
push @pts, sprintf("0 // Point %2d: %.3f 0 %.3f\n",
$ia+1, $x, $z);
if ($thick>0) {
$x=$rieffs[$ia]*cos($kk*$angs[$ia]);
$z=$rieffs[$ia]*sin($kk*$angs[$ia]);
push @ipts, sprintf("0 // Inner point %2d: %.3f 0 %.3f\n",
$ia+1, $x, $z);
}
}
print @pts;
print @ipts;
|
|
|
Road baseplates |
Posted by: Michael Horvath - 2012-01-08, 3:56 - Forum: Parts Authoring
- Replies (2)
|
 |
Currently, when you change the color of a road baseplate, the road surface changes color as well as the studded area. This is incorrect IMO, and the road surface should remain gray no matter what the color of the studded area.
My 2 cents.
|
|
|
Parts Tracker certification marks |
Posted by: Philippe Hurbain - 2012-01-07, 13:17 - Forum: Website Suggestions/Requests/Discussion
- Replies (1)
|
 |
Hi all,
Presently, the certification status of parts that have subparts is very blurry: there is only one yellow color tag. I think that this lack of visibility greately reduce review rate... Would it be possible to have a more detailed view, depending of status of subparts (and subsubparts and so on...)? eg. - Yellow: at least one subpart in the tree needs more certification vote
- Orange: at least one subpart in the tree has a hold vote
- Light blue: all subparts in the tree have at least two cert votes
- Blue: all subparts are certified
- Bright Green: part has at least two cert votes, all subparts in the tree have at least two cert votes.
- Green: part and all subparts are certified.
|
|
|
Patterns and color 16 |
Posted by: Travis Cobbs - 2012-01-07, 2:20 - Forum: Standards Board
- Replies (11)
|
 |
I think the topic Chris raised about using color 16 in patterns where it makes the pattern useless for any other brick colors than the original one has had enough feedback from the general populous that we should now decide if the spec should be updated.
My personal opinion is that in cases like the fire logo, where it's clear that a specific color is required, that color should be used in the pattern file. And in cases like the gauge where it's ambiguous, color 16 should be used. Perhaps disagreements over whether or not something is ambiguous could be resolved by the part admin.
Thoughts, everyone else?
|
|
|
Interpreting the Views counter |
Posted by: Chris Dee - 2012-01-06, 12:06 - Forum: Website Suggestions/Requests/Discussion
- Replies (5)
|
 |
In forum pages like this, what does the Views count represent? Unique users or a cumulative count including repeat views by the same user? Is the count for a higher-level message incremented if you open the whole thread from the last message?
I'd prefer the former to get a feel for how many members are interested in a particular topic, even if they don't respond.
|
|
|
Modelling patterns that depend on the underlying part colour |
Posted by: Chris Dee - 2012-01-05, 7:21 - Forum: Parts Authoring
- Replies (18)
|
 |
An issue has arisen on the Parts Tracker that I think deserves wider discussion than is possible there.
By convention, we only model the printed colours of patterns and use colour 16 for any unprinted areas. This allows the base part colour to "show through" when rendered. Although this is exactly what would happen if LEGO were to print the pattern on another colour of part, there is an argument that in some cases we are restricting the usability of the LDraw library by doing this.
The Fire Logo Pattern has caused most concern. By leaving the unprinted left-hand flame as colour 16, the LDraw part files that use this can only really be used in red. The second example is the Slope Brick 45 2 x 2 with Gauge Pattern, which is normally printed on black and uses the base part colour to create some of the detail. The potential benefit is shown in this rendering by Magnus Forsberg - left image = "desired" rendering on green; centre image = actual pattern on black"; right image = actual pattern on green.
I can see that the case is clear for the Fire Logo - the left flame was always intended to be red. For other patterns, including the Gauge Pattern, we would need to guess about the intent of the pattern designer. That guesswork makes it very difficult to apply any consistency, and potentially generates more controversy than the current discussion, as the implementation will depend on each person's interpretation of the design intent. The benefit of the current solution is that it is totally unambiguous, but I fear we are applying rules for their own sake and denying rendering opportunities to the users of the LDraw parts library.
For now I have certified these patterns and their parent parts as they now fit with the current convention. However, I would welcome further discussion, opinions and potential solutions.
|
|
|
Login retention on Firefox |
Posted by: Travis Cobbs - 2012-01-04, 17:25 - Forum: Website Suggestions/Requests/Discussion
- Replies (3)
|
 |
The forum won't keep me logged in from one session to another on Firefox. It keeps me logged in on both IE and Chrome, but not Firefox. Is anyone else having the same problem? I'm guessing it's something with the configuration of one of my Firefox add-ons (like Adblock Plus or NoScript), but before I spend significant time and effort tracking down the problem, I'd like to verify that other people using Firefox are able to stay logged into the forum from one session to the next. (I already deleted all cookies that matched ldraw as a search string.)
|
|
|
To hold or not to hold - preferably not |
Posted by: Tim Gould - 2012-01-03, 7:41 - Forum: Parts Authoring
- Replies (2)
|
 |
Having recently stuck my nose in the PT again after a long hiatus I've come, partially, to remember certain things about it that concern me a little. Most notably I've spotted examples of what I consider to be incorrect 'hold's on the PT.
From the PT Reviewew FAQ a 'hold' is for "It's getting there, but not yet. There are errors to be corrected before the part can be released. The author has to take care of the errors." Obviously there is some leeway in deciding what is wrong or right, but I've seen more than a few 'hold's that I think were simply imposing of the reviewers views on an iffy issue.
I'm writing this mostly to ask reviewers to give more consideration to whether a 'hold' is really appropriate or if a 'novote' might not be better. Especially if what you are demanding is in a grey area of standards. This isn't to criticise the reviewers or reviews, especially as there are times when I agree with the point but disagree with the 'hold'. Sometimes it's easy to be distracted by semantics and pedantism when you are so deep in something[1].
Remember the goal of the Parts Tracker is to produce releasable parts of high standard for LDraw. Not never released parts of a never-to-be-achieved perfect systemic standard.
Tim
[1] This is coming from a man who will spend days getting all the formatting to look just right in computational physics code while neglecting to do the coding for the intended job. I'm no innocent!
|
|
|
|