 | | 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)
|
