Similar to lighting channels, have distance field channels that you can apply to specific things, i.e. have material distance field lookups have an option to input what channel it affects, and have objects have an option similar to lighting channels to pick which channel or channels in the distance field data they affect. This would be useful for people who use DF data for different things, as there are plenty of uses, from particle collisions, to dynamic masking, to foliage collisions, and more. I don’t know if this is even something that’s possible, but if it is, it’d definitely make things a lot easier from a development standpoint.
yep, I suggested this in some other thread and this would be nice
An arbitrary number of channels might add too much overhead but if the global distance field would be a Vector4 rather than a Float we could have 4 channels which would be a decent compromise
YES that would be absolutely perfect.
Using four floats instead of one does decrease performance and memory use accross the board though, even for those not using channels. If this does come in it should almost certainly be optional, but I don’t think that’s particularly easy to do…
To be honest, this is probably better served with a custom engine change since it’s a very specific request.
well there can always be a project-specific setting. it’s not like the code isn’t full of them :eek: 
On GPU cost is the same as far as I know. Or this is not fo materials?
It would require four times the amount of memory on GPU as it does now.
Correct. Are they stored as a single float volume textures right now and later fetched? Or they are written into g-buffer? Extra 3 channel in g-buffer would be rather expensive, its definitely should be optional.
Sorry to necro an old thread, was looking for a way to mask DF via some sort of channel and this is the only thing that popped up on Google.
But why do we need a million color channels? You shouldn’t really need more than 256 channels (like what stenciling provides). At that point you’re only adding 1 byte to the DF size, not 12 bytes.
Sorta surprised this isn’t a more common request. In my head there are tons of scenarios where being able to differentiate DFs would be beneficial.
