You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a few things I think would be great if they gained bigger types, such as instanceId and mask. I understand that the packing rules don't allow for any extra bits, but it would still be great if this could maybe be added as an extension that allows these bigger types.
The current limit is; only 8 different masks are allowed and up to 16M instances can be used. Even though right now we might question why 16M instances are needed, it could be useful in the future. The 8 bit mask already is quite limiting as things like layers might have to use separate flags and these use more than 8 bits (up to 24 bits). If this can't be fixed by enlarging the mask, perhaps it could be flagged as a flag. This way you can specify 1 << x instead of x, giving you up to [0, 1 << 255; or 1 << 32 due to integer limits] instead of [0, 255]. Since trace ray already uses a uint (since HLSL doesn't know byte as a primitive), nothing on the shader side would have to be changed. Only a flag on DirectX's and the driver's side that should be checked and convert the stored 8-bits with 1 << x and compares with the mask shot by the ray.
The text was updated successfully, but these errors were encountered:
There are a few things I think would be great if they gained bigger types, such as instanceId and mask. I understand that the packing rules don't allow for any extra bits, but it would still be great if this could maybe be added as an extension that allows these bigger types.
The current limit is; only 8 different masks are allowed and up to 16M instances can be used. Even though right now we might question why 16M instances are needed, it could be useful in the future. The 8 bit mask already is quite limiting as things like layers might have to use separate flags and these use more than 8 bits (up to 24 bits). If this can't be fixed by enlarging the mask, perhaps it could be flagged as a flag. This way you can specify 1 << x instead of x, giving you up to [0, 1 << 255; or 1 << 32 due to integer limits] instead of [0, 255]. Since trace ray already uses a uint (since HLSL doesn't know byte as a primitive), nothing on the shader side would have to be changed. Only a flag on DirectX's and the driver's side that should be checked and convert the stored 8-bits with 1 << x and compares with the mask shot by the ray.
The text was updated successfully, but these errors were encountered: