Welcome, Guest |
You have to register before you can post on our site.
|
Online Users |
There are currently 251 online users. » 1 Member(s) | 247 Guest(s) Bing, Google, Yandex
|
Latest Threads |
Parts request
Forum: Part Requests
Last Post: Peter Grass
1 hour ago
» Replies: 1
» Views: 100
|
Batman Cowls
Forum: Part Requests
Last Post: Peter Grass
8 hours ago
» Replies: 1
» Views: 165
|
A fresh list of "most com...
Forum: Part Requests
Last Post: tom alphin
9 hours ago
» Replies: 7
» Views: 636
|
Transparent sticker colou...
Forum: General LDraw.org Discussion
Last Post: N. W. Perry
Yesterday, 19:12
» Replies: 1
» Views: 270
|
Fix for slightly incorrec...
Forum: Part Requests
Last Post: Huib Versteeg
Yesterday, 9:50
» Replies: 4
» Views: 820
|
Lego Town Racer 1996 - 63...
Forum: Official Models
Last Post: Chris Böhnke
2025-09-13, 23:39
» Replies: 14
» Views: 2,032
|
Eyesight on Linux
Forum: Rendering Techniques
Last Post: Orion Pobursky
2025-09-13, 18:56
» Replies: 12
» Views: 8,703
|
Another common varient: 1...
Forum: Part Requests
Last Post: Rene Rechthaler
2025-09-12, 14:51
» Replies: 8
» Views: 5,576
|
1Lx1Lx2L brick with studs...
Forum: Parts Authoring
Last Post: SNIPE
2025-09-12, 10:14
» Replies: 0
» Views: 744
|
LDraw Colors for OpenScad
Forum: LDraw Editors and Viewers
Last Post: Hageta
2025-09-12, 10:03
» Replies: 0
» Views: 674
|
|
|
BFC of mirrored parts? |
Posted by: Magnus Forsberg - 2014-12-30, 10:17 - Forum: Parts Authoring
- Replies (9)
|
 |
In the list of Non-BFC'd parts there is a lot of parts that only need a correct BFC statement.
Parts like physical coloured shortcuts or mirrored versions of a design (left/right).
Two of the Technic Panels Farings, 32189 and 32535, have been fixed, but we also need to add a BFC statement to the mirrored parts, 32188 and 32534. All that is needed is to add " 0 BFC CERTIFY CCW " to them, (and change from Part to Unofficial_Part).
Many files was caught in Rolands libfix update, and are now at the PT, but all the mirrored parts are still left behind in the official library and needs to be sent to Admin for recycling.
Is there a way to find them and/or correct them automagically?
|
|
|
Connectivity Problems |
Posted by: Ben Supnik - 2014-12-28, 21:48 - Forum: Official File Specifications/Standards
- Replies (4)
|
 |
