Default voxel stream immerge and emerge don't get called about godot_voxel HOT 10 CLOSED

Could you elaborate more on what you are attempting to do? Are you trying to extend VoxelStream from GDScript?

from godot_voxel.

Are you trying to extend VoxelStream from GDScript?

Yes, I'm creating my own stream using gdscript. I named my functions emerge_block(out_buffer, origin_in_voxels, lod), and immerge_block(Ref<VoxelBuffer> out_buffer, Vector3i origin_in_voxels, lod)
in the functions I put a print statement, which doesn't seem to get called (both debugger and terminal say nothing)

from godot_voxel.

I'm not so sure the problem is in VoxelStream. I was exploring this today and found a bug in voxel.cpp, though fixing that didn't solve the problem. I suspect the issue is with the VoxelLibrary. Before implementing your own stream, can you create a code based VoxelTerrain using any of the other built in streams? I have been unsuccessful so far, but I suspect that is the cause of your issue. I'm still researching.

from godot_voxel.

I can create a terrain just fine using other streams (I am on a bit older version than the repo here)
as a side note, I also have the same issue with this in my own C++ module. I use the same method as here, and I'm also calling from a different thread

from godot_voxel.

Ah, I forgot to add my terrain to the tree with add_child. So much C++ debugging to figure that out.... :(

emerge_block isn't being called because of a bug in voxel_stream.cpp. script->call(...) is calling the wrong overloaded variation. If you uncomment the Variant::CallError err; on the line before it, and change the line to script->call("emerge_block", args, 3, err); it will call your gdscript function. Repeat for immerge.

I now have a custom gdscript stream. All it does is makes an infinite plane, but it works:

extends VoxelStream

func emerge_block(buffer:VoxelBuffer, origin:Vector3, lod:int):
	if lod!=0: return
	if origin.y < 0: buffer.fill(1, 0)	

I will submit a PR to close this issue.

from godot_voxel.

Ah, I'll try that when I have the time!

from godot_voxel.

There are two things to note here:

1. script->call("emerge_block", args, 3); is just calling the version with err internally, I wonder why writing it explicitely fixes the problem Oo

2. When combined with terrain, VoxelStreams always run inside a thread. I have a hunch that Godot is unable to report errors in that situation, maybe because very few people did this so far, or nobody in core devs considered working on making the debugger work with threads.
   See godotengine/godot#18330
   And godotengine/godot#2446

A workaround to test your VoxelStream would be to instance it, calling its functions and polygonize the result using a mesher directly, a bit less practical though.

from godot_voxel.

from godot_voxel.

@tinmanjuggernaut so you mean the call itself was wrong? Because as things are currently, if the call succeeded but an error occurred in GDScript, it would behave as if the function is not called because Godot does not report any error from threads.

from godot_voxel.

Ah, right both calls do end up in the same place at gdscript.cpp.
Args passed from your call: { Voxelbuffer hashtable, Vector3i (0, 48, 0), lod=0 }

By adding the final parameter, the call goes directly to gdscript.cpp where p_argscount=3.
1168:Variant GDScriptInstance::call(const StringName &p_method, const Variant **p_args, int p_argcount, Variant::CallError &r_error) {
1176: return E->get()->call(this, p_args, p_argcount, r_error);
r_error=CALL_OK(0).

However in the old version it stops by script_language.cpp:246 first.
Variant ScriptInstance::call(const StringName &p_method, VARIANT_ARG_DECLARE) {

The arguments are received as { true, 3, null, null, null }. They are counted and reported as 2.

By the time it gets to the call in gdscript.cpp, p_argscount=2:
1176: return E->get()->call(this, p_args, p_argcount, r_error);
The return r_error is CALL_ERROR_TOO_FEW_ARGUMENTS(4).

from godot_voxel.