Unity Transport WritePacked and NetworkCompressionModel usage

Unity Engine
, ,
1

I am using Unity Transport and the WritePacked and ReadPacked functions from DataStreamWriter/Reader. These take a NetworkCompressionModel.

I have been unable to find documentation or samples for this, so I tried it out. Here’s what I’m doing:

On both client and server, I create a NetworkCompressionModel by simply doing:

new NetworkCompressionModel(Allocator.Persistent);

I store this in component data alongside the NetworkDriver and Pipelines.

I then pass that as a ref through my code until finally passing it to the DataStreamWriter/Reader, which does not take the parameter as a ref.

This is “working” and it’s doing “stuff”.

At first, I had one mismatch where I was writing a value packed, but not reading it packed, and I would get an error trying to read beyond the end of the DataStreamReader’s buffer.

After seeing that everything was working properly, I did some calculations by checking DataStreamWriter.Length after filling a big packet that has tons of packed floats. I did this once with WritePackedFloat calls, and then again with just WriteFloat calls. To my surprise, the packet was much BIGGER when using the WritePacked calls!

Why would this be? Having set this up a bit blind without documentation or samples, I would expect that I’m not doing it right, yet. Anyone else using WritePacked and NetworkCompressionModel?

2

Taking a quick look at the code surprisingly shows WritePackedFloat takes a NetworkCompressionModel as argument, but does not use it, it looked to me as the float is just written to the datastream directly, except that if the float value is zero then one 0 bit is written, if the float is non zero one 1 bit is written and then the 32bit float value is written.

Therefor if you have only non zero values you would end up with a larger size.

3

Thanks FakeByte, that’s what I see too. If I were to start using WritePackedFloatDelta against real baselines values, it seems like that would also make my packets bigger unless a lot of the values are exactly the same as the baseline.

I am assuming there is a plan to use NetworkCompressionModel and to pack values like 32-bit float deltas down to a smaller size? But maybe is not a priority yet?

4

NetworkCompressionModel uses Huffman encoding which gives smaller bit values to frequent repeating values, this is tricky with floats as they tend to not repeat as frequent as integers might do.