#Field Render Design Flaw
01-Jun-95 10:29:05
Sb: #172963-#Field Render Design Flaw
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.