After your post I first tried the same thing, taking the +1 off w and h, unfortunately for some reason this doesn't work, but then I tried just doing w-- and h-- before the first for loop...works perfectly. Very strange, since w and h are only used in a few places. I even tried taking +1 off as you did for both, and then adding -1 in all other places they are used, which should have the same effect as w--; h--; but it doesn't work.
On Nov 14, 2:36 pm, Fabrice <[EMAIL PROTECTED]> wrote: > just updated svn, there was a +1 in code, can you confirm if its ok, > cause i'm something else at the moment and can't test ... > > Fabrice > On Nov 14, 2008, at 10:57 PM, brainclog wrote: > > > > > Thanks for the quick response! I did what you said and it works > > perfectly now, thanks again! > > > On Nov 14, 1:36 pm, Fabrice <[EMAIL PROTECTED]> wrote: > >> no you are absolutly right , I've remarked this as well . > >> Its a bug, but there is an easy fixe you can do before I repair it > >> properly. > >> just pass a -1 to the width/height before it enters the loop. > >> whats happening is that it goes 1 pixel outside the source to check > >> the color, its a very dark place out there... :) > >> and dark places are zero on the source... black.. > > >> I try fixe asap and let you know. > > >> Fabrice > > >> On Nov 14, 2008, at 9:39 PM, brainclog wrote: > > >>> I have been using SkinExtrude to generate Elevation meshes and tile > >>> them. It's working good so far, except for a small problem. I'm > >>> getting dips between the tiles, and at first I thought there was a > >>> small gap between them. So I made a small hack to addChild() the > >>> bitmap information for ElevationReader every time it generates a > >>> tile. > >>> I should have a perfect gradient from black to red, going from > >>> bottom > >>> to top. What I get is that, but with the bottom and right of the > >>> bitmap always blurred, or maybe just fading out to black (same > >>> effect > >>> in my case). > > >>> Is this expected behavior? I'm trying to modify the code for > >>> traceLevels() in ElevationReader but it's taking me a while to > >>> decode > >>> what's going on. Any quicker way to fix this?
