To LUGNET HomepageTo LUGNET News HomepageTo LUGNET Guide Homepage
 Help on Searching
 
Post new message to lugnet.cadOpen lugnet.cad in your NNTP NewsreaderTo LUGNET News Traffic PageSign In (Members)
 CAD / 9917
9916  |  9918
Special: 
[DAT] (requires LDraw-compatible viewer)
Subject: 
Re: Crazy, OK Heretical Idea ...
Newsgroups: 
lugnet.cad
Date: 
Fri, 2 May 2003 14:32:52 GMT
Viewed: 
970 times
  
In lugnet.cad, Leonardo Zide writes:
In lugnet.cad, Steve Bliss writes:
Defining the material would be one side of the issue.  We (ie, the LSC)
could adopt/adapt the LDLite COLOR statement to handle materials.

Create a 0 MATERIAL extension instead, where you can define the properties
of the surface (smooth, bump, rubber, etc.) and keep the color selection
using the standard LDraw way so we don't break compatibility.

I like this.  It would allow you to define a bunch of materials up
front and then apply them to some of the surfaces.  Could we use this
for printed textures as well, or would that be better with a different
meta-command?

How would you apply the material?  I still like this way:

0 Put the standard materials in P\MATERIAL.DAT
0 MATERIAL DEFINE bumpy ......
0 MATERIAL DEFINE smooth ......
0 MATERIAL DEFINE rubber ......
0 MATERIAL DEFINE metal ......
0 MATERIAL DEFINE cloth ......
0 MATERIAL DEFINE pearlescent ......
0 MATERIAL DEFINE studLogoBumpMap ?????
0 MATERIAL DEFINE printed ?????


1 0 0 0 0 1 0 0 0 1 0 0 0 1 material.dat
0 MATERIAL BEGIN bumpy
0
0 ordinary ldraw commands to draw a sloped face.
0
0 MATERIAL END bumpy

Are printed textures a property of a MATERIAL, or should they be done
with a separate but similar set of meta-commands?  It seems to me that
some material properties may need an orientation, and some (like
specular effects) do not.

My question is really on the technical side: I'm somewhat aware of the
technique of texture-mapping, but I don't know if that can be achieved
in renderers like LDLite (without major changes to the rendering
engine).

This is a case by case issue, each program would need different changes to
support it.

If we implement it via meta-command hints then they can add the support
(or not) whenever they get around to it.

If that's possible, would it be possible to implement some kind of
gray-scale 'pearlescent' texture-mask, that could be combined different
color values to achieve a rendered surface?  There are a number of
different pearlescent 'colors' already, it'd be nice to have a single,
flexible, open-ended technical solution that could address them all.

I don't know what you mean by pearlescent, could you link a picture?

I'm not sure that 'textures' themselves are required, but then
again, Textures may be a better way to do printing and stickers
on bricks so....

That's possibly true.  But 'better' might not be the right word.  It
would definitely be easier and faster to produce patterned part files by
scaning printed bricks, making raster files, and apply those rasters to
brick surfaces.  But the vector files we create now generally give more
pleasing results at different scales.

Just make the textures with a good enough resolution and you won't get
many artifacts. The vector graphics we use also don't look good in all cases
and have z fighting problems if the authors are not careful.

If we surround the vector graphics with 0 MATERIAL BEGIN/END pairs then
it can be up to the renderer which bits to use, vector or texture.  This
technique seems to work reasonably well on the parts with specially encoded
L3P/POV bits.  Also the renderer could use the 0 MATERIAL BEGIN/END pair
as a hint to render the vector graphic representation of the printed bits
to an internal texture at whatever resolution it likes.  This only needs
to be done once when the file is read, and should eliminate any z-fighting
issues with the printed bits.

Don



Message has 2 Replies:
  Re: Crazy, OK Heretical Idea ...
 
(...) I was thinking we would have a pre-defined set of materials, so we don't need to define them. (...) That's what I had in mind. (...) You need texture coordinates to be able to apply textures but you don't need them for smooth, rubber and (...) (22 years ago, 2-May-03, to lugnet.cad)
  Re: Crazy, OK Heretical Idea ...  [DAT]
 
(...) Yes, I think it would be good to not encode the materials in the rendering programs. There are always going to be new materials, just like LEGO keeps coming up with new colors. (...) That would work for some things, like bumpy surfaces on (...) (22 years ago, 10-May-03, to lugnet.cad)

Message is in Reply To:
  Re: Crazy, OK Heretical Idea ...
 
(...) Create a 0 MATERIAL extension instead, where you can define the properties of the surface (smooth, bump, rubber, etc.) and keep the color selection using the standard LDraw way so we don't break compatibility. (...) This is a case by case (...) (22 years ago, 1-May-03, to lugnet.cad)

41 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