How to clear a texture3D?

itgiawa

How can I clear a texture of all set pixels?

I'm repeatedly creating a texture3D and passing it to the shader. It seems to remember the old pixels after each pass, despite me creating a new texture3D each time. I even tried passing null to the shader in between passes, but somehow it still remembers old pixels.

Here are the details:

I've got a 3D voxel game like minecraft and I'm using a texture3D to communicate to the shader which voxels should be hidden (so as not to obscure the player) I'm creating a texture3D like this:

hide_voxels():

var width = 128
var height = 128
var depth = 128
var texture3D = Texture3D.new()
texture3D.create(width, height, depth, Image.FORMAT_RGB8)
var image = Image.new()
# Setting one layer creates and initializes every layer in the stack of images.
image.create(width, depth, false, Image.FORMAT_RGB8)
texture3D.set_layer_data(image, 0)

x = 1
y = 54
z = 2
image = texture3D.get_layer_data(y)
image.lock()
image.set_pixel(x, z, Color(1.0, 1.0, 1.0, 1.0))
image.unlock()
texture3D.set_layer_data(image, y)

x = 2
y = 54
z = 2
image = texture3D.get_layer_data(y)
image.lock()
image.set_pixel(x, z, Color(1.0, 1.0, 1.0, 1.0))
image.unlock()
texture3D.set_layer_data(image, y)

x = player_position.x
y = 54
z = player_position.z
image = texture3D.get_layer_data(y)
image.lock()
image.set_pixel(x, z, Color(1.0, 1.0, 1.0, 1.0))
image.unlock()
texture3D.set_layer_data(image, y)

material.set_shader_param("blocks_to_hide", texture3D)

Every pixel in the texture with an alpha of 1.0 marks a voxel that should be hidden by the shader. I have it set up so that when I click a button it calls hide_voxels and hides the first two voxels at (1,2) and (2,2) and also hides whatever voxel the player is standing on. I move the player between clicks:

click 1: all three voxels hidden fine click 2: all three voxels hidden fine. The previous voxel the player had hidden is unhidden. All good. click 3: all three voxels hidden fine. The previous voxel the player had hidden is unhidden. All good, except the first voxel that was hidden in click 1 becomes hidden again! So now we have four hidden voxels!

Somehow the texture is remembering the pixel that I set in click 1.

I can "clear" the texture by standing still and clicking 7 times. Each click toggles the voxel that should not have been hidden until finally its unhidden permanently.

I can't wait for godot 4 so I can have real arrays!

xyz

Looks like you're again mixing up y and z between world and texture coords. But can't tell for sure without seeing shader code.

Also, calling set_layer_data() when changing pixels is redundant (and detrimental to performance) because set_pixel() operates directly on texture data. That's why you're locking it in the first place.

cybereality

If you want to use a Texture3D as an array, you need to disable filtering. That way the pixel you set will be exact. Otherwise you will get default interpolation between the layers. So do this when you create the Texture3D:

texture3D.create(width, height, depth, Image.FORMAT_RGB8, 0)

xyz

On top of everything said so far, if you're storing visibility in the alpha component of the texture, your texture format should support alpha. Otherwise shader may always read 1.0 for alpha. So use FORMAT_RGBA8 instead of FORMAT_RGB8. Better yet, if you only need one byte of information use luminance format FORMAT_L8, and read R component in the shader. It'll save you storage space and update time as the texture will be significantly smaller.

itgiawa

Thanks so much for the help guys! But the shader still remembers old textures. I'm turning some of the blocks white for easier debugging.

@cybereality I disabled filtering and confirmed it works by noticing that if I use colors they no longer bleed into one another. Also, with filtering disabled the behavior has changed.

Some blocks that I've marked simply never get unmarked. Other blocks flash white every other time I click. But in both cases once a block has been marked the shader never forgets, despite me passing a new texture each time I click.

@xyz I'll deff try to switch to FORMAT_L8 once I get this working. Thanks!

I tried getting rid of texture3D.set_layer_data(image, y) but that resulted in no blocks being marked for some reason...

I don't think I'm messing up coordinates because the blocks do get marked where I expect them too.

Heres my shader code if that helps:

    uniform sampler3D blocks_to_hide;

    vec3 _pixel_world_pos = (CAMERA_MATRIX * vec4(VERTEX, 1.0)).xyz;
    	
    	ivec3 voxel_that_pixel_is_in = ivec3(int(_pixel_world_pos.x), int(_pixel_world_pos.y), int(_pixel_world_pos.z));
    	vec4 result_test = texelFetch(blocks_to_hide, ivec3(voxel_that_pixel_is_in.x, voxel_that_pixel_is_in.z, voxel_that_pixel_is_in.y), 0);
    	if (result_test.x > 0.0) {
    		ALBEDO = result_test.xyz;
    	}

xyz

After creating the texture, try to iterate through all its images and zero-out all data by calling Image.fill().

If you still get the same behavior, it's probably shader related.

cybereality

Looking at the GDScript code, it looks correct. I don't think setting the layer is needed, because you already have a reference to the image. So that is probably redundant. And setting the shader param I would assume would copy the texture3d to GPU memory (though maybe it doesn't work instantly).

However, it might just be a bug in your shader code (most likely). Like this line:

result_test.x > 0.0

You can almost never compare floating point values directly and expect to get an exact value. Although zero is well defined, you are doing a texel fetch (especially if there is filtering involved) so you might not get exactly the value you put in. It would be better to check using some epsilon value, such as:

result_test.x > 0.001

That might help.

cybereality

Actually, set_layer_data does seem to be needed, but I still think it's a bug in the shader code.

xyz

@cybereality said: Actually, set_layer_data does seem to be needed, but I still think it's a bug in the shader code.

