| |
In lugnet.cad, Adam Myers writes:
> It's starting to seem to me like the best
> way in which to condense the menu system within lcad programs while at the
> same time allowing facilitation for all current lcad elements within the
> community would be to have "skins" for the parts.
<snip>
I feel this suggestion as worded combines two different, separable ideas, both
of which merit discussion.
One would be the introduction of subcategories for decorated versions of parts
within the authoring tools.
The other is a new, more graphical way, of creating decorations.
Prior to discussing them I will point out that I feel LDraw, the standard for
modeling parts, has some limitations. We all know that. Nevertheless, changing
the standard itself is highly impractical. Too many things depend on it, and I
for one would never advocate making changes that break current programs. Even
extensions that don't change existing parts. But fortunately the community is
clever and has come up with ways around many of these things by using the 0
line (comment) type, by file nameing conventions and so forth.
Normally I don't favor overloading things like filenames with multiple
business meanings, and using comments for multiple overloaded meanings but
sometimes you gotta do what you gotta do. This is one of those times. That
said...
1. The first suggestion is one that has been bandied about before, along with
the related one of allowing parts to be categorized multiple ways. If we look
at the file names of decorated parts it is quite obvious in 99% of the cases
which the decorated parts are and what the base undecorated version is.
If we agree to stick to that convention and agree that we will violate the
principle of not giving keys (and filenames are keys in this context) business
meaning as we said we would above, it becomes easy, for any authoring tood
that wishes to, to allow decorated versions of parts to be a subtree of a
particular part. MLCad could do this quite easily if Michael wanted it to, and
i would say that it should. For decorated parts there is no need to add
descriptive keywords as we are discussing elsewhere to solve the multiple
categorization problem, because we assume that the user has already found the
base part.
SO this seems like a good thing to do to reduce clutter. I love decorated
torsos dearly and I love the number and letter bricks dearly (I used them in
my copyright on my hopper model instructions!!!) but they *are* "in the way"
in the sense that they clutter up the first part of the MLCad bricks listing,
as Adam said.
We (that is, design tool authors and the file naming standards body) ought to
adopt this one.
2. Skins, or a more graphical way of describing decorations that allows more
people to participate in creating decorated elements.
This one is harder. The LDraw standard way of describing parts (including
their decoration) is a polygon oriented scheme, not a bitmap one. That is, its
roots lie in vector graphics rather than in raster, and further, in polygons,
not solids. If we had it all to do over again I am sure we would have used a
solid modeling approach that used perfect (that is describe a cylinder by its
radius and axis, not the set of polygons that approximate its surfaces) shapes
and that let you do intersections, subtractions, etc. as that way of authoring
parts is easier in the long run. Further I am sure we would have made
allowances for texturing bitmaps onto surfaces.
But James Jessiman, bless his heart and cherish his memory, wasn't
sophisticated enough to realise that a solid modeling approach was the way to
go, because a polygonal description system makes the rendering engine job
easier (because rendering engines like to work with polygons). After all, he
was largely self taught and hadn't had the benefit of lots of MS and PhD level
courses on how to do graphics and model reality, nor have most of the rest of
us (me either, but I have friends that did and i have some experience with 2d
shape bashing in chip design software), we're all just hobbyists trying to
make do and have some fun.
So we have to live with the choices James made, with the attendent problems
like the current discussion about what the proper way to model a spherical
section is, where the polygons go and so forth.
That properly is a problem that the rendering engine should deal with (a solid
model rendering engine goes through a stage of converting perfect solids into
polygonal approximations, then a stage of clipping and backface culling the
resulting polygons, then a stage of lighting/shading, then a stage of
rasterizing...) not the parts authors.
But so be it. The parts authors DO have to worry about where the polygons go
(thankfully, it's reduced to choosing the right primitive polygonal
approximation rather than having to calculate polygons for cylinders directly).
Given that, though, it's not practical to propose that we use bitmapped
textures directly, attractive though it may seem. The file format is not
condusive to holding them and the rendering engines of most of our tools do
not have a stage in their rendering pipeline for applying texture maps. Adding
bitmap support would be highly disruptive. I think.
Decorations, like everything else, need to be described as collections of
polygons. Unfortunately. And currently, that's what parts authors, even gifted
decoration authors like Chris Dee, do. They bash polygons by hand.
Is there another way round, though, to add some automation?
I think so. It won't be easy. Manfred already described an approach that was
tried and didn't give very satisfactory results, that of taking a bitmap and
converting it to a very large collection of 1 pixel rectangles of the
appropriate color.
There is another conceivable approach. Maybe. I am neither a parts author nor
a graphics engine programmer so I could be all wet.
But suppose that we had a program to aid us, that could take a bitmap, present
it to us in a large format view, and by doing edge identification, provide a
superimposed view of the edges that were present in the image. Those edges are
the important part to us, as the edges will all need to be at least one edge
of 2 triangles... one triangle for one side and one for the other.
Huh?
Consider the simple example of a bitmap of a uniform red triangle with a black
square centered in it. For this to become a decoration, we need to model the
triangles composing the large red triangle. Many of them will have a vertex or
edge that is part of the red/black border. Similarly the black square can be
described by two triangles as well. Those two trianges each take two edges
from the black red boundary. (real LDraw files would model the square as a
quad but bear with me)
If this program that could do edge recognition/analysis and could present
edges to us, could also allow us to enter additional lines, still in this
superimposed view, and then do a flicker compare where it quickly strobe
toggled between the bitmap and the growing collection of polygons that we were
authoring to model it, we'd be able to quickly tell how we were doing.
Such a program needs to have a way to do edge analysis, and a way to collect
lines and polygons, and a way to check to see that there were no gaps or
overlaps.
It doesn't sound like TOO hard a program to write. This program as spec'ed
doesn't help with decorations on curved surfaces but they are a minority at
the moment. Further, if the decorated part of curved surface is cylindrical or
spherical, it's a minor extension to add that capability.
Decoration authors... would this program make things easier? You would start
with a scan of the decorated element and end up with the collection of
polygons that did the decorated face.
++Lar
|
|
Message has 4 Replies:
 | | Re: part skins (was Re: some thoughts on ldraw parts)
|
| (...) Whoa. Deja vu. (...) [snip] (...) I'm not seeing how this affects file-naming standards, except from the POV of not changing what we're doing. Also, do you (or anyone) have any suggestions for modifying the Partsref site to follow this (...) (24 years ago, 2-Oct-00, to lugnet.cad.dev)
| | | Re: part skins (was Re: some thoughts on ldraw parts)
|
| Larry Pieniazek skrev i meddelandet ... (...) present (...) are (...) I have the beginnings of such a program, it puts the bitmap as background, and you can draw polygons (triangles and quads) on top of that. You can zoom in/out quite a bit, and it (...) (24 years ago, 2-Oct-00, to lugnet.cad.dev)
| | | Re: part skins (was Re: some thoughts on ldraw parts)
|
| (...) Yes indeedy, and coincidentally I slung together the beginnings of such a program tonight. You feed it the outlines of the features of the printed element, along with a "color seed" inside each colored region, and it generates the triangles (...) (24 years ago, 4-Oct-00, to lugnet.cad.dev)
| | | Re: part skins (was Re: some thoughts on ldraw parts)
|
| (...) It's not always this easy. Some parts just cannot be constructed out of the primitives - or the scaling/transformation is just too difficult to figure out. Examples are those with complex curves (like the wizard's hat), or complex (...) (24 years ago, 4-Oct-00, to lugnet.cad.dev)
|
Message is in Reply To:
36 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
|
|
|
|
