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
|
|
|
|