CompuServe Messages

#Field Render Design Flaw

    01-Jun-95 10:29:05
Fm: Marion K. Marks 70700,2777
To: Yost Group 76702,413
Code to fix it in r"5" (r4 — what we have now is r3.5 at best and I am NOT going to let that slide!)? Would this mean doing it right, or just something to aid in keyframe reduction? Gary, this is not a major rewrite I'm talking about here. In the Library there is something called "DXFPATCH" that patches 3DS r3 and r"4" (r3.5) and presumably r"4.1c" (r3.5.1c) to read AutoCAD r13 ASCII .DXFs! As a PATCH, not a plug-in! If something like THAT can be done by patch, then why not something like this which is merely replacing a single floating addition with a floating multiplication (by 0.5) followed by a floating addition? If I had to, I could disassemble the code and do it myself and upload the patch. For me it'd probably be an afternoon's work with no source code to refer to. For you guys, who have the source code and already know where the frame/field computation is, it'd be maybe 5 to 10 minutes' work at most. On another note, remember awhile back telling us that the Pentium bug could not affect 3DS? Well, it does. I have proof. We did a project with animated bump maps awhile back and network-rendered, and one pixel came out differently on the two Pentium machines we had as opposed to the four 486s. Since the Pentiums wound up rendering about half the frames (but not predictably which half — we only verified that it was just the frames rendered by the Pentium machines with the different pixels by Viewing the Log), that pixel seemed to "flicker" randomly in the final animation. Fortunately, the client didn't notice. But it's positive proof that the Pentium FDIV bug can indeed affect 3DS. If you like, I can upload two copies of the same frame from the animation in question, one rendered on a 486 and one rendered on a Pentium, that illustrates the difference.