| |
In lugnet.cad.dev, Travis Cobbs wrote:
> I tend to agree about putting it all in 2 separate commands. However, I
> don't think a position vector and orientation matrix are appropriate. A
> texture is conceptually much closer to a quad than a sub-file.
> Consequently, I feel it should have the same basic format as a quad, ie 4
> points (with a filename tagged onto the end, of course). I don't feel a
> position vector followed by an orientation are appropriate, since it doesn't
> tell us how big to make it, or what shape.
You are right. My approach assumed to much and restricted too much.
> In addition,
> Farlie (I think it was Farlie) mentioned that the back side should be drawn
> in gray for transparent pieces, and it might be more appropriate to specify
> an actual color to use here.
Good point.
> In other words, the line would look like:
>
> 0 TEXTURE <color> <corner1 vector> <corner2 vector> <corner3 vector>
> <corner4 vector> <filename> [START]
OK.
> Note that if we made START required, it would be more appropriate
> immediately following the word TEXTURE.
Right. But if START is required, then it might as well be omitted. My
purpose in having an optional START was to allow TEXTUREs without the
backup of conventional DAT code.
> > Is there any reason that both syntaxes couldn't be supported?
>
> If we're going to come up with a way for "smart" viewers to display texture
> maps in place of portions of a dat file, we should come up with a single
> way, shouldn't we?
Not if the two formats are accomplishing different purposes. But I don't
think they really are. Especially now that I've seen the light about the
needed parameters.
> > The main reason that this won't make it to the library is *not* the
> > meta-commands. It is because we'd have to carry the extra image files in
> > the library. The current (unwritten) spec does not allow non-DAT files to
> > exist in either the ldraw\p\ or ldraw\parts\ subdirectory trees.
>
> It might make more sense to allow parts using the meta-commands to be used,
> but keep the actual binary images separate and optional. It might even be a
> good idea to have a "TEXTURES" subdirectory, which any texture-enabled
> viewers would check for textures, in the same way that ALL viewers currently
> check the PARTS and P directories for dat files.
That would work, but it's a complication that I don't even want to start
messing with.
Another issue is possible copyright infringement on decorative patterns
(this isn't an issue with texture-textures, like the matte surface of slope
bricks). I'm not a lawyer, but my view is this: with complete DAT-ized
patterns, the author has put in sufficient effort that the result is a
"derivative work" rather than a simple duplication. I assume that many
texture-files would be scans from real LEGO elements. These files would be
simple duplications. Practically speaking, it would *probably* not be a
big deal, but I'd rather be overly cautious.
Steve
|
|
Message is in Reply To:
 | | Re: Doing Patterns and Bitmaps in MLCad
|
| "Steve Bliss" <steve.bliss@home.com> wrote in message news:oekarsonpfetb7s...4ax.com... (...) I tend to agree about putting it all in 2 separate commands. However, I don't think a position vector and orientation matrix are appropriate. A texture is (...) (24 years ago, 6-Sep-00, to lugnet.cad.mlcad, lugnet.cad.dev)
|
24 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
