Skip to main content

On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
(1 edit)

okay i understand, so it converts to 4 bit grey scale..thus 16 depths.......so it needs to convert it to 8 bit, thus 256 depths...but grab every 16th layer on one frame, then shift forward one bit and grab every 16th +1 depth on the next....16th +2 on the next..and so on...that seems relatively simple....that means each 256 depths will be displayed about 4 time every second.....that sounds perfect....could implement fibonacci later but keep it simple for now i suppose.

It's not quite that simple. I'm already using  full 32 bit textures, so 8 bit for the grey. Greyness corresponds to z in the algorithm (z is a value between 0 and 1, representing distance from the player). It's not the granularity of the z values, but the fact that two different z values will round to the same separation value in the algorithm. 

(2 edits)

so among other things this needs tweaking?????      #define separation(2) round((1-mu*Z)*E/(2-mu*2)

i'm sorry i myself am not much of a programmer

no sorry it is this that needs tweaking

#define round(X) (int)((X)+0.5

This is just a standard way to round to the nearest int, which needs to be done because you can't have a separation of 60.5 pixels, for example, because pixels come in wholes. 

So the only things I can change that would affect the layers are DPI and mu (depth of field). There are combinations of these that give a better spread of separation, but it often turns out messing up the stereogram.

Okay, making more sense now, I can see you have an option for render distance....i take it this needs to be a specific value?..can you dynamically cycle these 3 values +, ++, +++, +, ++, +++ on consecutive frames???? it would go someway to doing it.

(1 edit)

You have obviously chosen the depth of field and DPI values carefully, if you can cycle through all the values that give a good separation you may approximate a 3D scene

You could have a seperation of half a pixel, it's just this pixel takes on 2 values over 2 consecutive frames.........

To this end you could have any fraction of a pixel within reason of frame rate, bit depth and human perception...

if you give the human vision system an idea of what it is seeing, the brain will work out the rest....

to make it 3D don't want to define a layer/depth ...but approximate a volume

one frame might look weird by itself, but combined consecutively the 3D scene should present well

(1 edit)

okay i was wrong..there appears to be 20 layers...int + 0.5......

can you change that 0.5 value on each consecutive frame to a cycling value?

it needs to be a dynamic value

Fibonacci would be easy to introduce...just cut out furthest 23 depths and deal with 233 depths...by using Fibonacci ratios the rendered scene will not "pulse"..although that could look cool i suppose for a gaming environment.