 | | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) (URL) on Win2000 SP4 w. (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) My best guess is at that time MS was trying to make things safe for old programs (although it seems senseless for them to have done this with Win32 apps). If you call the Win32 function GetLongPathName on the short path, it will give you the (...) (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) That was command line, (URL) the result with drag n drop> is similar. ROSCO (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) Yeah I know they can be included but it's usually a safe idea not to. When setting a standard I'd be wary of allowing anything that is commonly poorly interpreted (which I suspect the escaped characters are). Tim (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) Thanks, Well well, first advantage of downgrading to XP, I guess. Just to be sure, you did drag and drop into the "application", or did you write it in a command line? /Tore (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) (URL) Here's> the output on XP. ROSCO (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) Well, I made a small program in Delphi 7 that lists the command line parameters, drag and dropped a file named "LongFileName.dat" in it, and here is the surprising result: (URL) (Running on a Win98SE PC.) So I think long file names still has (...) (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) The only character either Linux or Mac OS X is allergic to is '/'. Spaces are perfectly acceptable under both. One need only take care that any paths fed to the shell are properly escaped. Ideally anybody writing shell scripts or system() (...) (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) With tongue slightly in cheek, I believe it is time to accept the technological advancements of 1984. If DOS wasn't obsolete the day it was written, it definitely was within a few years. DOS filenames tend to be inscrutable, and there just (...) (17 years ago, 2-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) First of all, I agree that we should avoid using space in filenames for all official stuff. It's just too problematic. However, that's not a reason to forbid the use of long filenames in general. The thing is, any program that doesn't support (...) (17 years ago, 1-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Testing long filenames was Re: Unofficial directory (with non-standard name lenght)?
