#Field Render Design Flaw
16 messages in this thread
I don't smoke, but thanks anyway. Nice try but no cigar for you either,
though, Gary <grin>. First off, just because everyone else does it wrong
doesn't mean 3DS should. 3DS is the market leader in its price range and thus
should be the one DEFINING the correct way of doing things, not following
everyone else's mistakes (to your credit, it does do this in a great many other
respects). Field rendering is intended to simulate a specific aspect of
television (interlaced scanning) and merely rendering the second field as
"Field N?" regardless of frame stepping doesn't accomplish this.
Secondly, Time/Scale Segment isn't an option when you have keys on
single-frame increments as it is. 3DS (rightly, this time) simply won't let you
scale below an amount that would cause keyframes to be lost. I thought of that
already, and for the projects we most need proper field rendering on, Scale
Segment would ruin the animation if we tried to scale it down that far (which
we can't because Scale Segment is too smart to let us do that). In particular,
animations with keys generated by KeyScript, Key Factory, or even BOUNCE_I.KXP
fit into this category (note that the description of BOUNCE_I.KXP says that it
will not look right with Field Rendering, which would be easily solved if 3DS
did Field Render right). PYTHON is another example of something that needs keys
on every frame to work correctly, and which Field Rendering as it currently
exists distorts.
At any rate, this seems to be something that would likely be so easily fixed
as to almost be patchable in-place. Instead of adding 0.5 to the current frame
number for finding the interpolated frame value of the second field, add 0.5
times the Nth Frame Increment. It's as simple as that. The results would be the
same for Nth Frame Increment = 1.
You're right about the issue of it being a problem with keys being on
every frame. For now, you can use keyman to do key reduction for you
and _then_ do it. We've got some code in r5 that'll help you out
quite a bit (but don't hold your breath <g>).
– G
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.
PMJI, but you really think a flickering pixel is proof positive of a
bug in the floating point unit of the pentium. I'm still laughing.
Come on! I normally learn quite a bit from your messages, but I think
you're really _really_ reaching on this one.
David, read my message again. The "flickering pixel" is along the
edge of a BUMP MAP. Bump Mapping, especially in Release 3 and above,
utilizes floating-point mathematics to get those nice smooth rounded
edge shading effects. Note also that the View Log showed that EVERY
SINGLE FRAME out of over a HUNDRED FRAMES that was rendered on either
of TWO SEPARATE PENTIUM MACHINES here had those pixels set one way,
and EVERY SINGLE FRAME out of over a HUNDRED FRAMES that was rendered
on any of FOUR 486 MACHINES in the SAME EXACT JOB with the camera in
the SAME POSITION and the Bump Map UNCHANGED and the object UNMOVED
**ALL** had those pixels set another way. The ONLY DIFFERENCE
between those frames where those pixels were concerned was the state
of those pixels, and the CPU of the machines they were rendered on,
and it was a 100% ONE-TO-ONE CORRESPONDENCE. Now, you tell me. Does
that sound like it could be anything else BUT a Pentium FDIV roundoff
error?
>> Does that sound like it could be anything else BUT a Pentium FDIV
>> roundoff error?
No, it doesn't. But, maybe you need to dig deeper. Since 3DS doesn't
use _any_ double precision math it's highly unlikely that's the
problem. Could the Pentium itself use the double precision math
internally even though 3ds isn't asking it to? I'm really no
authority on this but I believe Gary when he says that 3DS _can't_
have a problem with the Pentium bug. Could an IPAS use double
precision math? It'll be interesting to see what Gary hays to say
about it. Good luck in tracking it down if you decide to. I'd like
to know what it turns out to be.
You're right about the 3DS renderer not using any doubles internally
(that's how we got away with using the Weitek coprocessor in the old
days, and that's how we get all the speed out of it now). Beyond
that, I'm not an authority about the Pentium chip flaw (and to be
perfectly honest, I don't particularly care).
– G
" >> Does that sound like it could be anything else BUT a Pentium FDIV
>> roundoff error?
No, it doesn't. But, maybe you need to dig deeper. Since 3DS doesn't
use _any_ double precision math it's highly unlikely that's the
problem. Could the Pentium itself use the double precision math
internally even though 3ds isn't asking it to? I'm really no
authority on this but I believe Gary when he says that 3DS _can't_
have a problem with the Pentium bug."
————
Why do I get myself into these things? Ahh, what the heck, try this on
your Pentium:
4195835.0 x 3145727.0 (notice: only one decimal)
Works every time <G> if you check the result, you'll find it even more
off than your $9.95 calculator from K-mart (it might be off by 0.2),
your Pentium will be off by 256!!!! (Just in case: You do the check
by multiplying the above result by 3145727)
What it all comes down to is this: The Pentium's result is WRONG in
the 5th digit. This is even less precision than IEEE SINGLE-PRECISION
numbers are supposed to have.
<<<Good luck in tracking it down if you decide to.>>>
Did it, done that, doing it… <BG>
The problem with the Pentium was a few 0's in the wrong spots in its
internal division tables (Now fixed in the "new" processors). In
fact, the "cutting edge technology" from 1958 it uses is quite a
robust algorithm (aka radix 4 (or SRT)).
So, M&M is probably right on the button…
Jack
>> So, M&M is probably right on the button…
Well, at least as far as it being a Pentium issue. But it's still not a 3DS
issue, no matter what you say. And, FWIW I don't even have a pentium…..
(Goin' right to Alpha come fall)
DM
"Well, at least as far as it being a Pentium issue. But it's still not
a 3DS issue, no matter what you say. And, FWIW I don't even have a
pentium….. (Goin' right to Alpha come fall)"
Never did say that it is a 3DS issue, it is a Pentium issue…
Good luck with the Alpha, if NT gives you as many troubles on that as
it does with my equipment, you'll need it. (besides the fact that
there are close to zilch applications for NT on an Alpha)
Jack, Well, I won't be giving up my PC just yet though. I'm hoping that at
least 3DS will be compiled for Alpha. That's really all I care about – and
being able to network the alpha to my PC. I'm sure in the future though – with
some 50,000+ users of 3DS moving to NT later this year that the alpha will be a
much requested platform. Maybe then more publishers will start supporting the
Alpha. Hopefully…
DM
" the alpha will be a much requested platform. Maybe then more publishers will
start supporting the Alpha. Hopefully…"
When they do, I will. 🙂 (But since they aren't even supporting the Intel base
(millions of computers) yet, I'm pessimistic)
All jokes aside, I wished we could get the stuff compiled in native code
suppoting the chip/machine (multitask- thread etc) specific stuff instead the
usual "one size fits all" approach that delivers (years too late) an operating
system that's half (or less) the bandwith of the machines it runs on.
I just read the article in CADALYST an Autocad rel.13 for Windows NT and now
I'm REALLY WORRIED about 3D-Studio under NT.
The Autocad NT DOES NOT support multiple processors AND IS SLOWER THAN the
regular Windows version AND BOTH WINDOWS VERSIONS are SIGNIFICANTLY SLOWER THAN
the DOS VERSIONS!
Oh, Boy, I hope Gary is doing it right for us 3DS'ers…
Jack
As I understand it, all Intel FPUs from the original 8087 up to the "80587"
built-into the Pentium use the maximum precision internally and drop to a lower
precision only for the final result, to maintain the maximum possible accuracy.
This is common among FPUs. In fact, there is an internal resolution which is
far higher than double-precision (called, I believe, Extended Precision) in
which ALL internal Intel x87 FPU math is performed, at least beginning with the
80387.
The Pentium FDIV bug did not require double-precision math. ANY FDIV which
used a divisor and dividend whose relative primes fit in the holes in the
lookup table would produce the result, which could be in as little as the
fourth significant decimal place (the term "decimal" here refers only to Base
10, not to whether digits are to the left or right of the decimal point —
that's a function solely of the exponent, which is not involved in the bug —
only the mantissa is), well within the limits of single precision.
By the way, you laughed at me when you said that assuming the Pentium bug
because of a "flickering pixel" was ludicrous. Well, you know what 3D Studio
does? It makes sequences of images. These images are arrays of PIXELS. The
values of those pixels are computed by floating-point math. So, if the FDIV
bug DID affect 3D Studio, HOW **ELSE** WOULD IT SHOW UP!? Pixels are what 3DS
_DOES_! It's not a spreadsheet, so there are no numbers in cells. It's not an
accounting program, so there are no screaming banks and IRS agents to come
a-knockin' if the figures are wrong. 3DS's very "product" is PIXELS!!
Well, I never laughed or said ludicrous but, you are close, I did find it
amusing. Didn't mean to offend you though, hope you didn't take it like that.
Anyway, you're probably right about the whole thing anyway. It sure seems like
you've been digging into it. Well, enough said, I hope you find away around it.
I thought you could send in your chips and Intel would replace them? Seems an
easy fix. See ya.
DM
Oh, we will replace them. It's just that we were assured here that
the bug could not possibly affect 3DS in any way. And yet it does. We
didn't replace them before because we didn't think we needed to. We
took the information given in this forum at face value. Apparently
that was a mistake.
Heck… 5-10 minutes? No way. I ought to be able to mentally
conceive of it and have it appear magically in the code. Really.