Subject:
|
Re: Texture mapping spec? (was Re: Doing Patterns and Bitmaps in MLCad)
|
Newsgroups:
|
lugnet.cad.mlcad, lugnet.cad.dev
|
Date:
|
Wed, 6 Sep 2000 20:18:58 GMT
|
Viewed:
|
2821 times
|
| |
|
|
In lugnet.cad.mlcad, Travis Cobbs writes:
> "Steve Bliss" <steve.bliss@home.com> wrote in message
> news:4gvcrs8kb1v5s0ndgg18619ropc62foh9p@4ax.com...
> > In lugnet.cad.mlcad, Farlie A wrote:
> >
> > > In lugnet.cad.mlcad, Steve Bliss writes:
> > > > Urg. Why so wordy? Just do:
> > >
> > > Sorry, Computing course at college showing through. (We were told try and
> > > specify EVERYTHING. Unfotunatly there is no concrete defintion of what
> > > EVREYTHING is.)
> >
> > :) I know what you mean.
> >
> > > I am inclinded to agree with your suggestion above, but are they able to • cope
> > > with 'nested' textures such as those included by line type 1?
> >
> > Hmm. There shouldn't be any need for 'nested' textures. Or is 'nested
> > texturing' an area of texture-mapping that I don't know about?
>
> I can't think of any reason to "nest" textures. The only reasons I know of
> to draw multiple textures over one another are to produce different effects
> (such as lighting, water ripples, etc.). Since all the textures that show
> up on LEGO pieces are, by definition, static, I wouldn't think that
> multi-pass texturing would be needed.
>
> In addition, even if the DAT version of a texture contains other DAT files
> which contain sub-textures (say, to produce a repeating pattern),
This is what I meant by nested textres.- sub-textures.
> the bitmap representation at the top level would have to contain the
> composite texture
> which would automatically include any sub-textures. In this case, it would
> seem that it would usually be more reasonable to just skip the top-level
> texture declaration and just allow the sub-textures to be drawn.
You are right, I was wrong.
However a more complex texture could be built up from simpler ones.(I.E No top
level texture The sub texture being made up from simpler 'bitmaps') - This
might mean smaller files when downlading from the internet(only really an
issue for that, but the trade off is a complicated syntax in the DAT files
which is a BAD thing.( However I think this goes beyond what was actually
required...)
Just thought of some more considerations. Thresholding between texture
operation and bitmap operation needs to be considered. I.E When does the
browser decide that the *.DAT representation is better than an expand or
contracted bitmap version?
I was thinking that this should be an option inside the browser/viewer editor
rather than part of the syntax....
Alex
> --Travis Cobbs (tcobbs@san.REMOVE.rr.com)
|
|
Message is in Reply To:
24 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
