<tterrag> need to add a way for a chisel block to say "use this model as a template"
<gigaherz> heh
<tterrag> currently I just use one hardcoded model
<tterrag> which is still better than before
<gigaherz> ICustomModelLoader?
<tterrag> where we used no models and generated quads on the fly
<tterrag> no need for that
<gigaherz> heh
<tterrag> it works off the vanilla format
<gigaherz> ah
<gigaherz> hmm
<gigaherz> vanilla model files
<tterrag> currently I use
<tterrag> chisel_block.json -> {"parent":"block/cube"}
<gigaherz> have a "parent":"minecraft:block/cube"
<tterrag> :D
<tterrag> too slow
<gigaherz> yep ninja'd
<gigaherz> that's probably the best option
<tterrag> was just changing that to block/stairs or block/fence_ns for testing
<gigaherz> are chisel blocks separate?
<tterrag> separate...from...?
<gigaherz> as in
<gigaherz> different ids for the full blocks, stairs and such
<gigaherz> like vanilla
<gigaherz> or single-id blocks with TE-based actual state?
<tterrag> no TEs that would be awful
<tterrag> we pack the variants into 16s
<tterrag> and use basically 1.7-style meta for that
<gigaherz> aha
<tterrag> just a PropertyInteger
<gigaherz> so full blocks are grouped in packs of 16 each
<gigaherz> and stairs have one id each?
<tterrag> yes
<tterrag> 2 stairs per ID
<tterrag> since a stair has 3 bits of states
<gigaherz> ah right
<tterrag> chisel has always been ID concious, it has to be with so many dang blocks
<gigaherz> 4 facings + up/down
<gigaherz> yeah makes sense
<gigaherz> that's why I didn't assume ;P
<tterrag> variable-length metadata would be a godsend for chisel
<tterrag> but it's a pipe dream for now :P
<gigaherz> that's sortof akin to using a TE
<gigaherz> if only we could store the TE data in a compact format instead of NBT
<gigaherz> ;P
<tterrag> not really
<tterrag> variable-length metadata would mean that there really is NO metadata
<gigaherz> well yeah
<tterrag> instead a block just marks out how many states it has and the world allots it that many IDs
<gigaherz> just
<gigaherz> provide a list of "persistent" blockstate properties
<tterrag> this would actually lead to a huge increase in ID availability as most blocks don't use meta at all
<gigaherz> and MC could just save those as separate IDs
<PaleoCrafter> Mojang is sorta preparing for that
<gigaherz> in fact
<gigaherz> that'd be the ideal case
<tterrag> PaleoCrafter: yes, that's my hope
<gigaherz> full 16 bits for blockstate ID
<gigaherz> no meta
<gigaherz> there's MANY blocks that don't make use of all 16 variants
<tterrag> the IDEAL case is having separate ID maps per cubic chunk, meaning that ids could be integer based but only saved as 12 bits
<gigaherz> all the blockstates using 3 bits for 6 values
<tterrag> that's a bit nuts though ;)
<gigaherz> no need for that
<gigaherz> if you remove the "block id"
<gigaherz> and assign each blockstate an ID instead
<tterrag> right that's what I'm talking about
<gigaherz> then you have 12+4 bits total without changing the save format
<tterrag> but that still limits to 16 bits
<gigaherz> since metadata bits become meaningless
<tterrag> which is a lot, but not infinite
<gigaherz> yes
<tterrag> 32 bits of ids is virtually infinite
<gigaherz> but for the purpose of chisel, that alone would be perfect
<tterrag> actually I take back the cubic chunk thing
<gigaherz> you'd move from having "packs of 16"
<tterrag> one ID map per chunk = 16 bits of IDs per chunk
<tterrag> then just save an int->int map with the chunk and bam
<gigaherz> that'd be annoying
<tterrag> not really
<gigaherz> suppose the case where someone has a large base
<gigaherz> with like, one floor per mod
<tterrag> uh...ok
<gigaherz> all the way from bedrock to build limit
<gigaherz> all packed with 65537 distinct blockstates
<gigaherz> ;P
<tterrag> and?
<tterrag> what's bad about that?
<gigaherz> [22:25] (tterrag): one ID map per chunk = 16 bits of IDs per chunk
<gigaherz> hmm no wait
<tterrag> 16*16*256 = 65535
<tterrag> I can math
<gigaherz> a chunk is 16x16x256
<gigaherz> can't possibly overflow
<tterrag> (yes that's off-by-one but I'm counting 0)
<gigaherz> yeah
<gigaherz> even if you literally packed each cell with a different blockstate
<gigaherz> you'd still be able to fit it in 16 bits
<gigaherz> so a chunk header with an array of IDs
<gigaherz> (32bit IDs)
<gigaherz> and then each block cell would just blockstates[ids[cell_idx]]
<gigaherz> yeah that'd work
<tterrag> bingo
<tterrag> only a small increase in world size to save the id maps
<tterrag> I'm guessing the id map would generally be less than 16 bits of data total
<PaleoCrafter> if you're having a map from every 16bit id to a 32bit id, woudldn't it be more efficient to just store 32 bit IDs then? :P
<diesieben07> no, that would mean 32 bit per block pos
<tterrag> sorry, 5000 bits, 5kb
<diesieben07> not 16 bits
<tterrag> diesieben07: why
<diesieben07> @paleo
<diesieben07> theoretically you could figure out how many bits you need per chunk
<tterrag> PaleoCrafter: it's much less expensive to store ONE map of 32b->16b than it is to store 32b 65k times
<diesieben07> and potentially even have a versino where you just map 32b->8b
<diesieben07> if there's just 16 different blocks in the chunk
<PaleoCrafter> well, but if you have a chunk where all blockstates are distinct?
<diesieben07> then you need 16 bits per pos
<diesieben07> and then a map to tell what those 16 bits mean in the 32 bit versions
<PaleoCrafter> then you have a 32bit mapping for every 16bit ID
<diesieben07> oh
<diesieben07> right.
<PaleoCrafter> + the 16bits per blockpos
<diesieben07> haha
<diesieben07> true
<PaleoCrafter> :P
<PaleoCrafter> so you essentially store double the amount you would if you just stored the 32bit ID
<diesieben07> there'd have to be a cutoff value where you say "screw the map, use 32 bit everywhere"
<tterrag> that's the worst case scenario
<PaleoCrafter> guess so
<tterrag> 99.9% of chunks will have waayyyy less blocks than that
<diesieben07> overall its not as simple as you think
<PaleoCrafter> I guess that threshold can be calculated
<tterrag> but yes, there could be a backing map fallback
<gigaherz> PaleoCrafter: that's the WORST case
<gigaherz> XD
<diesieben07> the problem si if you cross the threshold you have to recompute everything
<PaleoCrafter> yeah, but you have to plan for everything :P
<gigaherz> worst case is you store 32 bits per cell effective
<diesieben07> unless there is some fancy math you can do to avoid that
<gigaherz> best case you store only 16 bits of "0" (full air)
<gigaherz> average case would be only a slight overhead
<tterrag> recomputing a whole chunk in a batch isn't that expensive
<gigaherz> recomputing what?
<gigaherz> the ID is only needed for storage in the save format
<tterrag> yes but the map is gone
<gigaherz> for networking, the actual blockstate ID would make most sense
<diesieben07> the chunk itself already stores the IDs
<tterrag> you've passed the threshold where the map is more efficient
<gigaherz> I'd have it as 32bit in memory
<diesieben07> thats not a good idea :P
<diesieben07> you'd double the ram usage
<tterrag> er...except no
<tterrag> because java doesn't use less memory for shorts
<PaleoCrafter> let's just drop the topic and let Mojang deal with it when the time comes? :P
<diesieben07> uhm yes it does
<diesieben07> in arrays at least
<gigaherz> most programming languages use struct padding
<diesieben07> not on the stack
<gigaherz> ah right
<tterrag> in arrays maybe
<gigaherz> hmm
<diesieben07> nt maybe ;D
<gigaherz> actually
<tterrag> so yeah, you'd have to remap the whole chunk
<gigaherz> is it an array?
<gigaherz> does it store
<gigaherz> blockids[]
<tterrag> yes, the chunk IDs are packed into an array
<gigaherz> lightlevels[]
<gigaherz> etc
<diesieben07> if byte / short arrays would use 4 bytes per element that would be crazyness :D
<gigaherz> in separate arrays?
<tterrag>     private final ExtendedBlockStorage[] storageArrays;
<diesieben07> they use a char[] now i think
<diesieben07> unsigned 16 bit
<gigaherz> diesieben07: yes but if you store classes/structs, then padding DOES take effect
<tterrag> seems so
<tterrag>     private char[] data;
<gigaherz> aha
<gigaherz> so iew.
<diesieben07> yes but only if need be
<gigaherz> ew.
<gigaherz> it sounds slow XD
<tterrag>     public IBlockState get(int x, int y, int z)    {        IBlockState iblockstate = (IBlockState)Block.BLOCK_STATE_IDS.getByValue(this.data[y << 8 | z << 4 | x]);
<tterrag> what a strange packing method
<tterrag> yzx
<tterrag> .-.
<diesieben07> its for a reason
<diesieben07> they changed it because it apparently improves the compression
<tterrag> probably, since most blocks are lower down
<tterrag> that means less msb
<tterrag> most of the time y is < 128 which means you can lop off a bit
<gigaherz> for compression
<gigaherz> you want the least changing bits first
<gigaherz> simple matter of probability: if you make the most significant bits change less
<gigaherz> thne the chances of finding "near repetitions" are higher
<gigaherz> which means you can compress better
<tterrag> that as well
<gigaherz> and in a chunk, Y changes the least
<gigaherz> all compression formats work more or less on the idea of locality: nearby data has a higher chance of being similar
<gigaherz> that's why you don't normally store all the history since the beginning of the compression stream
<gigaherz> you use windowed dictionaries or similar
<tterrag> what about middle-out compression
<tterrag> :>
<gigaherz> what's that?
<gigaherz> XD
<tterrag> go watch silicon valley :P
<Drullkus> tterrag: So that means compression gets much worse with modded worlds with 3000 taken block ID's? :P
<tterrag> no
<tterrag> unless that mod is adding random blocks to y>128
* kroeser|away is now known as kroeser
<Drullkus> Wait
<Drullkus> OH
<Drullkus> The y-level
<Drullkus> ...like natura?
<tterrag> natura probably doesn't help, no
<diesieben07> keep in mind this compression stuff probably does nto do THAT much
<diesieben07> and the price per GB for modern harddrives is miniscule
<Pennyw95> Is it possible to combine booleans in a blockstate json? Like, place one inside another?
<tterrag> on a large world it could be significant though
<diesieben07> nobody should have storage space probelms these days :D