#3DS – non-deterministic?
8 messages in this thread
Hi Gary,
pretty scary question, huh? Sorry for bothering you yet again, but I'm
running into trouble yet again, so I'll cry for assistance… Remember my
problems with corrupted GIFs about half a year ago? Well, this bug (we settled
for faulty hardware back then although I couldn't find any proof of it) is
haunting me again. But this time I'm gonna develop an excessive testing
strategy so this bugger won't escape me again – I'll keep you posted about the
results.
As for the non-deterministic behavior of 3DS, while running some test
patterns (scenes) in order to find the above mentioned error I discovered an
interesting phenomenon: different stills of one (same) frame are not
byte-equal. Responsible for this is (seemingly) the DITHER TRUE COLOR option in
the Renderer options dialog. If DTC is set to 'yes', pixels differ between both
pics, if DTC is set to 'no', pixels are identical. I could verify this behavior
on two completely different computers, so it seems that 3DS uses a randomy
dither algorithm for DTC.
Is this a bug or a feature? <g> Not that I think this behavior is
connected in any possible way to my 'corrupted-*.?IF-problem', but I'm just
curious if you already knew about this feature (well, the possibility for
_that_ is in the 99.9999% range, but anyway…) and even if there's no possible
way for a connection, what about an _im_possible way…?
Be back soon (hopefully) with new results,
Volker
We absolutely do use some randomness in our dither algorithm, hence the
difference between the images.
– G
Depends on the dithering algorithm….I thought that (under release 2, anyways)
that you could change it in the 3DS.SET program to different types of
dithering. You could probably find it in the Reference manual.
Now, what I want to know is *WHY* does 3DS, when dithering, INSIST on dithering
solid patterns in 8-bit FLICS????
I can NEVER use dither on, because it shoots up the size of the file by virtue
of
its unnecessary dithering! Can somebody answer that one?
<<Now, what I want to know is *WHY* does 3DS, when dithering, INSIST on
dithering solid patterns in 8-bit FLICS????>>
When rendering your flic set Dither 256 to No and you'll get solid colours(and
increased banding).
<<I can NEVER use dither on, because it shoots up the size of the file by
virtue of
its unnecessary dithering! Can somebody answer that one?>>
The flic file format is RLE(run length encoded) which means that runs of pixels
of the same colour are encoded to compress the file size. This method is best
for images that have long runs of pixels that are the same. A completely white
image can be really well compressed. But when you use dithering, pixels are
varied and changed giving a more random image that RLE can't compress as well,
this is why the file sizes are much larger for dithered flics.
DaviD "I need more fric not flics" GouID
Thanks for the response, Dave. I did some reading myself and am a bit clearer
on the "Delta" scheme for flics (only the changing pixels get updated). I
understand why dithered flics are so big.
But as an even more basic question, Why are large, solid areas of color (for
instance a solid rendering background) dithered in patchy areas and with
different patterns for different frames of a dithered flic. To demonstrate,
try rendering a simple animation over a solid background with dither on. Once
rendered, you'll notice that in odd angular areas, the solid color is dithered
and "creeps" from frame to frame, even though there is no real motion in the
solid color.
I can't explain it.
Anyone have info regarding?
Jim Spoto
<<Why are large, solid areas of color (for instance a solid rendering
background) dithered in patchy areas and with different patterns for different
frames of a dithered flic.>>
Firstly the all the colours for all the frames of the animation amount to 256.
So this doesn't leave you with many colours for the details. The problem you
mentioned can either be caused by an incorrect palette or the simple fact that
you'll always get banding when using such a small palette for a gradient such
as you described.
<<To demonstrate, try rendering a simple animation over a solid background with
dither on. Once rendered, you'll notice that in odd angular areas, the solid
color is dithered and "creeps" from frame to frame, even though there is no
real motion in the solid color.>>
As Gary mentioned a few days ago the dithering uses a little bit of random that
no two frames will dither the same. This normally isn't a problem since
normally everything is moving in an animation.
DaviD "just a spoon full of randomness makes the medicine go down" GouID
Jim
I think your background is changing because of the palette mode you are using,
medium and high palette modes create an optmized palette for each frame so
there is a good chance that palette will change with each frame. Rendering to a
low or custom palette mode will force each frame to use the same palette and
might keep your solid background pixels from changing color
ME