 | | Re: announcing TrackDraw (BrickFest preview)
|
|
(...) There is nothing wrong with using .NET, and most of the "crap" you refer to is already present in Windows XP. I've developed many .NET programs and they all work well and my clients are all happy with the way .NET works on their systems. (...) (21 years ago, 7-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: announcing TrackDraw (BrickFest preview)
|
|
(...) Why you did it in MICRO$OFT .NET now if we want to use your program we need to install 30mb of crap .NET anyway your program is the 1st ine to use it I haven't seen any yet apart from MICRO$OFT LONGHORN a.k.a next windows in 2005 (21 years ago, 7-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: announcing TrackDraw (BrickFest preview)
|
|
(...) I noticed you're using .Net So it might actually work on Linux boxes since the Framework is also available for Linux. See: (URL) for more info about a .Net framework implementation. -Frank (21 years ago, 7-Aug-03, to lugnet.cad.dev, lugnet.off-topic.geek)
|
| |
| | Re: Orange in LDraw
|
|
Another solution is to leave things alone, but change the applications palette to suit the user's taste. Color is tricky. (21 years ago, 7-Aug-03, to lugnet.cad.dev)
|
| |
| | announcing TrackDraw (BrickFest preview)
|
|
I've been working on TrackDraw, a replacement for Track Designer, for six months or so. I'll talk about it at BrickFest on Saturday. You can read a little about it, and see the BrickFest PowerPoint slides here: (URL) not ready to release the program (...) (21 years ago, 6-Aug-03, to lugnet.trains, lugnet.events.brickfest, lugnet.cad.dev) !
|
| |
| | Re: Star Wars mini models 1st wave render & Orange in part
|
|
(...) Maybe a light source is really close, but the blue seems rather bright. I'll have to try it myself. There's not an official LDraw color for Dark Blue yet, is there? I checked (URL) (...) 484 looks like the right orange to me, based on your (...) (21 years ago, 6-Aug-03, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: Star Wars mini models 1st wave render & Orange in part
|
|
(...) It is dark blue. In fact that's the darkest I can get it wiht LDraw color number since I used dithered Black and Blue. (...) Unfortunately no (...) I used 484. 25 seemed too dark. -Orion (21 years ago, 6-Aug-03, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: Star Wars mini models 1st wave render & Orange in part
|
|
(...) Looks nice, esp. the AT-ST. Colors seem wrong on the Slave I (I think the blue should be dark blue). Missing the TIE Bomber, though. Are the cylinders for the TIE Bomber up yet? Question related to another topic: what color orange did you use (...) (21 years ago, 6-Aug-03, to lugnet.cad.ray, lugnet.cad.dev)
|
| |
| | Re: Orange in LDraw
|
|
(...) I personally prefer 484 over both 25 & 462, although this may be an optical trick (brain sees a progression, and logically picks the middle color as the correct color). But 462 is defintely too yellowish. John P.S. I FTXed Orion's message. (21 years ago, 6-Aug-03, to lugnet.cad.dev, FTX)
|
| |
| | Orange in LDraw
|
|
I did a color comparison of the color orange in LDraw: (URL) brick on the left is the current LDraw color 462 The brick in the middle is color 484, the dither of Yellow and Red (the dither of Red and Yellow, 334, is currently defined as Gold Chrome) (...) (21 years ago, 6-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: LEdit Command line question [DAT]
|
|
(...) The only way to do this with LEdit is to create your own part file, consisting of one line: 1 16 0 -24 20 1 0 0 0 1 0 0 0 1 3001.dat If you store that file in your ldraw\parts directory, you can use it in LEdit as a part, in place of 3001.dat. (...) (21 years ago, 6-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: Command line commands in dat parts
|
|
(...) But for the less commonly used tools ... it does nothing. At this time, CMDLINE is really just a comment. Maybe someday, some renderer/editor will make use of it, but not yet. Steve (21 years ago, 6-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: LEdit Command line question
|
|
(...) Most of the meta commands are used outside of the original LEdit program. ROTATION CENTER is currently only used in MLCad (I make use of it frequently). If you're not able to use MLCad (I don't see why not), then I suggest making a custom part (...) (21 years ago, 4-Aug-03, to lugnet.cad.dev)
|
| |
| | LEdit Command line question
|
|
My ignorance of meta-commands is very nearly complete, so I throw myself on the mercy of my peers here in lugnet.cad.dev Is there a way to "set" the rotation point of a part that will work in LEdit? For example, if I'd like the 2x4 brick 3001.dat to (...) (21 years ago, 4-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: Command line commands in dat parts
|
|
(...) I forgot to add that this link: (URL) my draft LDraw spec and it contains a list of all the known META commands and links to the website for the programs that use them -Orion (21 years ago, 4-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: Command line commands in dat parts
|
|
(...) It's a LDLite META Command. Supposedly the command gives a default color for the part though I've never really seen it in action. For the most commonly used tools (MLCad, LeoCAD, L3P) this command does nothing. -Orion (21 years ago, 4-Aug-03, to lugnet.cad.dev)
|
| |
| | Command line commands in dat parts
|
|
Can someone tell me what a "CMDLINE -C0" means? And if there is a website that explains what the other commands are and how they are used. Thank you, Paul (21 years ago, 4-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
(...) Well this problem my be out of our hands. We've been using SynEdit for our editing component and since this code is not written by us, fixing problems with it is difficult. (...) When code ocmponent that we used for the editor was swapped the (...) (21 years ago, 3-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
(...) [SNIP] (...) I’d like to move the triple 3, say, into position 1 or another line. I click and select the 3 numbers + spaceholders. once the triple is selected in 1.4 the cursor becomes an "arrow" and you can drag’n’drop the selection into the (...) (21 years ago, 3-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
(...) I don't know what he is using, but I do know that enabling and disabling menu animations can produce completely unexpected side-effects. Assuming your Windows version is recent enough to support menu animations, you might want to switch them (...) (21 years ago, 3-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) That's right, Don. Please see (URL) continued: (...) Yes, it will. Tony said: (...) Good initiative! If the file gets too big or unhandy for POV, I will reconsider the L3PARTS mentioned in (URL) (21 years ago, 3-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
(...) I'm not sure what you mean by Drag 'N Drop. Could you elaborate more? (...) Again, I not sure what you mean. (...) Hmm... I have a look at it. I pretty much just ported the code from L3Check to Delphi. (...) I'll put this on the todo list. (...) (21 years ago, 2-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
(...) hi, thx for making a great tool even better. I really like the winding button and the fakt that now you can select multiple lines and rewind them in one go! working with the old plug-in was a lot of clicking and mouse-hoovering (nontheless thx (...) (21 years ago, 2-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: * LDrawDesignPad LDDP 1.5 Beta released *
|
|
To all those who downloaded and got an '.dll not found' error after install, I've uploaded the fix to this problem. -Orion (21 years ago, 2-Aug-03, to lugnet.cad.dev)
|
| |
| | Re: Inline POV code in official parts?
|
|
This is just my opinion since I started all this by suggesting to Lars to add POV support into L3P in the first place. By adding a few .dat primitives (not POV primitives) to the .dat definition, then you don't have to tie yourself to any renderer. (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) Now that would rock. For my personal use, this would almost entirely solve the problem. I could whip up a single file that contains all the parts I want to fix, run it through L3P, manually fix the parts in the resulting file, and then include (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) I asked Lars a while back if he could wrap all the part definitions with IF NDEF statements so that someone could define the parts they wanted in an external include file and the rest would use the standard L3P code. Hopefully when a new (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) Because parts with inline POV code work with the version of L3P that we have now. Why not start by building a library of modified official parts, but with the explicit goal of eventually converting them into POV only parts when L3P or some (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest? [DAT]
|
|
(...) Here is my $0.01.... This is how I have started handling Ldraw/PoV parts: The 3626bp6f.dat is availabe on the parts tracker here: (URL) is some line wrapping happening here, I will need to fix it later) 0 Minifig Head with Female Eyes with Red (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Inline POV code in official parts?
|
|
(...) I agree with Steve on this issue: no POV code in offical parts with the possible exception of primitves. I feel this way for a few reasons: - It could be construed the POV is the Official rendering program of the LDraw.org library. This can (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) Why not just a library of POV code only parts, ala LGEO/Raves, only compatible with the LDraw.org library? We could host this project on Sourceforge so anyone who was interested could develop. I think if we do it Pov only, LDraw.org is more (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Repository of .dat files with inline POV-Ray code... any interest?
|
|
(...) Okay... then I'd like to open this up to a question for the community: Is anyone interested in working on a single shared repository of ldraw-compatible parts with inlined POV-Ray code? How many authors out there are comfortable with both (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Inline POV code in official parts?
|
|
(...) Yes, it's pretty much still the case. I would really prefer to not have any POV code in the parts library at all. But if there must be some, I think it should stay in the primitive files. (...) I think a better solution is to work on POV (...) (21 years ago, 29-Jul-03, to lugnet.cad.dev)
|
| |
| | Inline POV code in official parts?
|
|
What's the current plan for POV-Ray code in official parts? I have been out of the loop for a while, but my last understanding was that parts with inline POV-Ray code don't have any chance of getting certified on the parts tracker. Is this still the (...) (21 years ago, 28-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Primitive substituion and part reviews
|
|
(...) They should not warrant a Hold review. Put comments in the review, and if you think the issue is serious enough, go for a NoVote review. (...) If the pattern allows, it would be good to add a color-matched ring primitive around the outside of (...) (21 years ago, 28-Jul-03, to lugnet.cad.dev)
|
| |
| | Primitive substituion and part reviews
|
|
To what extent, if any, should rendering errors caused by primitive substitution warrent a Hold vote on the PT? An example of this would be a disc shaped pattern surrounded by a ndis. Would it be appropritate to add a small, color matching ring (...) (21 years ago, 27-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: LDGLite outputting gobble-dee-goo to terminal window
|
|
(...) So you're saying that if I ask for the GL_RENDERER etc strings after a window resize I'll get the same ones I started with no matter what? (I added some code to check it anyway just in case) That really sux. Who designed that feature, (...) (21 years ago, 25-Jul-03, to lugnet.cad.dev.mac, lugnet.cad.dev)
|
| |
| | Re: LDGLite outputting gobble-dee-goo to terminal window
|
|
(...) OK, I looked at the code above, and all it seems to do is tell its OpenGL context to update every time the window is resized. If their glut doesn't do this, then it is broken. As far as I know, there isn't any equivalent to this in Windows. (...) (21 years ago, 25-Jul-03, to lugnet.cad.dev.mac, lugnet.cad.dev)
|
| |
| | Re: LDGLite outputting gobble-dee-goo to terminal window
|
|
(...) Found some more info. This makes it even more clear. (URL) it only shows icky Cocoa code. I may have to examine the apple glut sources to see how much of this is actually handled in glut. I wouldn't be suprised to find some bugs there. And I (...) (21 years ago, 25-Jul-03, to lugnet.cad.dev.mac, lugnet.cad.dev)
|
| |
| | Re: LDGLite outputting gobble-dee-goo to terminal window
|
|
(...) The OS is selecting the drivers. If I want to select them myself I have to write all sorts of icky OS specific code. (...) It gets worse. I did some searching on this. Apparently, according to the source on this page, I may need to check if my (...) (21 years ago, 25-Jul-03, to lugnet.cad.dev.mac, lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here* [DAT]
|
|
(...) Yes. No. ;-) There's still a problem with mirrored sub-assemblies. Suppose you have an aeroplane, Plane.ldr: 1 2 0 0 0 0 0 1 0 1 0 -1 0 0 2445.DAT 1 16 0 -8 0 1 0 0 0 1 0 0 0 1 Wing.ldr 1 16 0 -8 0 -1 0 0 0 1 0 0 0 1 Wing.ldr Wing.ldr: 1 4 -80 (...) (21 years ago, 19-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Vertices not coplanar?
|
|
(...) Right, it is typically an error if the four points of a quad do not lie in a plane. Too bad that the LDraw format has a built-in possiblity of creating degenerate quads. POV e.g. uses 2D points to describe a polygon. See also "Method for (...) (21 years ago, 18-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Vertices not coplanar?
|
|
(...) What Orion said. (...) Sometimes, it just means the vertices are incorrect. If the vertices are correct, then you should break the quads into two triangles, and put a soft edge (linetype 5) along the common edge. But often, it's worth looking (...) (21 years ago, 18-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Vertices not coplanar?
|
|
(...) When a renderer goes to render a quad in 3D, it will almost always (perhaps always) first split the quad into two triangles. As long as the quad forms a planar surface, this will result in fairly equivalent results no matter which of the two (...) (21 years ago, 18-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Vertices not coplanar?
|
|
(...) If I remember my 3D theory correctly, these quads can mess up the normals associated with them. Also, noncoplaner quads cause small gaps in the part since they are, in essence, bent rectangles. Usually these gaps are too small to see, even (...) (21 years ago, 17-Jul-03, to lugnet.cad.dev)
|
| |
| | Vertices not coplanar?
|
|
What troubles do these warnings cause? I see no problems with the renderings, no matter what renderer I use. How do I correct them? By splitting all the quads into two triangles each I guess? If so, why not make a tool that splits them up? /Tore (21 years ago, 17-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here*
|
|
(...) Thanks for the info. After further consideration, I realized that there is one other thing that will prevent the -lgeo option from working properly, even for models that don't have mirrored sub-assemblies. Any parts in the part library that (...) (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: List of part numbers with descriptions???
|
|
(...) Ow!!! (just smacked self in head) Thanks! James (21 years ago, 11-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: List of part numbers with descriptions???
|
|
(...) How about using the peeron master list? (URL) VW (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: List of part numbers with descriptions???
|
|
(...) You can use the parts.lst file in your LDRAW directory. All it is is a master list of all the part numbers/names in the PARTS folder sorted by number or description depending on how you ran MKLIST. --Orion (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | List of part numbers with descriptions???
|
|
I'm still working on my back-burner program to make labels for storage drawers. Does anyone know of a (simple, Windows-based) way to get a list of the parts descriptions? Getting a list of all LDRAW part numbers is no sweat (dir *.dat /b ><filename> (...) (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here*
|
|
(...) Two reasons I can think of: 1) Inventories: If you build a submodel using a Left Wing, and then mirror it, the inventory is going to show 2 left wings, when in reality there is 1 left wing and 1 right wing. 2) Instructions: Official LEGO (...) (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here*
|
|
(...) That's good to hear. (...) Yeah. I was aware of that. The good news is that it should only be a problem in LGEO if you have mirrored sub-assemblies. Looking at the models I have downloaded over time, I discovered that most people don't do this (...) (21 years ago, 11-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here*
|
|
(...) I have tested your program against half a dozen files (including files with large mirrored sub-assemblies for wings and such) and the L3P generated renderings all showed the studs correctly. Well done. However, it doesn't work with -lgeo... (...) (21 years ago, 10-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Some secrets of MLCad revealed ...
|
|
(...) Yes, that makes sense. Hey, I did a little searching and found some references to "depth sprites" which seem to be supported in some of the latest graphics hardware. I haven't read it yet, but the pictures in this article seem to indicate that (...) (21 years ago, 9-Jul-03, to lugnet.cad.mlcad, lugnet.cad.dev)
|
| |
| | Re: Proposed solution *Test Here*
|
|
OK, I have created a command line program to un-mirror studs. It is called UnMirrorStuds, and version 0.1 is available from the following location: (URL) download it and give it a try, and let me know what you think. I'd like to have people process (...) (21 years ago, 9-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) After bit of searching during lunch hour for Delphi DLL memory corruption problems, I think I may have found it. This page: (URL) using _fpreset() to fixup the floating point state on return from Delphi DLLs and it seems to work. Must've been (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: A Plea from a greenhorn (Re: WOULD YOU PLEASE...)
|
|
(...) I'm willing to accept this. I also like a reviewer technique (BrickCaster) of taking screen captures of the errors and posting them to the web. The pictures are actually more beneficial than dat code in learning how to screen for errors. I'd (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) Feel free to Email anything to me. I'm a LDDP developer and I just recently got Delphi 7 -Orion (21 years ago, 8-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) I'm not into sourceforge and I have no time to dig myself into it, but I can send my source to someone who is willing to try it in delphi 6. Niels (21 years ago, 8-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) Yeah, that's all I had to go on. I had the most trouble getting the exported function name decorations to match. Never did that before. Since all your DLLs seem to have the same symtom would you mind contributing the source for one (or more (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) For ldglite I've been emulating LEDIT, so that means the same position as the previous part, but unrotated. This works pretty well when you're building in LEDIT mode because it's right where you're working and it's easy to move it to someplace (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) What would the position and matrix be? I see two possibilities: Same position amd mtrix as previous part 0,0,0 and Indentity Matrix Of course we could add the ability for the user to choose between the two or input desired default position or (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: A Plea from a greenhorn (Re: WOULD YOU PLEASE...)
|
|
(...) Ok, after this thread and some off Lugnet discussion, I've come to a firm opinion. I will refrain from ANY part modfications on non Official Library parts and then subsequent posting on the PT. I will modify parts and Email them to the authors (...) (21 years ago, 8-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: Another LDDP plugin question.
|
|
I am using Delphi 3, which is (besides Delphi 1) the only version I've got. I haven't experienced writing DLLs before the LDDP plugins. The only info I had was the sample included with LDDP. Niels (21 years ago, 8-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) Ok I fixed the problem in the ldlist plugin and replaced the zip file. Turns out I had to use the WINAPI convention and add an alias to the .def file to make LDDP happy. I wonder if it's a similar calling convention problem with the track and (...) (21 years ago, 7-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) I think he might have mentioned an older version of Delphi. Anyhow, I suspect it may be an issue with Delphi vs gcc. I got my ldlist wrapper plugin working in ldglite, but it doesn't work in LDDP. I added some debugging and saw LDDP call (...) (21 years ago, 7-Jul-03, to lugnet.cad.dev)
|
| |
| | A Plea from a greenhorn (Re: WOULD YOU PLEASE...)
|
|
(...) I agree, it is a little frustrating. I'm still a fledgeling author, and I need to learn what I'm doing wrong. Having somebody come through and make these edits before I get a chance to look is not making me a better author. I need to be able (...) (21 years ago, 7-Jul-03, to lugnet.cad.dev, FTX)
|
| |
| | Re: Another LDDP plugin question.
|
|
(...) I have no idea what the problem could be unless Niel used an older version of the plugin code. This shouldn't be an issue with Delphi. --Orion P.S. All the current developers at the LDDP project are using Delphi 6 or higher. As far as what (...) (21 years ago, 7-Jul-03, to lugnet.cad.dev)
|
| |
| | Another LDDP plugin question.
|
|
I'm not sure what the problem is, but I'm running into memory problems with some of the LDDP plugins. I wonder if it's some sort of incompatibility with a particular version of Delphi used to build the plugins. Orion's plugins don't exhibit the (...) (21 years ago, 7-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: WOULD YOU PLEASE...
|
|
(...) I agree that it affects every line in the part but my point is the triviality of the moving the part. If the origin is 1 LDU off of what it should be, it's fairly trivial to move it. -Orion (21 years ago, 7-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: WOULD YOU PLEASE...
|
|
[crossposted to lugnet.cad.dev, with followup-to set there as well -- this thread isn't about posting LDR files to lugnet] (...) If anyone is not sure about the general rule/protocol/guidelines on this: for new parts (not fixes), you should *always* (...) (21 years ago, 6-Jul-03, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | LDDP plugin API suggestion.
|
|
(...) It looks like ldlist gets the LDRAW path from the LDRAWDIR environment variable, and this made me think about the LDDP plugin API. Doesn't it make sense to pass the LDRAW path to the plugin via an argument to the ProcessText() fn? This way the (...) (21 years ago, 5-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: PARTS.LST searching. (Was: Re: Part Fix 3959 Space Gun)
|
|
(...) Heh, I already borrowed the idea of narrowing the search as you type from ldlist. I also already added drag and drop support from ldlist. But I need a better screen shot to show that in action. (URL) now that I think about it, I should (...) (21 years ago, 4-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: PARTS.LST searching. (Was: Re: Part Fix 3959 Space Gun)
|
|
(...) LDList makes a partlist of it's own, and saves the keywords too. You can search for a part by AND-ing separate words, or exact quote. (URL) (Both .exe and Delphi source) You're free to use any ideas you can get from it. -- Anders Isaksson, (...) (21 years ago, 4-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution for mirrored parts and studs
|
|
(...) I'll look into that. I thought it would be easier to reference the other file, but thinking about it again, I guess I should be able to multiply the mirror matrix by the stud matrix to get the correct final matrix anyway. (Or would that be (...) (21 years ago, 4-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Proposed solution for mirrored parts and studs
|
|
(...) As you write below you can open ANY file. If no studs are mirrored, then no action takes place. (...) In stead of referencing studmirr.dat, why not simply use a mirrored reference to stud.dat? (...) No, same code. (...) Right. (...) If all (...) (21 years ago, 4-Jul-03, to lugnet.cad.dev)
|
| |
| | Proposed solution for mirrored parts and studs
|
|
It's obvious that there is a lot of interest in the problem of mirrored studs, based on the volume of traffic in the ongoing thread. I have a proposed solution to the problem. My proposal is the creation of a small tool that automatically fixes a (...) (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: PARTS.LST searching. (Was: Re: Part Fix 3959 Space Gun)
|
|
(...) Actually, I looked a bit further in the mklist.c code and it will READ up to 200 chars of part description, but then it truncates down to 64 chars before writing the part file. Apparently this is to be compatible with the old MAKELIST.EXE and (...) (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Ouch--painful use of Dave! Oh, well. I knew my solution wasn't perfect, but it solved the immediate problem (while admittedly creating others). I'll still probably use it in my blasphemous clone.dats, if it's all the same to you folks. (...) (...) (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Yes. But I'm not as willing as you are to see files changed, I guess (...) I think mirrored is more of a concern than misrotated, but that's just me. Would this meta work though? In other words, are there any parts that have studs *with logos* (...) (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: PARTS.LST searching. (Was: Re: Part Fix 3959 Space Gun)
|
|
In lugnet.cad.dat.parts, Don Heyse wrote: <snip> (...) The PT currently limits you to, I think, 64 characters in the part name. I don't know wht this limit is imposed. I just test LEDIT with a long name and it didn't care. --Orion (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | PARTS.LST searching. (Was: Re: Part Fix 3959 Space Gun)
|
|
(...) Right now it seems to be listed on the parts tracker as "Bar 1.5L with Handle and Female Stud". I just added a PARTS.LST search capability to ldglite: (URL) there's nothing in that name that would help me narrow the search to find the part. (...) (21 years ago, 3-Jul-03, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) A fair point, but how often would that happen, realistically? Enough to be a problem? Even if one or two parts eventually turn up like that, why would the whole system have to be jettisoned for those few exceptions? (...) I'm not sure that (...) (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Thanks to all the parts developers
|
|
(...) I want to join to the thanks... As I have done a few (easy) parts, I know how tedious it can be... And thanks to the hawk-eyed part reviewers, who help to keep standards high ! Philo www.philohome.com (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Thanks to all the parts developers
|
|
(...) I would like to do so as well. It sounds like a lot of work. -Mike (21 years ago, 3-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Thanks to all the parts developers
|
|
(...) Of course I join to part authors praising. Part authors can't be praised enough, especially as new parts quality is so much high. And of course we want Willy Tschager's space parts to be certified and released as soon as possible. Damien (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) After thinking about it for a while, I totally agree. If anyone wants to make perfect rendering with stud logos lined up correctly (how often does this occur?), I assume this person must have the knowledge to inline that part locally at (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Correct. There's no way to know if they actually face the right direction, so I just figured that horizontal mirroring was more likely to be correct than vertical (although I could be wrong). (...) You can, but my code that decides which (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Actually that does help a bit. It looks like you aren't concerned with whether the logo faces the same direction as on the actual part, you're just ensuring that it's readable. That makes me feel better about my solution. By the way, why do (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Thanks to all the parts developers
|
|
(...) thx to you kevin for makin' pov-rendering a piece of cake. toying around with all this cryptic pov-code was never easier. w. (waiting to see his space parts certified, especially the crater plate - reviewers please!) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) I don't actually do any transformations in LDView to get the logos right. I just detect the mirroring (by tracking negative determinants and flipping the mirrored bit every time I see one) and modify my texture coordinates to un-mirror (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Yeah, I did a search for determinant and found your note. I tried the on-the-fly fix in ldglite with the L3 structs and it seems to work, although I'm not sure I'm applying the fix correctly. Is it really as simple as multiplying some matrix (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) We definitely don't want to do this. It's unnecessary, because the sign of the determinant in the matrix specifying the sub-part tells you whether the sub-part is mirrored. The above might allow the program to do less math, but that's not an (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Yes. That's what LDView does. --Travis Cobbs (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Umm, my math is really rusty. Can the sign of the determinant also be used to detect mirroring? That could be handy. Don (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Thanks to all the parts developers
|
|
I just wanted to say thanks to Steve, Chris and all else that are involved with the developent, review and approval of the parts in the parts library. Programs can come and go, but without the parts library we'd have nothing. I think that the parts (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) Wait a minute. Doesn't L3Input.cpp build a threaded tree structure before outputting a single POV part? I would think you could traverse the array Parts[0...nParts] and look for toplevel parts from the PARTS directory. Then for each toplevel (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) My view is that there is nothing _serious_ wrong, but that a fix should be welcome. Anyway. Since we are only talking about studs, the rendering programs _could_ simply remember to fix any mirrored studs (can be done by multiplying the (...) (21 years ago, 1-Jul-03, to lugnet.cad.dev)
|
| |
| | Re: Mirrored parts and studs
|
|
(...) My only concern about letting the rendering programs do this is "how they know which way to orientate the logo". Coding this within the .dat file (either with a correctly orientated stud.dat or with metadata) is preferable to storing this (...) (21 years ago, 2-Jul-03, to lugnet.cad.dev)
|
