[Gllug] Faster maths?

[salsaman]

salsaman wrote:

> salsaman wrote:
>
>> Adrian McMenamin wrote:
>>
>>> On Fri, 2007-03-09 at 00:49 +0100, salsaman wrote:
>>>  
>>>
>>>> Adrian McMenamin wrote:
>>>>   
>>>
>>>
>>>
>>>  
>>>
>>>> Perhaps you could do some optimising while the index is being 
>>>> created ? How do you generate the 8 bit palette ?
>>>>
>>>>   
>>>
>>>
>>>
>>> Median cut
>>>
>>>  
>>>
>>
>> I'm not familiar with that method, but it appears you will make cubes 
>> in RGB space which contain equal numbers of colour pixels.
>>
>> When you are counting the pixels, then you know which box they belong 
>> in.
>>
>> Or am I missing something ?
>>
>> Gabriel.
>>
>
>
> OK, now I see where the problem lies; when you add the dithering, each 
> pixel moves a random amount.
>
> To calculate this quickly, you should make a 3d map of all the cubes: 
> each cube has 6 faces which connect to another cube. So you need an 
> array of 256*6 connections. You will also store the side length of 
> each cube (256*3 array).
>
> Now when a point moves, you can track it's position as it crosses from 
> one cube into the next, first in the R direction, then G, then B. You 
> will then know which cube it ends up in, and you can map it to your 
> indexed palette.
>
> Gabriel.
>





Hmmm...actually it's not quite so simple as I thought. Each face can 
connect to multiple other cubes, so for each face you need to store an 
array of four ints (the opposite corners of the intersection with 
connecting cubes).

You can still use the same algorithm, it's just a little more complex to 
see which cube a pixel moves to when it crosses a face.

Gabriel.

-- 
Gllug mailing list  -  Gllug at gllug.org.uk
http://lists.gllug.org.uk/mailman/listinfo/gllug