Subject:
|
Re: part skins (was Re: some thoughts on ldraw parts)
|
Newsgroups:
|
lugnet.cad, lugnet.cad.mlcad
|
Date:
|
Fri, 29 Sep 2000 16:21:54 GMT
|
Viewed:
|
1963 times
|
| |
|
|
In lugnet.cad, Adam Myers wrote:
> okay, were going to try and post something without getting anyone angry this
> evening.
:) That sounds like a good prayer/meditation to/for me.
> Where to begin? Well first off I'll apologize to all the minifig
> torso fans out there.
I'd like to also apologize. My responses (to both Adams) were somewhat
overdone. Good thing I toned them down before posting them, eh?
> I'm just sick of defending my point in an argument over minifig torsos.
For me, it wasn't your chosen example -- any example would have gotten the
same response. It was a combination of (a) the apparent lack of
understanding of the work involved in what you were proposing and (b) the
lack of appreciation of the history/context. We are where we are for a
number of reasons.
> Anyways on to the point of my post. It's starting to seem to me like the best
> way ...
[pardon me for butting in -- 'the best way' is an overstatement. 'One good
way' works better for me.]
> ... in which to condense the menu system within lcad programs while at the
> same time allowing facilitation for all current lcad elements within the
> community would be to have "skins" for the parts. An example of the
> effectiveness of this comes when you look at the beginning of the brick menu
> in mlcad. One of the first major groupings of bricks is the alpha-numeric 1x1
> bricks. All of these are basicly the same brick but with differing designs.
> In a skin type format all of the 1x1 bricks would be represented by a blank
> 1x1 brick and instead of pulling a graphic brick from the menu you would first
> select the the blank brick and then go to modify part and select add skin.
> You would then be presented with a screen of availiable skins for the desired
> part. Admitedly this does require some advance within lcad programs.
I think this is a *great* idea for the user interface within an LCAD
editing program. Pick the basic part you want, then pick the pattern for
it. Cool. :)
But it doesn't (necessarily) have anything to do with the storage of the
data. This UI feature can be achieved without changing any part of the
current LDraw library. Which is a good thing, because the LCAD Library
must maintain complete compatibility with LDraw.
If you don't like that interface for the program you are using, you might
want to think in terms of "how can this program be enhanced", rather than
"how can we make major changes to the underlying structure". Don't use a
sledgehammer to kill mosquitoes, and all that.
> Separating the graphic on a given part has some major advantages over just
> creating parts thatstand as one unified piece.
This approach (separating patterns from parts) *would* require a big change
in the library. Although it could be implemented by a modeling program, as
a non-standard extension. Which would be good for that program, but the
results wouldn't be compatible with other programs. And would leave all
skin-authors out in the cold, because there'd be no standard source for
skins.
You are really discussing two big changes here: one is that patterns should
be represented by texture-mapping ("skinning") raster images onto the
surface of parts. That change has been discussed before, and would be high
on many people's list of features to add to the GDL.
One downside: using bitmapped images (in whatever format) for patterns
would most likely result in updates being *larger*, not smaller. For most
patterns, the DAT language representation is fairly compact. GIFs or JPGs
are likely to be much larger.
An upside: patterns which are either complex or have fine details (or both)
would improve in rendered quality. But that increase could be achieved by
other methods, which would benefit the entire rendering, not just patterns.
The second part of your idea is more obvious: instead of releasing
"patterned parts", we could release "patterns for parts". That sounds
good, but when you get down to details, it isn't much different from what
we do now.
For pieces with many different patterns, we create one file (hidden in the
parts\s\ directory) for the entire part, except for the patterned areas.
Then the patterned part files include a short reference this subfile, along
with all the code needed to describe the pattern. So there's not much
datastorage overhead for releasing "entire parts".
Also, "patterns for parts" would still need to be tied to the specific
part, with a few exceptions. There are a few patterns which are used on
many pieces, such as the Octan logo. We can currently supply these
patterns as shared files, and just reference them in the specific
> One that really sticks out in
> my mind is the ability to more easily create new parts. Skins could basicly
> be created and edited using an editor.
Somebody would have to create that editor. Unless you mean a standard
graphics editor? That could work, especially if the graphics format
supported transparent areas (otherwise, those minifig torsos are hard to
deal with).
> There are two possible problems that I can see with this format and future
> lcad programs that might include it. The first is that not all graphics are
> printed on a smooth and flat surface within LEGO pieces. An example of this
> is the 6x6 octagonal domes in aquazone sets.
Faceted surfaces are not that big of a problem -- it's just multiple flat
surfaces on a single part. There would need to be a defined mapping from
the bitmap image to the part surface, which would be unique to each part.
As most (maybe all) 'skins' would still be part specific, this definition
could be carried in the part file.
The skin-to-polygon mapping definition is a fairly standard skinning-issue,
I think. Look at all the 3D games -- they use skins pretty effectively on
complex surfaces.
Now, how about those R2D2 heads? Those are polygonal in LDraw, but a good
skin-solution would also be l3p-able to POV-Ray.
> The other problem involves the
> logistics of thousands of different skins for one single element migrating
> around the community. The best solution around this is to simply release
> approved skins as parts along with the updates in lieu of releasing a full
> part as is currently done.
Agree as to the solution, if 'skins' are the way we decide to go. This
goes around full circle to my point that we don't want to reorganize the
whole database in order to solve a user-interface issue. Especially since
that change could make the library less-useful in other UI-modes.
Steve
|
|
Message is in Reply To:
36 Messages in This Thread:
  
  
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
