To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cad.devOpen lugnet.cad.dev in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / Development / 5111
5110  |  5112
Subject: 
Re: Doing Patterns and Bitmaps in MLCad
Newsgroups: 
lugnet.cad.mlcad, lugnet.cad.dev
Date: 
Wed, 6 Sep 2000 01:50:43 GMT
Viewed: 
86 times
  
"Steve Bliss" <steve.bliss@home.com> wrote in message
news:oekarsonpfetb7spg7euh2gejm77ib7fmj@4ax.com...
In lugnet.cad.mlcad, Farlie A wrote:

OK,Revised Suggestion. (Still needs Further Disscussion)

[snip]

Urg.  Why so wordy?  Just do:

0 TEXTURE <position vector> <orientation matrix> <filename.type> [START
<standard ldraw commands go here>
0 TEXTURE END]

The <position vector> and <orientation matrix> parameters are identical to
the parameters on the standard subfile command (linetype 1).

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.

The only way I can think of to use a position vector and orientation would
be to assume that all textures are 1x1 squares (or some other arbitrary
size) and force them to come up with an orientation matrix that produces the
desired shape.  This seems like the wrong way to go to me.  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.  In other words, the line would look like:

0 TEXTURE <color> <corner1 vector> <corner2 vector> <corner3 vector>
<corner4 vector> <filename> [START]

Note that if we made START required, it would be more appropriate
immediately following the word TEXTURE.

The entire START ... 0 TEXTURE END segment is optional.  If someone is
making a custom file, they don't have to include any more code than is
necessary.

In a different post, Travis wrote:

This actually wouldn't be necessary.  Just put the DAT file which • represents
the texture in between the TEXTURE START and TEXTURE END comments, and it
accomplishes the same thing without any compatibility issues.

That would work, but would require the use of a subfile for the pattern.
Which isn't the end of the world.

0 TEXTURE <filename.type> [START]
1 16 <position vector> <orientation matrix> <filename.dat>
0 TEXTURE END

Why?  Just replace the linetype 1 line above with any number of linetype 4
lines (or any other line types, for that matter).  As long as there is some
way to tell when you have reached the end of a texture (ie, with the 0
TEXTURE END line), any number of lines can make up the dat representation of
the .  Granted, if they skip the START, the entire texture would have to be
included in the next single line as a subfile statement.


An advantage of this approach is that existing tools (such as LDAO) can
still be used to edit (rotate, scale, inline) this 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?  Also, the way you have listed above assumes that
<position vector> <orientation matrix> are appropriate for specifying a
texture, which I feel is not the case.


BTW, none of this stuff will ever make it into the LDraw/LCAD parts
library, in the library's current form.  At some point in the future, I
hope we advance enough to require a new library, with parts that are no
longer compatible with the old LDraw/DAT standard.  But we aren't there
yet.

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.

--Travis Cobbs (tcobbs@san.REMOVE.rr.com)



Message has 1 Reply:
  Re: Doing Patterns and Bitmaps in MLCad
 
(...) You are right. My approach assumed to much and restricted too much. (...) Good point. (...) OK. (...) 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 (...) (24 years ago, 6-Sep-00, to lugnet.cad.mlcad, lugnet.cad.dev)

Message is in Reply To:
  Re: Doing Patterns and Bitmaps in MLCad
 
(...) [snip] Urg. Why so wordy? Just do: 0 TEXTURE <position vector> <orientation matrix> <filename.type> [START <standard ldraw commands go here> 0 TEXTURE END] The <position vector> and <orientation matrix> parameters are identical to the (...) (24 years ago, 5-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

This Message and its Replies on One Page:
Nested:  All | Brief | Compact | Dots
Linear:  All | Brief | Compact
    

Custom Search

©2005 LUGNET. All rights reserved. - hosted by steinbruch.info GbR