 | | | | | |
Hi folks,
the LEGO Universe Team has shared another batch of part shapes with the
community, with the purpose to make them fit for the LDraw
Parts Tracker.
As usual I have uploaded them to my webspace (the upload module at LDraw.org
would have me driven crazy if I had to upload 254 files one by one). Just add
the part number to this path:
m2039
http://www.holly-wood.it/tmp/LEGODraw/m2039.dat
The path for the thumbnails would be:
http://www.holly-wood.it/tmp/LEGODraw/m2039.png
(the “M” in front has been added by the LU Team for internal reasons -
please ignore them).
Since the wiki:
http://www.ldraw.org/wiki/index.php/L%28EGO%29Draw_parts
has worked well to keep the cleanse process organized it would be best to add
also the fourth batch. The “!HISTORY date 2010-09-10” should be used.
w.
| | | | | | | | | | | | | | | |
Awesome news! Love the quantity of Bionicle parts there... (yes I’m back D:)
I’ll be sure to make the fourth chart to the Wiki. :)
-Santeri
| | | | | | | | | | | | | | | | | | | | | |
Few really new parts... but some outstanding ones (eg. 30408). And a much
improved quality, compared to previous releases!
| |
Awesome news! Love the quantity of Bionicle parts there... (yes I’m back D:)
I’ll be sure to make the fourth chart to the Wiki. :)
|
Thanks in advance, Santeri!
Philo
| | | | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
| |
... a much
improved quality, compared to previous releases!
|
HMM! I wonder how *that* happened :wink:
Thanks to you for your help with that, Philo.
-- joshua
| | | | | | | | | | | | | | | | | | | | | | | |
New parts chart done:
http://ldraw.org/wiki/index.php/L(EGO)DrawFourthBatchNewPartsChart
Note that some parts I could not find on Peeron - those parts ‘‘might’’ have
been modeled under an unknown part number. Those parts need investigating.
-Santeri
| | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Santeri Piippo wrote:
| |
New parts chart done:
http://ldraw.org/wiki/index.php/L(EGO)DrawFourthBatchNewPartsChart
Note that some parts I could not find on Peeron - those parts ‘‘might’’ have
been modeled under an unknown part number. Those parts need investigating.
-Santeri
|
Sorry, link broken due to FTX, it’s
here
| | | | | | | | | | | | | | | | | | | | | | | | | | |
Santeri Piippo wrote:
> In lugnet.cad.dev.org.ldraw, Santeri Piippo wrote:
> > New parts chart done:
> > http://ldraw.org/wiki/index.php/L(EGO)Draw_Fourth_Batch_New_Parts_Chart
> >
> > Note that some parts I could not find on Peeron - those parts ''might'' have
> > been modeled under an unknown part number. Those parts need investigating.
> >
> > -Santeri
> Sorry, link broken due to FTX, it's
> <http://ldraw.org/wiki/index.php/L(EGO)Draw_Fourth_Batch_New_Parts_Chart here>
Parts 54655 and 54809 come from a motor used for a couple of City Boat sets.
http://www.bricklink.com/catalogItem.asp?P=48064c02
| | | | | | | | | | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Santeri Piippo wrote:
| |
New parts chart done:
http://ldraw.org/wiki/index.php/L(EGO)DrawFourthBatchNewPartsChart
Note that some parts I could not find on Peeron - those parts ‘‘might’’ have
been modeled under an unknown part number. Those parts need investigating.
-Santeri
|
If you want to send me a list of the “mysteries,” I can help sort that out or
you.
-- joshua
| | | | | | | | | | | | | | | | | | |
Some interesting parts in this submission.
cu
mikeheide
| | | | | | | | | | | | | | | | | |
This is great :-)
What's the communication channel with the Lego Universe team? How do we know
when they're gonna make other parts available and when?
Looks like part m30408 is a Stormtrooper helmet. I've been waiting for this one
for ages!
I also recognise some of the other parts:
m4506 - Forest Man's hat (Peeron inventory 8683-14)
m30114 - Tribal Hunters hair (Peeron inventory 8683-1)
These new characters are part of the Lego Minifigures Series 1. My kids have now
got 9 of the 16 characters (when you buy a pack you don't know what character
you're gonna get, so the idea is that you swap them with your friends)
Bye for now
Reuben Pearse
| | | | | | | | | | | | | | | | |
In lugnet.cad, Willy Tschager wrote:
| |
Hi folks,
the LEGO Universe Team has shared another batch of part shapes with the
community, with the purpose to make them fit for the LDraw
Parts Tracker.
|
The astute parts author will notice a slightly new format to these new files. I
thought it might help to describe them.
The first line is the official LEGO Group name for the part. These are almost
always exclusively in UPPERCASE, so you’ll see them this way in the parts files.
The 2nd line involves trying to approximate a proper “0 Name:” line to save
time, based on the generated file name without the prepended M.
The third line is a courtesy to signal an unofficial part (obviously)
The fourth line flags this as a Foundry converted part, as opposed to the
traditional stl2dat tool.
All the part meshes come out “properly wound” so BFC certification has been
generated.
The source meshes organize faces into groups. Those groups were used to sort
the output lines and also color sets of faces to make conversion to primitives
easier on parts authors. Comments were used to describe the start and end of
each section.
“main” is already in color 16, and involves any parts not in the other
categories.
“stud” usually represents a male mating surface, they are colored as LDRAW color
14 (yellow). In many cases, a stud primitive should be used instead of the
group. Please note, LDRAW studs are SHORTER than official studs by an
appreciable margin, so a direct drop-in replacement was not easily done. You
may find your studs offset in the y direction at first, based on the orientation
you use (if you were to position based on the “top” of a stud mesh from the LU
file, you’ll “bury” part of the stud in the main model because of the difference
in heights). This is just something to keep an eye on.
“base” represents a female-mating surface, and in many cases needs to be
replaced with a tube or stud primitive, but also different curve portions may
apply. These appear as LDRAW color 1 (blue)
“tube” isn’t really well defined. It appears pinkish, and usually signals a
likely primitive substitution (but is also often connected to base or stud, in
the rare cases it seems to appear).
The grouping should make primitive substitution work a lot easier to accomplish.
-- joshua
| | | | | | | | | | | | | | | | |
There is one more thing to add to Joshua extensive explanations: coplanar
triangle pairs are not assembled into quads. I advocated for that, because it
offers the maximum flexibility when splitting into subparts or adjusting
vertices position (no coplanarity issues). The downside is that you should do
the triangle merging at the end of the cleanup process.
This can be done easily with Rectifier and LETGUI
Philo
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
| |
There is one more thing to add to Joshua extensive explanations: coplanar
triangle pairs are not assembled into quads. I advocated for that, because
it offers the maximum flexibility when splitting into subparts or adjusting
vertices position (no coplanarity issues). The downside is that you should do
the triangle merging at the end of the cleanup process.
This can be done easily with Rectifier and LETGUI
Philo
|
I realise this is largely off-topic to the oriinal thread but I’ve always been
curious why the use of quads is encouraged when just about every other format
and rendering engine sticks to triangles. So the part author merges triangles
into quads and then whatever software looks at the part undoes the merge.
Tim
| | | | | | | | | | | | | | | | |
> I realise this is largely off-topic to the oriinal thread but I've always
> been curious why the use of quads is encouraged when just about every other
> format and rendering engine sticks to triangles. So the part author merges
> triangles into quads and then whatever software looks at the part undoes the
> merge.
Good question!
+ reduces file size by 50%
+ 50% less vertices to adjust when building "by hand"
+ triangles plays havoc with smooth shading (the helical artefact that can be
seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png disappears when
triangles are converted to quads. But I guess it could be solved at renderer
level too.
- More complexity in many tools
- introduces coplanarity issues
Philo
| | | | | | | | | | | | | | | | |
In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
> + triangles plays havoc with smooth shading (the helical artefact that can be
> seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png disappears when
> triangles are converted to quads. But I guess it could be solved at renderer
> level too.
Note that I consider this behavior to be a bug in LDView, and as such I will fix
it when I get a chance.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Philippe Hurbain wrote:
> > + triangles plays havoc with smooth shading (the helical artefact that
> > can be seen here http://www.holly-wood.it/tmp/LEGODraw/m50986.png
> > disappears when triangles are converted to quads. But I guess it could
> > be solved at renderer level too.
>
> Note that I consider this behavior to be a bug in LDView, and as such
> I will fix it when I get a chance.
Isn't this the same problem we ran into with the twisted wedge bricks a
while back? Those gave us problematic conditional lines in addition to
the ugly zigzag shading artifacts.
http://news.lugnet.com/cad/dat/parts/?n=5654
I thought the solution was to orient the triangles orthogonal to the curve
of the surface rather than zigzag across it. You don't have to use quads,
but you end up orienting the triangles as if they were quads.
Can you really fix this in software without using a replacement part with
the triangles oriented better? I'd like to hear more about how that works,
especially if it can be adapted for my favorite low end flat shading
renderer :-)
Don
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> > Note that I consider this behavior to be a bug in LDView, and as such
> > I will fix it when I get a chance.
>
> Isn't this the same problem we ran into with the twisted wedge bricks a
> while back? Those gave us problematic conditional lines in addition to
> the ugly zigzag shading artifacts.
>
> http://news.lugnet.com/cad/dat/parts/?n=5654
No. This is a different problem. This problem is a bug in LDView's smoothing
algorithm. LDView uses Type 5 lines in the LDraw file for smoothing, and
considers any two surfaces that have a Type 5 line joining them to be part of a
smooth curve. The problem is that two co-planar triangles sitting next to each
other should also be considered to be joined together for smoothing, but they
aren't, because there is no Type 5 line between them.
Since the two triangles are co-planar, a Type 5 line between them would in fact
be an error in the part. For some shapes, the problem can be gotten rid of in
LDView by simply joining the two triangles into a quad. However, this should
not be necessary, and it only works when the flat surface only has four points.
Flat surfaces made up of more than two triangles cannot be fixed this way, and
would require Type 5 lines between all their triangles in order to be smoothed
properly by LDView.
> I thought the solution was to orient the triangles orthogonal to the curve
> of the surface rather than zigzag across it. You don't have to use quads,
> but you end up orienting the triangles as if they were quads.
The reason for the shading artifacts you showed was that the individual
triangles were in fact forming a bumpy surface, and the shading was simply
making that more obvious. Rearranging the triangles in the curve got rid of
this problem.
> Can you really fix this in software without using a replacement part with
> the triangles oriented better? I'd like to hear more about how that works,
> especially if it can be adapted for my favorite low end flat shading
> renderer :-)
Not as far as I know.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> > > Note that I consider this behavior to be a bug in LDView, and as such
> > > I will fix it when I get a chance.
> >
> > Isn't this the same problem we ran into with the twisted wedge bricks a
> > while back? Those gave us problematic conditional lines in addition to
> > the ugly zigzag shading artifacts.
> >
> > http://news.lugnet.com/cad/dat/parts/?n=5654
>
> No. This is a different problem. This problem is a bug in LDView's
> smoothing algorithm. LDView uses Type 5 lines in the LDraw file for
> smoothing, and considers any two surfaces that have a Type 5 line
> joining them to be part of a smooth curve. The problem is that two
> co-planar triangles sitting next to each other should also be
> considered to be joined together for smoothing, but they aren't,
> because there is no Type 5 line between them.
>
> Since the two triangles are co-planar, a Type 5 line between them would
> in fact be an error in the part. For some shapes, the problem can be
> gotten rid of in LDView by simply joining the two triangles into a quad.
> However, this should not be necessary, and it only works when the flat
> surface only has four points. Flat surfaces made up of more than two
> triangles cannot be fixed this way, and would require Type 5 lines
> between all their triangles in order to be smoothed properly by LDView.
I see. So what you really want to do in LDView is ignore the Type 5
lines (at least for smoothing) and smooth wherever there's no Type 2
edge lines between the triangles (and quads).
> The reason for the shading artifacts you showed was that the individual
> triangles were in fact forming a bumpy surface, and the shading was
> simply making that more obvious. Rearranging the triangles in the
> curve got rid of this problem.
Did anybody ever did actually fix the parts though? I got about
halfway through part 43721.dat before I lost focus. Meanwhile Philo
introduced the Coverer tool which may have institutionalized the
automatic generation of the problematic bumpy wedge surfaces. You can
see the ugly sawtooth shading on the wedge parts in the documentation
for the Coverer tool:
http://www.philohome.com/isecalc/coverer.htm
The problem is that the naive algorithm generates triangles where the
joins between them alternate between slightly convex and slightly
concave. I think perhaps we might need a warning for that tool to watch
out for this. Or is it possible to fix the tool to follow the convex
and concave saddle curves between the opposite corners instead? Maybe
as an option?
Anyhow I took another stab at the 43721 wedge part after re-reading
Lars' 5 year old comment about just making one octant of a twist
primitive. I used quadrants because it was easier for my feeble brain,
but I think you just scale them and you can use 8 chunks instead of 4.
http://news.lugnet.com/cad/dat/parts/?n=6571
I also didn't do any Type 5 lines yet but I think it's a bit closer
to what we really want than my previous feeble attempt.
Don
| | | | | | | | | | | | | | | | | | |
| |
|
> Did anybody ever did actually fix the parts though? I got about
> halfway through part 43721.dat before I lost focus. Meanwhile Philo
> introduced the Coverer tool which may have institutionalized the
> automatic generation of the problematic bumpy wedge surfaces. You can
> see the ugly sawtooth shading on the wedge parts in the documentation
> for the Coverer tool:
Sorry for that ;o) But (fortunately) here are very few twisted surfaces in LEGO
pieces, so I don't think my tool has created too much havoc...
>
> The problem is that the naive algorithm generates triangles where the
> joins between them alternate between slightly convex and slightly
> concave. I think perhaps we might need a warning for that tool to watch
> out for this. Or is it possible to fix the tool to follow the convex
> and concave saddle curves between the opposite corners instead? Maybe
> as an option?
Problem is that at this low level I have almost no information about the
intended geometry - I see only a bunch of connected lines.
Philo
| | | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> I see. So what you really want to do in LDView is ignore the Type 5
> lines (at least for smoothing) and smooth wherever there's no Type 2
> edge lines between the triangles (and quads).
Actually, no. That is indeed a long-term goal, but it is hampered by two
things. First of all, it's a lot of work. Secondly, the current algorithm is
actually useful to part authors, since it can visually highlight missing
conditional lines. (Of course, since the current algorithm has bugs, that
decreases its utility for this purpose.) If I implement the new smoothing
algorithm you suggest, I'll retain the current one as an optional one for part
authors to use, while making the new one the default one.
My planned fix for the bug in the current algorithm is to add dummy entries in
my "type 5 map" used for the smoothing. So, when I build the map of type 5
lines that is specifically used for smoothing and nothing else, I'll insert
entries between adjacent co-planar triangles. I believe that this should be
straightforward, but I haven't really investigated yet.
--Travis
| | | | | | | | | | | | | | | | | |
| |
|
In lugnet.cad.dev.org.ldraw, Travis Cobbs wrote:
> In lugnet.cad.dev.org.ldraw, Don Heyse wrote:
> > I see. So what you really want to do in LDView is ignore the Type
> > 5 lines (at least for smoothing) and smooth wherever there's no
> > Type 2 edge lines between the triangles (and quads).
> Actually, no. That is indeed a long-term goal, but it is hampered
> by two things. First of all, it's a lot of work. Secondly, the
> current algorithm is actually useful to part authors, since it can
> visually highlight missing conditional lines. (Of course, since the
> current algorithm has bugs, that decreases its utility for this
> purpose.) If I implement the new smoothing algorithm you suggest,
> I'll retain the current one as an optional one for part authors to
> use, while making the new one the default one.
> My planned fix for the bug in the current algorithm is to add dummy
> entries in my "type 5 map" used for the smoothing. So, when I build
> the map of type 5 lines that is specifically used for smoothing and
> nothing else, I'll insert entries between adjacent co-planar
> triangles. I believe that this should be straightforward, but I
> haven't really investigated yet.
Hmmm, it seems to me that any algorithm that can find the missing
Type 5 lines (in order to create the dummy entries) should be able
to find *all* of the Type 5 lines. Some missing lines is just a
special case of all missing. So just include them all in the dummy
list and use that for the smoothing instead of the other list. If
you want to retain the debugging features you can give each one a
tag that labels them as either real, dummy, or missing.
Then, maybe long term, you can do the lotsa extra work to switch the
Type 5 line drawing over to the dummy list as well. And at that point
maybe the standards committee can declare Type 5 lines obsolescent,
making part authoring just a wee bit easier.
Don
| | | | | | |