Hi Y'all,
I've been playing with the idea of connectivity for a while now, and picked it up again after poking around Moc Builder recently. The main features I'd like to support in Bricksmith with connectivity data are:
- Easy assembling of models (by having Bricksmith know how parts want to "snap" together)
- Easy manipulation of irregular shapes (e.g. hinges at odd angles and technic assemblies) by letting Bricksmith understand how an entire sub-assembly rotates around an arbitrary hinge. (This would make irrelevant the part origin or META commands to "fix" the origin - the connectivity information would specify how a given part can rotate.)
- In an ideal world, Bricksmith would be able to figure out what the "actions" of a given model are. E.g. if you make a car and the doors open, the hood can pop up, and the trunk opens, ideally Bricksmith can, from the connectivity information, derive some kind of higher level "playability" data that describes what the model does. (This goal is much harder than the first two.)
I did some experiments with LDD and found that it goes very far in most of these directions. However, it also hits limits sometimes. For example, I downloaded an LDD build of 70165 (ultra agents HQ) and found that LDD couldn't figure out that the linear assembly of ball joints effectively form a hinge. As a result, the truck walls could not be "opened". LDD does seem to understand complex technic assemblies (at least sometimes) but sometimes moves the model all over the place trying to solve the system of multiple independent hinges.
Anyway, starting with the usual straw man of connector meta-data on parts (e.g. plugs and sockets or receptors modeled after things like stud, hole for stud, technic hole, technic axle, etc.) there are a few problems I'm not quite sure what to do about. This is sort of a brain dump of where I'm at in the design.
1. Friction: ignoring wear-and-tear on your real bricks, the friction of a given hinged connection varies by part. For example, 1x4 brick hinges tend to be very "floppy" and we can almost always assume that if they've been left hanging free, it was the intention of the modeler to make an opening door, moving part, etc. By comparison, 1x2 brick hinges are relatively stiff* and can be used to simply build at a 45 degree angle, or they can show intended motion. (See also 1x2 brick hinges used in place of a 1x2 brick with studs on side before we had SNOT bricks.)
I'm not sure how to determine what is intended "playability" and what is not. One solution is to treat everything that can move as playable, but the result would be that complex bar and clip assemblies (like the carefully modeled bogies that serious train nerds build) would be interpreted as incredibly complex moving parts, when they're really supposed to just sit there looking nice.
2. Movement limits: both MocBuilder and LDD support AABB collision testing on bricks, which helps solve the "it can't rotate any more because it bonks itself" problem. But it would still be nice to get -exact- rotation limits out of a given system. E.g. every 1x2 brick can rotate 0 to 90 degrees at most. To determine this from AABB, we'd be forced to build very complex AABB models of the hinge itself. Ideally an LDraw client would be able to determine some rotation information while punting on collision detection, or be able to operate even if the entire LDraw library wasn't correctly AABB modeled. (Realistically I think we could get partial connectivity implemented relatively quickly for a subset of parts, but having an AABB on every single part is a huge undertaking.)
3. Complex movement. A series of hinged assemblies may define a single play movement because of limits to interaction between moving parts. For example, consider a train with working steam pistons. A low level analysis of connectivity would reveal a number of sub-assemblies with relationships: a linear relationship between the piston and its housing, 1-degree rotational hinges on the various piston rod assemblies, and a one-degree rotational relationship on the axle to the axle bearings.
But the net result of all of those train parts moving is a -single- movement. For example, any given orientation of the axle relative to the train itself fully defines where all of the parts will end up, and if you drive the axle in an animation, all of the parts have to move along specific paths to keep connectivity.
I don't even know how you would begin to go from low level connectivity to complex movement, but I'd like to have a connectivity spec that does not omit any needed information to be able to someday solve this problem.
Anyway, that's the end of my brain dump - if anyone is already doing this stuff in-app, I'd be curious how the problems were solved.
thanks!
Ben
* as a kid I vaguely remember a huge range of stickiness among my hinges, and having to pick the right hinge for the job due to differences in friction.
|
|
|
Rounding bug in PrimGen2? |
Posted by: Max Martin Richter - 2014-12-28, 11:09 - Forum: Parts Author Tools
- Replies (10)
|
 |
