Subject:
|
Re: Smoothing on part level using edge lines
|
Newsgroups:
|
lugnet.cad.dev
|
Date:
|
Tue, 6 Aug 2002 19:33:35 GMT
|
Viewed:
|
820 times
|
| |
|
|
"Travis Cobbs" <tcobbs@REMOVE.halibut.com> wrote in message
news:H0Fopv.22s@lugnet.com...
> In lugnet.cad.dev, Martijn Zwaal writes:
> > If you check out the big space dish (3961.dat) you can see the optional • line
> > algorithm fails because there are no optional lines. In my opinion this • part
> > is good. There is no need to fix this part because it will only get • larger
> > and slows down some applications. It performs it's job as it should. • This
> > is the same with the inside of the hands of the minifigs.
> > A workaround in your program could be made by letting your program • generate
> > optional lines (while preprocessing) on all edges except for edges of • color
> > 24. You might want to remove optional lines that are coincide with edge
> > lines of color 24. That way the other programs are happy and your • program
> > too. You can use the same code for smoothing but you have to do some • extra
> > preprocessing.
>
> Reading the various replies to this, I've seen a number of good points, • but
> I think that some degree of misunderstanding was also generated. I
> personally don't think optional lines are generally a good idea on the
> inside of curves, but it is true that if a part is ever transparent, then
> these are required for fully correct rendering. I don't feel I'm closely
> enough involved with the part creation process to have earned an
> opinion/vote on this issue, though.
>
> Now as for LDView, I think that Martijn's suggestion of smoothing over all
> edges that don't contain an edge line is a good one. There are some
> problems that I see that would require being a little smarter, though.
> Based on what I've seen with the optional lines, I think that rounding
> differences will occasionally cause an edge line to be missed. Adding a
> maximum angular difference between two polygons that smoothing will be
> disallowed over will help a lot.
>
> Overall, I expect that there will still be some artifacts in this • smoothing
> process, but I do agree with Martijn that there will be less artifacts • than
> with the current algorithm.
>
> As for how I would accomplish this in LDView; I can come up with • something,
> but I doubt it will involve the automatic creation of conditional lines.
> While it's true that this would allow me to use my existing smoothing
> algorithm, I still don't think it's the best way to go. In fact, based on
> the usefullness of the current smoothing code in pointing out missing
> conditional lines to part authors, I think I should leave it available as • an
> option.
>
>
> > And something else. Have you read my suggestion about rendering patterns
> > into a texture map?
>
> I did see that, and it sounds like a good idea, but it would also be • fairly
> difficult. You would have to have some way of deciding that there are
> enough co-planar patterned polygons, then create the texture map, then • apply
> it in the correct location. All of this is certainly possible, but I'm • not
> sure how difficult it would be.
>
> There also might be difficulties with the join between the pattern • polygons
> and the surrounding ones, so you would probably have to consider all the
> surrounding co-planar polygons of color 16 to also be part of the pattern.
> Given the relative scarcity of patterned parts, I'm not sure the • performance
> improvements would be enough to justify the amount of work that would be
> required.
I just thought about it because printed patterns seem to become more complex
every year. If you look at the skateboarding Pepper (6731) for example, you
can see dithered pizza printed on his torso. The speeder of Dooku is also
complexly (and sometimes randomly) printed. Perhaps it might be a good idea
to think about extensions that provide per vertex values, like per vertex
colors and texture maps, so it can be possible to display complex patterns.
This could look like this perhaps:
....
0 QUAD INDICES 2 2 4 4
4 2 1.2 1.2 etc..
or
0 TRIANGLE INDICES 3 8 9
3 8 1.5 1.4 etc.
to provide color indices per vertex that override the default index.
For texture mapping:
0 QUAD TEXTURE RGB PIZZA.PNG 0. 0. 0. 1. 1. 0. 1. 1. (Texture coordinates)
4 16 1.2 etc.
0 TRIANGLE TEXTURE RGB PIZZA.PNG 0. 0. 0. 1. 1. 0. (Texture coordinates)
3 16 1.2 etc.
0 QUAD TEXTURE BUMP TILE.PNG 0. 0. 0. 1. 1. 0. 1. 1. (Texture coordinates)
4 16 1.2 etc.
to provide texture maps or bumpmaps for roof tiles.
Perhaps it's also possible to add normals like:
0 TRIANGLE NORMALS 1. 0. 0. 1. 0. 0. 0. 1. 0.
or rgba colors:
0 TRIANGLE RGBA etc.
Martijn
|
|
Message is in Reply To:
 | | Re: Smoothing on part level using edge lines
|
| (...) Reading the various replies to this, I've seen a number of good points, but I think that some degree of misunderstanding was also generated. I personally don't think optional lines are generally a good idea on the inside of curves, but it is (...) (22 years ago, 6-Aug-02, to lugnet.cad.dev)
|
11 Messages in This Thread:
 
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
