| |
In lugnet.cad, Scott Wardlaw wrote:
> > It seems to me that you put for every pixel one quad.
>
> Almost...I combine pixels of the same color that are on the same horizontal
> line. So, if pixels 1 through 5 are the same color, they become a line that
> ocupies 1 through 5.
>
> Most of my stickers have been about 1MB.
>
> I wasn't aware of the other programs when I wrote mine. I don't think that
> there is a good programmatic way to make official files.
>
> I'll try to combine the vertical lines together, where possible, so that should
> reduce file size.
>
> Look for another release tomorrow.
>
> Thanks for all of the suggestions and ideas!
> Scott
Hi Scott,
It will be better if you put adjacent horizontal pixels into a long quad
rather than a line.
The renderer POV-Ray does not support the concept of lines, so they are tossed
when L3P converts you LDraw file to a POV file.
Kevin
|
|
| |
> Hi Scott,
> It will be better if you put adjacent horizontal pixels into a long quad
> rather than a line.
>
> The renderer POV-Ray does not support the concept of lines, so they are tossed
> when L3P converts you LDraw file to a POV file.
>
> Kevin
Sorry, long quads is really what I meant by a line. So, that's exactly what the
program does.
I should have an update out later today or tomorrow that combines pixels
vertically as well.
Thanks,
Scott
|
|
| |
In lugnet.cad, Scott Wardlaw wrote:
> I should have an update out later today or tomorrow that combines pixels
> vertically as well.
Keep in mind that doing it both ways is probably a lot more difficult than just
doing it one way. For example, if you have a 1-pixel thick plus sign, you need
at least 3 quads (to avoid overlap), and your algorithm needs to deal nicely
with this. Then too, a 2x2 pixel square would be nice as a single quad, but
doing this generically is likely to be a lot of work.
--Travis
|
|
| |
In lugnet.cad, Travis Cobbs wrote:
> In lugnet.cad, Scott Wardlaw wrote:
> > I should have an update out later today or tomorrow that combines pixels
> > vertically as well.
>
> Keep in mind that doing it both ways is probably a lot more difficult than just
> doing it one way. For example, if you have a 1-pixel thick plus sign, you need
> at least 3 quads (to avoid overlap), and your algorithm needs to deal nicely
> with this. Then too, a 2x2 pixel square would be nice as a single quad, but
> doing this generically is likely to be a lot of work.
>
> --Travis
If you can work out regions of identical colour I believe there is a theory that
says you can fill it with no more than 2N (where N is the number of corners)
triangles. This is probably a good way of doing it for complex shapes.
If I ever get a chance to update my sticker creator I intend to use this
algorithm (I believe Ross uses it for txt2dat) as well as better smooth edge
finding.
Tim
|
|
| |
Sorry that it has taken me so long. In fact, I am still working on creating
quadrilaterals and triangles to fill the largest spaces possible. My main
hang-ups are:
reducing processing time
a working point-in-polygon test
I have found two different methods for testing if a point is inside a polygon,
but both have flaws (or my implimentation of them has flaws)
I did create a webpage for the sticker generator. Does anyone have a better
name for it, other than sticker generator?
The ldraw primary colors is now working, and the preview for ignoring background
colors is now more accurate.
Please checkout the website, download the program, and let me know what other
changes that I can make:
<http://www.scottwardlaw.com/sticker_generator/>
I will continue to work on the polygon problem.
Thanks again for all of your help and suggestions,
Scott
|
|
| |
In lugnet.cad, Scott Wardlaw wrote:
> I have found two different methods for testing if a point is inside a polygon,
> but both have flaws (or my implimentation of them has flaws)
There is C code for a point in polygon implementation here:
http://www.ecse.rpi.edu/Homepages/wrf/Research/Short_Notes/pnpoly.html
It's only 8 lines of code for the whole thing, but it supports arbitrary
polygons, including ones with holes. UNDERSTANDING the algorithm might take a
little work, but the page contains good documentation about the whole thing.
--Travis
|
|
| |
In lugnet.cad, Timothy Gould wrote:
> In lugnet.cad, Travis Cobbs wrote:
> > In lugnet.cad, Scott Wardlaw wrote:
> > > I should have an update out later today or tomorrow that combines pixels
> > > vertically as well.
> >
> > Keep in mind that doing it both ways is probably a lot more difficult than just
> > doing it one way. For example, if you have a 1-pixel thick plus sign, you need
> > at least 3 quads (to avoid overlap), and your algorithm needs to deal nicely
> > with this. Then too, a 2x2 pixel square would be nice as a single quad, but
> > doing this generically is likely to be a lot of work.
> >
> > --Travis
>
> If you can work out regions of identical colour I believe there is a theory that
> says you can fill it with no more than 2N (where N is the number of corners)
> triangles. This is probably a good way of doing it for complex shapes.
>
> If I ever get a chance to update my sticker creator I intend to use this
> algorithm (I believe Ross uses it for txt2dat) as well as better smooth edge
> finding.
Wow, I can't believe I only just found this thread!
txt2dat uses Jonathan Richard Shewchuk's Triangle library to triangulate
polygons generated by Truetype fonts. All you need to do is supply a list of
verteces, and it will generate the triangles to fill it. It's written in C, is
very fast, and can handle all weird types of polygons, including ones with
"holes" in them. And best of all it's free. Get it here:
http://www.cs.cmu.edu/%7Equake/triangle.html
And there's lots of great information there about the theory and how it works
too.
ROSCO
|
|
|