Hej,
I think, I found a rounding problem in PrimGen2.
I'll continue to check all primitives for rounding errors, correct file ending and add a "generated with primgen" comment, when comparison is successful or the file is regenerated.
Please see these lines:
Code: 0 Cone 15 x 0.25
0 Name: 1-4con15.dat
0 Author: Max Martin Richter [MMR1988]
0 !LDRAW_ORG Unofficial_Primitive
0 !LICENSE Redistributable under CCAL version 2.0 : see CAreadme.txt
0 BFC CERTIFY CCW
4 16 15 1 0 [color=#FF0000]13.8585 1 5.7405[/color] 14.7824 0 6.1232 16 0 0
4 16 13.8585 1 5.7405 10.6065 1 10.6065 11.3136 0 11.3136 14.7824 0 6.1232
4 16 10.6065 1 10.6065 [color=#FF00CC]5.7405 1 13.8585[/color] 6.1232 0 14.7824 11.3136 0 11.3136
4 16 5.7405 1 13.8585 0 1 15 0 0 16 6.1232 0 14.7824
0 // conditional lines
5 24 15 1 0 16 0 0 15 1 -6.2132 [color=#FF0000]13.8582 1 5.7403[/color]
5 24 13.8585 1 5.7405 14.7824 0 6.1232 15 1 0 10.6066 1 10.6066
5 24 10.6065 1 10.6065 11.3136 0 11.3136 13.8582 1 5.7403 [color=#FF00CC]5.7403 1 13.8582[/color]
5 24 5.7405 1 13.8585 6.1232 0 14.7824 10.6066 1 10.6066 0 1 15
5 24 0 1 15 0 0 16 5.7403 1 13.8582 -6.2132 1 15
0 // Build by Primitive Generator 2
This problem seem to exist for cones only...
/Max
|
|
|
add a new meta 0 !ORIGIN |
Posted by: Steffen - 2014-12-27, 14:47 - Forum: Official File Specifications/Standards
- Replies (6)
|
 |
Following the discussion at
http://www.ldraw.org/cgi-bin/ptdetail.cg...s/6117.dat
on the PT, I'd like to suggest a new META for specifying a "good" origin of a file.
0 !ORIGIN x y z m1 m2 m3 m4 m5 m6 m7 m8 m9
It is just the keywords "0 !ORIGIN", followed by the usual translation and matrix data.
When not present, a default of
0 !ORIGIN 0 0 0 1 0 0 0 1 0 0 0 1
is assumed.
Adding this will allow us to adjust the "suggested" origin of parts even after they have become official,
WITHOUT breaking models that users have built with it.
Software aware of this new syntax can put its rotation center etc. to that origin when the user touches the part.
|
|
|
Need a more specific LDraw Parts Colour Definition |
Posted by: Dennes - 2014-12-26, 2:14 - Forum: Official File Specifications/Standards
- Replies (6)
|
 |
Hi LDraw community,
I’m not happy about the material and edge color specification from the LDraws Colour Definition, I have trouble to understand what is meant, I will try to explain my reasons in 2 steps.
Edge Color:
The edge color specify (how the word says) the color from the rendered lines between 2 points, and the color is (in most cases) darker then the maincolor.
But that's not correct, at first such lines called "edges" does not exist in the real world, that what we see as a dark line between 2 parts are shadows, please take a look on the following picture.
farm9.staticflickr.com/8337/8192336942_2d08eddbfb_b.jpg
(25 Dec 2014 at 23:46)
If we take a look on a single part, we see that the edges are brighter and not darker then the maincolor.
To show this you can watch the following pictures (or you go to your bricks and spectate them self, of curse).
davidglennsimmons.com/archive/images/Jack Stone car chassis.jpg
(25 Dec 2014 at 23:56)
lego.brickinstructions.com/05000/5653/003.jpg
(25 Dec 2014 at 23:57)
In both cases it will be wrong... - First case we have edge-colors which are darker then the maincolor, so it fits if we have things like brickwalls but not if we have a single brick.
- Second case we have edge-colors which are brighter then the maincolor, so it fits if we have a single brick but not if we have a brickwall.
At the time I don't have a specification for it as solution because such "edge-color" thing does only exist in wireframe mode or similar display techniques but not if we want to render it to a more realistic looking object.
The color between bricks in a brickwall consists of things like the shadow (which consists of the density of an object, reflectivity ...) from a brick, the lights and materials (shaders, roughness) of a brick, I hope you know what I mean.
Maybe it’s better to define a density/clearness/transparency and a reflectivity for a part and not only a color-value because transparent and reflecting parts exist and "edge-color" must not be defined.
Material:
I watched the Visual LDConfig table I’m fine with solid and transparent colors because it gives a hex value that defines the color and a alpha value which defines the transparency but I have ask me things like "what’s the difference between speckle and glitter", "what’s the difference between chrome and metallic" or "what’s the difference between speckle and metallic"...
I know that this means different kinds of materials (shaders and so...) but the differences are not clearly defined so I searched a picture that shows the differences of the materials (the real materials not shaders), the picture can be watched over flickr under this url:
flic.kr/p/eUKtQi
(26 Dec 2014 at 01:05)
so ok... transparent is the same surface like solid with transparency, and chrome, metallic, pearl and milky are additional kinds of surfaces, but speckle defines a pattern with a kind of surface, so it has 2 colors ok, but is it chrome, metallic or pearl ?
Glitter is the same like Transparent with Glitter in it?
And where are the differences (optical not physical) between Rubber and Milky?
If you watch the image above again and take a look at the bionicle mask under the word "Glitter" you can see that this is another kind of surface but not Glitter.
So I am confused now...
My solution or idea for that is to use a maincolor that can be overwritten by pattern which uses a second color for that, every color can be an alpha too.
Than it has to specifying which kind of pattern should be used. For now I know 2 kinds, the first is the Speckle pattern and the second is the chemical looking gradient which Lego uses for some bionicle parts, see pictures below:
media.peeron.com/pics/inv/custpics/x546.1077930325.jpg
(26 Dec 2014 at 02:39)
img3.wikia.nocookie.net/__cb20090801192607/custombionicle/images/4/4c/Blaze_Dragon.jpg
(26 Dec 2014 at 02:40)
Then it must have a surface (solid, chrome, metallic, pearl or milky) and additional it can be luminat and/or glitter.
If I am wrong, it where be nice if somebody can answer my questions and explain how that should be work.
Greetings
DMI-1407
|
|
|
Theming |
Posted by: Orion Pobursky - 2014-12-25, 2:19 - Forum: Help Wanted
- Replies (5)
|
 |
If any site design/graphic artists are out there, I'd like some ideas for a theme facelift for the forums. No coding experience is necessary, just a mock up of how things should look. However if you have the know how then code is good too.
|
|
|
Forum Icons |
Posted by: Orion Pobursky - 2014-12-25, 2:17 - Forum: Help Wanted
- Replies (10)
|
 |
Can someone with better icon making skill than me make icons for the following:
Website Admin
Parts Author
Parts Author/Reviewer
Parts Library Admin
Steering Committee Member
Standards Committee Member
LDraw.org Member
JJMA awardee
If you can think of any other icons/badges appropriate for the forums make those too. Not sure how big we should make them 16x16? 32x32?
|
|
|
|