 | | Re: Checking for bowtie quads?
|
|
(...) Yeah, I tried to think of a simpler way to do it myself. But all my ideas required converting the quad from 3D coords to 2D coords first so my feeble brain could handle it. :^) Don (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Checking for bowtie quads?
|
|
(...) Thanks, I've got it! I didn't know the check was that involved, though... Fredrik (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
(...) I don't know the exact files that I changed, I remember that I unziped LDLite 1.6 and added a #ifdef BMP_HIGHCOLOR, I'm sending what I have in another message. The code is not Windows specific, it was taken from the LeoCAD image routines and (...) (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: L3PLiTE?
|
|
(...) It does take some extra time to load a big file but the speed increase later is well worth it. After doing the initial calculations, you only need to check the studs for the bricks you move so it's very fast. Leonardo (25 years ago, 29-Mar-00, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: Checking for bowtie quads?
|
|
(...) Lar's L3Input.cpp is in the latest ldglite source (which is available at the usual place). It contains the bowtie checking code and is quite nice. Don (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Checking for bowtie quads?
|
|
Do anybody know of a simple algorithm for checking if a quad is of the "bowtype" kind? I.e. a quad where two of the edges cross each other. I understand that Lars C Hassing's L3P does this check, so perhaps he can help me? Thanks in advance! Fredrik (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Time for BFC overhaul?
|
|
Now that MLCad is supporting BFC, should we begin overhauling the parts database to take advantage of this? I'd be interested in working on this for a while. What is the status of the meta-command discussion? How close are we to closure? -John Van (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
(...) I didn't see it, but I didn't look really hard at the windows specific code since I'm bypassing it for something more portable. If you still have the code I could try to paste it in with the other two formats. Don (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Problem with 1-4con1.dat
|
|
Augh! How do these things get by us? I'll put this into the next update. And I promise that the 2000-01 vote is coming. Very soon. Really. Steve (...) (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: L3PLiTE?
|
|
Leonardo: (...) So in "every" part you have put a "stud-slot-point" in all the places where a stud from another part can connect with this part. So if a stud on a non-transparent part is at the stud-slot of another non-transparent part, it is (...) (25 years ago, 29-Mar-00, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
Rui: (...) You are probably right, but JPEG is defined _for_ lossy compression. It is definitely not the correct choice if you want loss-less compression. (...) Maybe, but GIF is covered by a patent (not a problem in Europe yet), and PNG generally (...) (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
Don: (...) In some, but admittedly very few, cases GIF gives a better compression than PNG. (...) PNG does anything from 1 to (at least) 64 bit/pixel, including up to (at least) 16 bit/pixel graduated transparency. Play well, Jacob ---...--- -- (...) (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
(...) A long time ago I submited a patch to make ldlite save 256 color bitmaps, was it never applied ? (...) (URL) but most Linux distributions have it too. Leonardo (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: Parts Cataloging Program
|
|
(...) From what I've seen PNG gives BETTER compression than GIF for flat shaded ldlite type images, and as far as I can tell it only does 32bpp true color. I put a sample PNG on the ldglite web page if you want to try converting to various formats (...) (25 years ago, 29-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: A discovery? and part 3475
|
|
John VanZwieten <john_vanzwieten@email.msn.com> wrote in message news:Fs5MrI.325@lugnet.com... (...) can (...) show (...) Never mind--you answered in another post. -John Van (25 years ago, 28-Mar-00, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Re: A discovery? and part 3475
|
|
John Jensen <skurt@vip.cybercity.dk> wrote in message news:18a2esk6si8dbum...4ax.com... (...) Why not just use the ring and cone primitives? Used in combinations, you can create just about any size ring or cone from these primitives, and they show (...) (25 years ago, 28-Mar-00, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Re: A discovery? and part 3475
|
|
(...) [snipped description and part-file] Yep, this is how I usually build curved stuff - use primitives to get the correct points, inline them and move the points around as necessary. In this particular case (a full circular ring), a way to avoid (...) (25 years ago, 28-Mar-00, to lugnet.cad.dev)
|
| |
| | Re: A discovery? and part 3475
|
|
(...) I've done a similar thing myself a few times to generate a cone (and similar things), and I've been thinking about making a function in LDraw-mode to make the process easier. But I failed to see how to formalize the procedure, so I suspended (...) (25 years ago, 28-Mar-00, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Re: L3PLiTE?
|
|
(...) Basically it checks if a stud primitive is close to a "inverted stud" (the cylinders under a plate for example) or to some predefined points added by me and remove them. The original idea was to make the bricks really connect when they get (...) (25 years ago, 28-Mar-00, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: A discovery? and part 3475
|
|
Perhaps that'll teach me to take a better look at the numbers... Regards John (25 years ago, 28-Mar-00, to lugnet.cad.dev)
|
