Special:
|
[DAT] (requires LDraw-compatible viewer)
|
Subject:
|
MLCad's Spezification description of buffer exchange doesn't add up
|
Newsgroups:
|
lugnet.cad.mlcad
|
Date:
|
Sun, 30 Mar 2003 18:47:24 GMT
|
Viewed:
|
3800 times
|
| |
|
|
Hi Michael,
As you know LPub tries to support MLCad's wonderful rotation steps and
buffer exchange. Using the two together in LPub uncovers some incorrect
behavior between the two.
LPub does not deal with images when doing buffer exchanges as indicated by
MLCad's Spezification 1.0, it instead deals with LDraw file contents.
LPub's problem is that it records rotation steps in the exchange buffers,
when in fact it should only put parts into the buffer. As I was working on
correcting my algorithms and reading the Spezification, I realized that
MLCad does not really save images when doing buffer exchange store.
The following LDraw file shows that MLCad *must* implement exchange
buffers as a list of parts:
0 Untitled
0 Name: rotbfx.ldr
0 Author: MLCad
0 Unofficial Model
0 ROTATION CENTER 0 0 0 1 "Custom"
0 ROTATION CONFIG 0 0
1 9 -40 -8 0 1 0 0 0 1 0 0 0 1 3703.DAT
0 ROTSTEP 0 90 0 REL
0 BUFEXCHG A STORE
0 ROTSTEP END
0 BUFEXCHG A RETRIEVE
1 12 -40 -8 -40 1 0 0 0 1 0 0 0 1 3703.DAT
0
The first added part is subject to a rotation step, so the echange buffer
A's image would have the technic brick pointing from lower left to upper
right. Immediatly after the buffer exchange store, there is a ROTSTEP END.
The image from buffer exchange retrieve A, combined with the second added
technic beam, should form a cross, but instead we end up with two bricks
parallel to each other. This means that the first added part was
"unrotated" as part of the retrieve, which implies that exhange buffers are
lists of parts without rotation step information.
Right?
Kevin
|
|
1 Message in This Thread:
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
