|
 | | Re: 2006 LSC: Call for Nominations
|
| (...) Considering that the election is in July (which I believe is a fairly common month for summer holidays) I don't find the terms that long. And only five days to vote doesn't seem very democratic to me. I try my best to read news on a daily (...) (18 years ago, 20-Jul-06, to lugnet.cad.dev.org.ldraw)
| |
|  
ldraw
(score: 0.712)
|
|
| | Re: MPD file loading search order
|
| (...) Sorry, you're right every part in the mpd should see any of the other parts. May be Ldraw.org should post a set of 'testcase' files to be used as a reference for programmers. For each file there should be a description of the expected results (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
| |
|
ldraw
(score: 0.712)
|
|
| |
|
ldraw
(score: 0.711)
|
|
| | Re: 2006 LSC: Election Results
|
| (...) archives? (Are there list archives?) I remember that the list archives of some LDraw-based mailing list were public and contained the email addresses of the people sending messages to the list. That's a sure recipe for lots of spam. --Travis (18 years ago, 26-Jul-06, to lugnet.cad.dev.org.ldraw)
| |
|
ldraw
(score: 0.711)
|
|
| | Re: MPD file loading search order
|
| Thanks Tim and Steve, I think I will go with Steve's advise to let only the main part in the mpd see the other parts in the mpd. This will give a much cleaner recursive approach, in which I can easily support sub mpd's. Further more I think I will (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev)
| |
|
ldraw
(score: 0.711)
|
|
| | Re: MPD file loading search order
|
| As you have pointed out, the spec is indeed ambiguous. Consequently, there's probably no correct answer as to how things should work. However, I can tell you what I do in LDView, so that you have an idea of how at least one MPD-compatible program (...) (18 years ago, 25-Jul-06, to lugnet.cad.dev, FTX)
| |
|
ldraw
(score: 0.711)
|
|
| | Re: MPD file loading search order
|
| (...) You're welcome. (...) I think local scope is the "correct" thing to do as long as local scope means that only files inside an MPD file can access other files inside the MDP file. Files stored external to the MPD shouldn't, in theory, be able (...) (18 years ago, 26-Jul-06, to lugnet.cad.dev)
| |
|
ldraw
(score: 0.711)
|
|
| |
|
ldraw
(score: 0.710)
|
|
| | 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)
| |
|
ldraw
(score: 0.709)
|
|
| | 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)
| |
|
ldraw
(score: 0.709)
|
|
| | 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)
| |
|
ldraw
(score: 0.709)
|
|
| | 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)
| |
|
ldraw
(score: 0.709)
|
|
| |
|
ldraw
(score: 0.709)
|
|
| | 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)
| |
|
ldraw
(score: 0.709)
|
|
| | 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)
| |
|
ldraw
(score: 0.708)
|
|
| | 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)
| |
|
ldraw
(score: 0.708)
|
|
| | 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)
| |
|
ldraw
(score: 0.708)
|
|
| |
|
ldraw
(score: 0.708)
|
|
| | 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)
| |
|
ldraw
(score: 0.708)
|
|
| | 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)
| |
|
ldraw
(score: 0.708)
|
