SlimeVoid / LittleBlocks-FML

LittleBlocks for FML
http://www.slimevoid.net/LittleBlocks
GNU Lesser General Public License v3.0
18 stars 13 forks source link

Little Block Internal Light level #71

Open Tarig0 opened 11 years ago

Tarig0 commented 11 years ago

This will be hard work but I think worth it.

Possible ways to do this create a 3D lightmap just like we do with TE, and block data and update that map when a block changes state( i.e. blockupdate, setblockID/metadata, TE data updated)

Tarig0 commented 11 years ago

We need to find a way to quickly detect if light is blocked from the Macro world in the Little chunk

example a box in the middle of the chunk should be pitch black inside, I guess we could see if a block can see the edge of the chunk on each side and determine if that block should be effected by any Macro light lvls.

assume we start with just the LB light map for each side

Edit 14 light level will by 0 past that point if side of block can see edge of LB world (will keep scanning through 15 LB chunks or reach border of LBWorld and MacroWorld) if Macro Light lvl - Macro Distance > LB light lvl AND render light level < Macro Light set render lght lvl == Macro light lvl - macro distance

We will store two light maps

LB light map -- this will be stored in NBT Tag Render light map -- This will be calculated from LB light map and Macro world light map and is chached for the time the Tile Entity is loaded

Eurymachus commented 10 years ago

Are we scrapping this?

Tarig0 commented 10 years ago

Flag it as a nice to have, but not planned

Tarig0 commented 10 years ago

I would like to revive this as a priority feature,

I think we should develop the internal little world light map in the following order.

  1. ignore macro world light and concentrate on getting light lvls in the little chunks to bleed properly.
  2. create 6 more light maps, one for each side. these maps will hold the light coming from the macro world that is hiting the little block. for debugging we should flip between each light map to see the effects on the light lvl A. the scan algorithm will scan for 15 * 8 little blocks in the designated direction (since light has a max 15 and won't bleed far enough to effect the little world)
for (int i=1, i < 15*size i ++)
      if (x%size = 1 &&  real world){ //only check if realworld if this is the first coord in another little chunk
         light = realworld.light - (i/size)
      }
      else  if (x+i,y,z is solid){
         light[x][y][z] = 0
         break;
      }
loop                  

This will be the base algorithm and will definitely not be the final implementation, unless the performance of the algorithm is massively faster than what I think it will be.

  1. once we get the arrays working, get the list of light lvls for a block positon and choose the max as the displayed light lvl
Tarig0 commented 10 years ago

we could do a prescan to see if there is a real world block in range, but this will only be faster if there isn't a real world block within 15 blocks of the little chunk

Tarig0 commented 10 years ago

The light array could be this

LBLightMap = int[size][size][size][7] <-- 6 macro sides, 1 little world

Arrays.asList(LBLightMap[x][y][z]).max() to get the max

skaviouz commented 10 years ago

I'm assuming there will be an option in the configs to disable this? I know if you had a bunch of chunks, people could get unneeded lag on low-end computers.

Tarig0 commented 10 years ago

Most of the lag will be from the server, due to the influx of data. I will have a config option for both client and server to turn off this high detailed lighting.

The server side will turn off the transmission and calculation of the extra data. The client side will only change how the user handles that information.

Tarig0 commented 10 years ago

oo Mobs never spawn without help of spawn eggs in the little world, and even then we re-route them back to the overworld, full size