That's strange as it would mean that get_layer_data() creates a copy instead of returning just a reference. Which is strange by itself.

cybereality

So you only need to use set_shader_param once for the texture3d. Once it is attached to the shader, you can modify it in GDScript with the set_layer_data and it will update fine. Not sure if that is related to your problem. But it's probably still a shader bug, because I just tested it and confirmed the texelFetch works fine.

cybereality

@xyz said:

@cybereality said: Actually, set_layer_data does seem to be needed, but I still think it's a bug in the shader code.

That's strange as it would mean that get_layer_data() creates a copy instead of returning just a reference. Which is strange by itself.

Yeah, that is what it appears like. And the docs are vague but do give the impression it's a copy.

Image get_layer_data ( int layer ) const Returns an Image resource with the data from specified layer.

Notice it doesn't say it returns the image at the layer, but an image with the data from the layer. Hence a copy. Which sort of makes sense, now that I think of it, because texture3d probably has it's own data structure (e.g. not just a simple array of images) in which case the image you put in doesn't exist anymore.

xyz

@cybereality Right. Then this will make the whole approach even more time consuming. But I too think this is more likely to be shader related.

cybereality

So the Texture3D approach should work, but honestly it will probably be faster to just use a single image and write the logic for the z axis yourself. I just did a test, and you can modify a standard Image (using set_pixel, without recreating it) though you do need to use ImageTexture set_data, which could be expensive. I think using 3D textures is conceptually easier, and maybe it is optimized already under the hood, but my guess is that it was not designed to be used for something like this. But you should try to get it working because so far it don't see any bugs in Godot.

itgiawa

@xyz @cybereality Thanks! I incorrectly assumed that passing a new texture3D overwrote the reference to the old one. Calling fill() on every layer seems to be way to expensive, but if I just iterate through my array of voxels and un-mark each one before marking the next batch, then it works and seems to be performant enough. Likely faster than creating a whole new object each time (which is what I thought was happening)

I did the epsilon trick, and I'll keep it in mind for the future, but I wouldn't have expected that to work since each voxel is bright white and was no where near an r value of 0.

It is somewhat baffling to me that if I never zeroed out the old values that they would appear exactly half the time, but texture3D is somewhat of a blackbox. Who knows what its doing.

If things do have a hard time scaling up I'll give sampler2D a try.

Thank you again!

xyz

I was suggesting fill() just to test things out. This whole approach is risky performance-wise.

And yeah, you need to pass texture object to the shader if you create a new one via Texture3D.new(). However since you're creating that texture object immediately after you destroyed the old one, the texture ID in underlying (GL) implementation may stay the same, hence the Sampler2d uniform doesn't appear to need an update. But it's not guaranteed so you may encounter additional bugs in the future if you assume this.

Because of similar reasons the exactly same chunk of video ram may be allocated each time and if you don't clear anything, data from the last texture could still be there. But none of this is guaranteed either. That's why I hinted testing it out with fill().

cybereality

Can you post your entire shader code?

itgiawa

@cybereality sure, this is the simplest version that exhibits the behavior of toggling pixels on and off after each texture update:

    shader_type spatial;
    render_mode blend_mix,depth_draw_opaque,cull_disabled, unshaded, diffuse_burley,specular_schlick_ggx;
    uniform vec4 albedo : hint_color;
    uniform sampler2D texture_albedo : hint_albedo;
    uniform float specular;
    uniform float metallic;
    uniform float roughness : hint_range(0,1);
    uniform float point_size : hint_range(0,128);
    uniform vec3 uv1_scale;
    uniform vec3 uv1_offset;
    uniform vec3 uv2_scale;
    uniform vec3 uv2_offset;
     uniform vec3 camera_origin;
    uniform sampler3D blocks_to_hide;
           
    void vertex() {
    	UV = UV * uv1_scale.xy + uv1_offset.xy;
    }
    
    void fragment() {
    	vec2 base_uv = UV;
    	vec4 albedo_tex = texture(texture_albedo, base_uv);
    	albedo_tex *= COLOR;
    	ALBEDO = albedo.rgb * albedo_tex.rgb;
    	
    	vec3 _pixel_world_pos = (CAMERA_MATRIX * vec4(VERTEX, 1.0)).xyz;
    	
    	ivec3 voxel_that_pixel_is_in = ivec3(int(_pixel_world_pos.x), int(_pixel_world_pos.y), int(_pixel_world_pos.z));
    
    	vec4 result_test = texelFetch(blocks_to_hide, ivec3(voxel_that_pixel_is_in.x, voxel_that_pixel_is_in.z, voxel_that_pixel_is_in.y), 0);
    	if (result_test.x > 0.001) {
    		ALBEDO = result_test.xyz;
    	}

	METALLIC = metallic;
	ROUGHNESS = roughness;
	SPECULAR = specular;
    }

xyz

Out of curiosity, what's your setup for drawing voxels? What nodes are you using for the cubes?

cybereality

Shader code looks mostly alright. One thing that looks suspect is the view to world transformation. If you are checking VERTEX, and the blocks are on a grid, then the vertex will be on the dividing edge of the grid line, leading to z-fighting. This would make sense that your blocks would flicker or fail to update. You want to actually be checking the center of the block (which you won't know in a fragment or vertex shader). I'm not sure the best way to fix this, but I think that is the problem.

itgiawa

@cybereality Good catch. Actually there is z fighting (you can see it in my screen shot, the top face of a white cube is not solid), but I'm pretty sure thats a separate issue, because I do have a fix for it, but even with the fix I still get the block toggle.

But you guys fixed the block toggling, I just have to un-mark voxels when I'm done hiding them and I'm good : )

@xyz I'm using Zylanns awesome engine: https://github.com/Zylann/voxelgame Easily the best voxel engine for Godot. Nothing comes close.