Obscure LDView primitives bug?
2014-09-12, 13:20 (This post was last modified: 2014-09-12, 13:20 by Stephen.)
2014-09-12, 13:20 (This post was last modified: 2014-09-12, 13:20 by Stephen.)
Travis,
Not really sure if this is a bug in LDView or not. Thought I'd report it anyway in case it is of interest. I will concede it's arguably a pretty obscure set of circumstances.
With this minimal case MPD (it took me an hour to cut down my 50000+ part model to find the cause):
You'll note that I've done something a little unusual perhaps by including a reference to box.dat in one of the models. Note sure if this is "allowed" - but this was done because I wanted to simulate the appearance of edges of baseplates under a model without the render cost of the memory consumed by the studs on real baseplates, and a number of box.dat entries was quicker than using a whole bunch of quads.
Under normal circumstances viewing the above (either model) in LDView works fine.
However, if I then copy 3068a.dat from the LDraw parts directory into the project's own directory (because I intend to later customize it) and view the exact same file above (it now selects 3068a.dat from current directory) the appearance of Model2 is wrong within LDView. The 2x2 tiles still show, but they are completely missing their seams, and the POV export is also missing the calls to LDXSeamMatrix() for these parts.
Model2 fails to show correctly due to the box.dat reference in the unshown Model1. If I hide the box in Model1 (0 MLCAD HIDE), or I rearrange the order of the models so that Model1 comes after Model2 in the MPD, then Model2 once again shows correctly with the seams.
Like I said, pretty obscure circumstances to be using box.dat directly within a model and also using a local copy of another .dat file, so not sure if you'd strictly classify it as a bug since maybe I'm not supposed to be doing this
Not really sure if this is a bug in LDView or not. Thought I'd report it anyway in case it is of interest. I will concede it's arguably a pretty obscure set of circumstances.
With this minimal case MPD (it took me an hour to cut down my 50000+ part model to find the cause):
Code:
0 FILE Untitled.ldr
0 Untitled
0 Name: Untitled.ldr
0
0 FILE Model1.ldr
0 Model1
0 Name: Model1.ldr
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 4 0 0 0 0 0 1 0 1 0 1 0 0 box.dat
0
0 FILE Model2.ldr
0 Model2
0 Name: Model2.ldr
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 28 0 0 0 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 40 0 0 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 40 0 40 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 0 0 40 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 -40 0 40 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 -40 0 0 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 -40 0 -40 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 0 0 -40 1 0 0 0 1 0 0 0 1 3068a.dat
1 28 40 0 -40 1 0 0 0 1 0 0 0 1 3068a.dat
0
0You'll note that I've done something a little unusual perhaps by including a reference to box.dat in one of the models. Note sure if this is "allowed" - but this was done because I wanted to simulate the appearance of edges of baseplates under a model without the render cost of the memory consumed by the studs on real baseplates, and a number of box.dat entries was quicker than using a whole bunch of quads.
Under normal circumstances viewing the above (either model) in LDView works fine.
However, if I then copy 3068a.dat from the LDraw parts directory into the project's own directory (because I intend to later customize it) and view the exact same file above (it now selects 3068a.dat from current directory) the appearance of Model2 is wrong within LDView. The 2x2 tiles still show, but they are completely missing their seams, and the POV export is also missing the calls to LDXSeamMatrix() for these parts.
Model2 fails to show correctly due to the box.dat reference in the unshown Model1. If I hide the box in Model1 (0 MLCAD HIDE), or I rearrange the order of the models so that Model1 comes after Model2 in the MPD, then Model2 once again shows correctly with the seams.
Like I said, pretty obscure circumstances to be using box.dat directly within a model and also using a local copy of another .dat file, so not sure if you'd strictly classify it as a bug since maybe I'm not supposed to be doing this