|
|
(...) And sorry to reply to myself... Could people using older operating systems test this? I'm happy to maintain the status quo if there are problems but if no-one finds problems then I think we make the majority suffer for something that isn't (...) (17 years ago, 1-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) I'm not sure about 98 and its ilk but I've never had any problems with long filenames in XP for l3p (and possible other command lines although I can't remember any off hand). I would certainly recommend against using spaces in filenames as (...) (17 years ago, 1-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) It it really so? We still use renderers and utilities that have command line inputs, and I don't know but I have a strong feeling that long names may cause problems like "Unofficial" turs into "Unoffi~1" followed by path not found errors. And (...) (17 years ago, 1-Mar-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
--snip-- (...) Personally I'm against maintaining it. It forces us into strange naming conventions for something which probably affects no users of the software. Tim (17 years ago, 28-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Unofficial directory (with non-standard name lenght)? (Was: LDView 3.1 on Mac OS X!)
|
|
(...) So far, we have maintained the old DOS convention of max. 8 chars and no SPACE used in folder names. I realize that fewer and fewer programs and utils are made in DOS evironments, maybe I'm the only to still make quick 'n' dirty programs in (...) (17 years ago, 28-Feb-07, to lugnet.cad.dev.mac, lugnet.cad.dev, FTX)
|
| |
| | Re: Fiber Optics module
|
|
Willy Tschager schrieb: (...) I own the set (URL) and I will see what I can do. cu mike (17 years ago, 14-Feb-07, to lugnet.cad.dev)
|
| |
| | Re: Fiber Optics module
|
|
(...) hmm ... posted on "Sun, 3 Dec 2000 05:40:17 GMT" ... it's never to late to reply ;-) yes, I confirm that the axle hole in 6637.dat - Electric Technic Fiber Optics Element (Official LCad update 99-01) is 2 ldu too high - beside many other (...) (17 years ago, 14-Feb-07, to lugnet.cad.dev)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) Thanks! I enjoy recording models in LDraw after I've made them because the process of methodically disassembling and reassembling them for input is very different from the casual way I initially build them. It's just sort of fun to look at a (...) (17 years ago, 9-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) Ah yes, the trusty helmet mounted flashlight look. Too much glare for me. I prefer the sort of lighting delivered by the mid-afternoon sun, beaming down from high over the left shoulder. But that's a personal preference, I suppose. (...) Nice (...) (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) My light is a directional light pointing in exactly the same direction as the camera. In LDView 3.1, you can actually override this with an undocumented command line option. I hope to have light direction (single directional light) as a new (...) (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) Yeah, your default settings tend to hide certain surface flaws. Your light source (where is it by the way?) and smooth shading are as effective as dim lighting and heavy makeup. Perhaps not the best thing for a parts designer to be using. But (...) (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) I have to wonder if I'm partially to blame. Perhaps the part author was using LDView (thumbnail is linked to bigger image, generated by LDView): (URL) Everything looks great there. --Travis (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) I'm wondering if something can't be done for general fits between two or three parabolas (perhaps I'm best to start with one parabolas and two lines). I'm trying to think of things but unfortunately geometry is my weakest branch of (...) (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) If you fix that one, perhaps you can take up the challenge of (URL) the wedge brick>. I don't think we ever solved that one properly for ldraw. Enjoy, Don (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) Hi Don, That problem has bugged me for a while but I didn't realise there was such a simple solution to it. I imagine that something similar can be done where both edges are curves by setting up shells along the double curves. Now I'm off the (...) (17 years ago, 8-Feb-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Alternate 6208 B-Wing Escort Fighter
|
|
(...) I like the ship, and especially that you've done it up in LDraw on the Mac. Cool. I'll have to leave any other comments to the starwars and building experts though. What I really like about that particular cad picture is the way it highlights (...) (17 years ago, 8-Feb-07, to lugnet.starwars, lugnet.cad.dev, FTX)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) I'm not sure if I know what you mean here. But an importer will most likely create joints for all parts in the MPD. Otherwise it will be difficult to determine which to do and which ones not. (...) I'll see what I can add to help automate some (...) (17 years ago, 28-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) Thank {you} if you implement it ;-) - I'd hate to do all that work over again. BTW if you're able to incorporate that function, it would be nice if you can merge individual submodels since more than 90% of mine are usually just angled sections (...) (17 years ago, 28-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) If everything goes well, I'll expect the first beta in a couple of months. (...) Not as far I'm concerned. An actor describes the connections between an group of parts. You can then use any actor in an 'character'. And there is no coded limit (...) (17 years ago, 27-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) This is just the kind of program I've been longing for since before I decided to MLCad all my mocs - it was actually one of the main motivations. Man, I'm looking forward to see it completed!! A couple of questions: Assuming that the bot is an (...) (17 years ago, 27-Jan-07, to lugnet.cad.dev, FTX)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) Yes, After defining one or more actors, you can use them in animations whom will be rendered real time using openGL. While animating you can manipulate all defined joints in the actors using a tracker like editor. In this tracker you put (...) (17 years ago, 26-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Finaly: I completed my new LDraw render engine
|
|
(...) Am I correct in understanding this lets you animate LDraw models in some limited way? If so, very good work getting it done so far. Does it output povray? Tim (17 years ago, 26-Jan-07, to lugnet.cad.dev)
|
| |
| | Finaly: I completed my new LDraw render engine
|
|
Just wanted to show you people that the LD4DModeler project is not dead, I'm still working on the succeeder and I'm happy to announce the first big step is done. I finished the basic 3D Engine and editors. I have put some screen dumps on my site. (...) (17 years ago, 25-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) Look fine in Mozilla 1.7.13 Roland (17 years ago, 18-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
For anyone who's interested, here is the output from a more complicated model: (URL) chose pyramid for the test because it allowed me to take a screenshot of the entire page.) Notice that it doesn't show images for any parts that aren't recognized (...) (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) <snip>> Thanks in advance. (...) Looks great on my Treo 650 with PalmOne Blazer 4.0. Although the partslist images the edges show up white reather than black ans make the parts look a bit funky... (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) quickly; all the rest are still in the queue. Thanks a lot. --Travis (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
I found this via browsing the other day, and it is very useful. It doesn't have ALL browsers, but has most and has options for version number, resolution, flash, java, etc. (URL) (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
I found this via browsing the other day, and it is very useful. It doesn't have ALL browsers, but has most and has options for version number, resolution, flash, java, etc. Aaron (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) Thanks. It looks really bad in Lynx. Apparently Lynx doesn't like div elements (at least not when they have style information attached). Lynx also doesn't know the meaning of the tfoot element, which is a little more surprising. --Travis (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) Looks fine in Opera 8.3. I'm sure I can test it on Lynx for you too ;) Tim (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: Web browser compatibility testing request
|
|
(...) The above was worded badly. I'm most interested the above browsers. However, if you use some other browser, please test it in that as well, and report the results. --Travis (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Web browser compatibility testing request
|
|
I'm adding a new feature to LDView that will generate a parts list web page for any model being viewed in LDView. The HTML code that I'm generating makes heavy use of CSS, and I don't have some browsers that users might use. While my output (...) (17 years ago, 17-Jan-07, to lugnet.cad.dev)
|
| |
| | Re: LSynth electric cable cross section oriention problem
|
|
(...) Me too! Kevin (18 years ago, 27-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LSynth electric cable cross section oriention problem
|
|
(...) Hi Kevin, Another possibility to investigate is to change the up vector in inverse proportion to the bezier curve change. That would mean it would twist less where there's a sharper bend, and would possibly end up looking more authentic. But (...) (18 years ago, 26-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LSynth electric cable cross section oriention problem
|
|
(...) Leo, In case you didn't get this far, I solved the above problem and can now control twist all through a cable segment from start point to end point. I calculate the up vector for the start of segment, and the up vector for the end of segment. (...) (18 years ago, 26-Nov-06, to lugnet.cad.dev)
|
| |
| | LDAO problem
|
|
i guess this would be the correct spot for the message. i have a install problem with LDAO. i install it, and when i stat it i get error 76 , path not found. (18 years ago, 26-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LSynth electric cable cross section oriention problem
|
|
I've got up/side/front vector stuff working now, so that I can control the orientation of cross sections of electrical cables at the start of a segment defined by two constraints. My issue now is that I don't know how to force the twist so that the (...) (18 years ago, 24-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: bend thingie creator.
|
|
(...) Let me check my archive of LDraw related programs and if I have it I'll email it to you. -Orion (18 years ago, 24-Nov-06, to lugnet.cad.dev)
|
| |
| | LSynth electric cable cross section oriention problem
|
|
Hi, I've got a reworked version of LSynth with a major problem... I cannot figure out how to control the twist of the cross section. I use bezier curve to created the nicely curved set of points, and compress it by tossing out points until the angle (...) (18 years ago, 24-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: bend thingie creator.
|
|
(...) Koen, I tried to email you using your address, and I tried to download your bendie thingy creator. It is gone. Does anyone have a copy of this so I can play with it? Kevin (18 years ago, 24-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: *** Correction: LDView Version 3.1 Released ***
|
|
(FUT lugnet.cad.dev) (...) Actually, all the string handling code for the path stuff is fine (and cross-platform to work in both Windows and *nix). After doing some investigation, I discovered that the problem is that when we do a stat on the (...) (18 years ago, 22-Nov-06, to lugnet.cad, lugnet.cad.dev)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
A sincere thanks to all of you. Your comments made me go back over (again) my export code, and I found an error. Now it works as expected. I was getting funny rotations because I mis-ordered the elements of the transformation matrix, duh. Seems (...) (18 years ago, 20-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) I agree with Tim. It looks fine to me. If there were any mirroring going on, then either the orange and red would be swapped on the unwrapped box, or the green and grey would be swapped. The picture in LDView has a rotated camera angle (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) Google uses the right handed system but indeed rotated by 90 degrees, LDraw also uses the right handed system but 180 degrees rotated. It should not matter how you show the model, the coordinates are interchangeable, but if you want to use (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
Tim Gould wrote: > It is still a right-handed system. The handedness is unchanged by rotation (in (...) So the original designer of the LDraw program just decided to use this orientation of the right handed system. if so then it starts making more (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) That looks like a correct mapping to me. Unless I'm mistaken the red and orange are on the same sides in both pictures. The unwrapped boxes are definitely identical and unless you've moved them in one or the other the whole thing is right. Tim (18 years ago, 19-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
Hi, Here's my box test model in SketchUp. (The above model is the same model unfolded.) (URL) When I export this model to a .dat and open it in LDView, the green side is the top-view, blue is the front view (as expected), and I would expect the (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) In LDraw +z is backwards, not forwards or more strictly +Z points away from the camera when X is right and -Y is up. Tim (18 years ago, 19-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) I've been having difficulty with importing/exporting .dat files from SketchUp. In SketchUp, if you stand at the Origin; X is right, Y is forward, and Z is up. The LDraw Primitives Reference ((URL)) says the LDraw axes are: X is right, Y is (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) It is still a right-handed system. The handedness is unchanged by rotation (in ldraws case 180*x from standard). Tim (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
As I understand it, LDraw has negative y in the up direction, which is neither right nor left handed, but something else entirely. I don't know that it has a name. James (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: LDraw coordinate system driving me crazy
|
|
(...) I've always understood it is: X positive is right X negative is left Y Positive is bottom Y Negative is top z Positive is back z negative is front In fact you can show this by adding a brick in MLCad and moving it around, watching how the X, Y (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | LDraw coordinate system driving me crazy
|
|
Hello all, I'm having difficulties with the ldraw coordinate system. As fas I understood it it's Right handed, just like OpenGL. So X positive is right X negative is left Y Positive is top Y Negative is bottom z Positive is front z negative is back (...) (18 years ago, 19-Nov-06, to lugnet.cad.dev)
|
| |
| | Re: Question to parts authors about BFC CERTIFY
|
|
In lugnet.cad.dev, Travis Cobbs wrote: > So, my question is this: should I remove this warning from LDView for commands > that contain options in addition to CERTIFY and CW/CCW? I definitely think that > it's appropriate to warn when multiple (...) (18 years ago, 12-Oct-06, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Question to parts authors about BFC CERTIFY [DAT]
|
|
As many parts authors are aware, LDView produces a warning if it finds more than one instance of the CERTIFY option among the BFC commands in one file. For example, the following will produce a warning on the second BFC command: 0 BFC CERTIFY CCW 1 (...) (18 years ago, 12-Oct-06, to lugnet.cad.dat.parts, lugnet.cad.dev)
|
| |
| | Re: Part 3650a
|
|
Here's a resurrection of an OLD thread... :-) I've recently begun to store all my TECHNIC sets, which range from about 1988 to present, all have been stored MISB (well, OK, they've been stored in the original box after I opened, inventoried by bag, (...) (18 years ago, 8-Oct-06, to lugnet.cad.dev)
|
| |
| | Re: Bug in LDGlite?
|
|
(...) My first guess would be the -z-6000 arg. I think this places the near clipping plane way back behind the camera. What you want to do is put it in front of the camera, as far out as you can without clipping the model, so you squeeze the space (...) (18 years ago, 5-Oct-06, to lugnet.cad.dev)
|
| |
| | Bug in LDGlite?
|
|
hi, any ideas what's wrong with this batch file: set LDGLITE_EXE="C:\Prog...ad\LDGLite 1.1.8\ldglite" for %%a in ("MOTM_*.dat","MOTM_...OTM_*.mpd" ) do %LDGLITE_EXE% %%a -fh -v10240,7680 -s2 -z-6000 -Z6000 -i1 -q -cg25,45,0 -mS%%~na1.png for %%a in (...) (18 years ago, 4-Oct-06, to lugnet.cad, lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) I found that performance went down somewhat when I copied and pre-translated all the studs too. I could be creating a memory cache penalty. Anyway it is only one matrix multiply per stud (stud is already flattened in itself), which goes onto (...) (18 years ago, 9-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
The thread seems to be splitting from the original point, It is a fact that OpenGL generally places a depth of 16 on any transforms. If an LDRAW model in MPD format was presented to OpenGL as a raw data block I suspect that OpenGL would easily hit (...) (18 years ago, 8-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) Actually on modern cards strips are always slower than optmized lists. You can always try adding degenerate triangles to stitch strips together to save the cost of multiple render calls (too bad PC cards don't support a primitive reset index). (...) (18 years ago, 8-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) Well, typically the multiplies that occur for different studs have the same rotation and scaling aspects, the only thing different is the position. So instead of repeating the multiplication on the original matrix, if the top left 3x3 values (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) Okay... 15% speedup is substantial... that means that it's better to pre-transform the subfiles when generating the operations for the current file. I won't worry about the maximum depth any more then. (...) How does a renderer know which (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) Same here for LDView. LDView always flattens part geometry, and this seems to improve performance enough to be noticed. LDView does use a display list for each part, and a nested display list for each nesting level above that (as long as you (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) MPD files don't add that many extra levels... usually only 2, isn't it? Further, the only stacking that generally needs to occur at the mpd level is modification of the modelview matrix, which opengl guarantees a minimum of 32. It's only in (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) I tested the performance of, and saw a decent gain from flattening part geometry. (Perhaps 15% in BrickDraw3D for QuickDraw3D or OpenGL.) What this means is that when a part is prepared into a drawing list, it is not a list of calls to (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) As far as building instructions go, LPub only provides for unique background color/backdrop for up to four levels. This is about as much as I've ever seen in LEGO building instructions. The renderers take care of nesting within individual part (...) (18 years ago, 7-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Maximum depth of ldraw models?
|
|
(...) Hmm. I use MPD models a lot, there can be several levels of nesting within a single .mpd file, and I have been known to refer to .mpd files from other .mpd files. I'm not sure how deep my nesting of model files goes, but I'd be a little (...) (18 years ago, 6-Sep-06, to lugnet.cad.dev)
|
| |
| | Maximum depth of ldraw models?
|
|
I notice that no maximum depth is given by the standard. How potentially non-compliant would a renderer be if it fails because parts in a model are too deeply nested (a maximum of as little as 16 on some OpenGL implementations). I notice that no (...) (18 years ago, 6-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Well, one that I have gives a warning message that says it can't handle color 24 and substitutes 16 for such lines. But I wasn't sure if that was correct behaviour. Another one that I've played with quietly accepts such lines, but appears to (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Actually, that grep doesn't return anything. '^[ \t]*1 24' does return hits from three files, though. Every single place in the library that this is used, it's used in a reference to one of the edge primitives. The edge primitives use color 24 (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) In the case of some kind of direct color, I guess the rendering program is free to do whatever it wants. The simplest action would be to default to black (either LDraw 0, or RGB #000000). I'd be interested to hear what actual rendering (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
Okay... that makes sense. But what if the contrast color for the current file's main color is just an RGB value rather than a color index? What should the subfile's contrast color be set to in that case? Thank you for your help, by the way. >> Mark (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) The contrast color within the subfile would be defined in the normal way - use the main color for the subfile, and look up the contrast color from the color table. The fact that the originating linetype 1 used color code 24 shouldn't matter by (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Right... but what should the contrast color be defined as within the subfile? The same? >> Mark (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Not exactly -- just use the current contrast color as the main color for the subfile. Whenever a subfile is rendered, it should already be looking up the local contrast color based on the local main color. Steve (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Does that mean that it would be appropriate for a renderer to just swap the main and contrast colors when it encounters such a line, or what? I just want know what a renderer is supposed to do. (...) Well, doing grep '^1 24 ' on the parts (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) It will be the constrast color for the constrast color. Which may be the same as the main color -- but it may not. Also, some viewers (like L3Lab) may balk at rendering a file which uses color 24 in a line type 1. Steve (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) OK, I was partly right. There actually is a standard defined for colour extensions, you can view it here (URL) it only applies to colours defined either in ldconfig.ldr, or in the part files or model files themselves. And it is still up to the (...) (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: What does a subpart with color=24 mean?
|
|
(...) Hi Mark, I'm pretty sure there is no standard for that, and it depends on which renderer you use. ROSCO (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | What does a subpart with color=24 mean?
|
|
How is the contrast color defined for line type 1, when color=24? >> Mark (18 years ago, 5-Sep-06, to lugnet.cad.dev)
|
| |
| | Re: Proposal for MLCad.ini Enhancements
|
|
(...) hi allen, many thx for the .ini file fixes you sent me via mail. I'll load them up asap. the rest is michael's territory as I'm only the maintainer of the data. bye, w. (18 years ago, 19-Aug-06, to lugnet.cad.dev)
|
| |
| | Proposal for MLCad.ini Enhancements
|
|
In the course of writing a minifigure generator for my Bricksmith program, I've really come to appreciate how nifty it is to have something like the MLCad.ini file to work with. I've very grateful to the people who designed and maintain it. However, (...) (18 years ago, 18-Aug-06, to lugnet.cad.dev, FTX)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) Yes, basically. It wouldn't make any sense to add the parts\s directory, because those files are segments of parts -- they aren't complete objects in any sense. They are only intended to be used by part files, which should refer to them (...) (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) <snip> (...) Is it correct to assume because of this, the 48 and s dirs must not be added to the part search directories list? Roland (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) I've decided to drop the whole option for now, so the 48 dir is only used if parts reference to it by 48/xxx.dat . Roland (18 years ago, 31-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) <snip> As might be expected, Steve's replies were correct (as far as I know, anyway ;-). (...) While it's true that this isn't all that useful, it can still be done, even though some parts reference primitives from the 48\ directory directly. (...) (18 years ago, 30-Jul-06, to lugnet.cad.dev)
|
| |
| | Re: 48 directory and non filename only line 1 part file names
|
|
(...) Not exactly. The files in the ldraw\p\48 directory are all based on a 48-faceted approximation of a circle. The regular primitives in ldraw\p are all based on 16-facets. Just because a file is in one directory does not mean a corresponding (...) (18 years ago, 30-Jul-06, to lugnet.cad.dev)
|
| |
| | 48 directory and non filename only line 1 part file names
|
|
Hello all, Still working on the LDraw loader. The 48 directory in ldraw\p, as far I understand it, is a 'alternative' source for primitives, not? Jet I see some (unofficial) files using type 1 lines with the 48\ attached to the part name reference (...) (18 years ago, 29-Jul-06, to lugnet.cad.dev)
|
