Godot Engine Hub

[Xrayez]

I'm not able to directly comment on Godot issues or proposals, see #191. However, occasionally I'd like to reach out to some people there to discuss or clarify things, and have a conversation independently of strict moderation and lack of free speech in Godot.

You're free to use this forum hub for whatever topic you always wanted to discuss in Godot, but was afraid to ask. 😉

Please, reply to posts directly, only create new posts for separate topics, thanks!

[Xrayez]

@golddotasksquestions godotengine/godot-proposals#5176

There are several complementary options:

• For Image operations, use Thread to prevent freezes.
• Split your textures into chunks.
• Use shaders (sorry!). If you need to blend textures, shaders can do this blazingly fast.
• As you say, find a way to expose texture_get_data_partial() in the engine, if possible (not sure if that's oversight, or limitation).

These are just ideas, but I'm certainly interested in this topic myself.

I wonder what's your concrete use case for this. I'd suggest splitting your texture into smaller texture chunks if you have to edit such large textures at runtime (I think that's how it's done in image editing apps). Not to mention that not all devices (especially mobile) support large textures. I've heard that some mobile devices support up to 2048px textures only.

[Xrayez]

@halgriffiths @MGilleronFJ @Streq godotengine/godot#64326

As you may have seen already, Goost provides something similar here, via Graph, GraphVertex, GraphEdge classes. The approach is object-based, which means that all aspects can be scripted, so it's very flexible and general-purpose, performance is acceptable for level generation. With GraphIterator, you can also customize for depth-first and breadth-first algorithms, or come up with your own algorithm via script.

However, I don't think that this kind of feature is going to end up as a built-in Godot feature, under any form. In any case, I hope you get inspired by these ideas!

[halgriffiths]

Why don't you think it will end up as a built-in feature? I actually left a message on the Goost discord just a few days ago asking for your permission to adapt exactly this for mainline Godot, funnily enough.

[Xrayez]

@halgriffiths I had no idea that you reached out! I left Godot community to be honest, I no longer use Godot for anything, so yeah feel free to make a pull request with everything you see in Goost and make Godot pull requests, if you wish! I'd appreciate that you mention Goost and/or me in your PR as well. 🙂

Why don't you think it will end up as a built-in feature?

My experience contributing to Godot tells me that features like these (that can be implemented in numerous ways) are generally refused by Godot core developers. They also "refuse by default", not really welcoming, don't you think? Even then, if there's a use case for it, they may just tell you that "it's better done via plugin", or "it doesn't need to be in core", or things like that. 😛

It's not instantly clear because Godot has no development philosophy: godotengine/godot-proposals#575. The existence of Goost is a testament to this. In any case, I'd suggest not to put your hopes high with Godot. It was easier to get things merged in Godot like 5 years ago, but not any longer.

In general, Godot leadership doesn't like when contributors go straight creating pull requests before proposals are approved. At the same time, they just ignore proposals if they are not interested in any of this, which is the case with godotengine/godot-proposals#3848. Speaking of myself, I personally have 3 years old proposals that are completely ignored and never looked at by Godot core developers.

[Xrayez]

@vpellen take a look here, I think that's what you're describing: #195 (comment)

But as I said, this kind of feature is unlikely be implemented in Godot. @halgriffiths's PR (godotengine/godot#64326) is half a year old now.

[Xrayez]

@brianwinterpixel I accidentally stumbled upon your proposal: godotengine/godot-proposals#6146.

See my previous proposal: godotengine/godot-proposals#913.

I'm the author of Clipper integration in Godot: godotengine/godot#28987. Godot's lead developer wouldn't allow me to make this feature configurable and versatile in the first place, otherwise I'd implement exactly what you suggested right from the start. This will remain a limitation of Godot.

I suggest you to take a look at Goost (this repository), which has Clipper2 integrated, while also providing boolean operations using nodes (similarly to CSG): #39.

[Xrayez]

This is also my reply to @smix8: godotengine/godot-proposals#6146 (comment)

[brianwinterpixel]

Yeah, I've already integrated Clipper2 into some native code for our project. I could definitely see the core team pushing for Clipper2 as a GDExtension rather than core, which I think is fine for Godot 4.

[Xrayez]

@brianwinterpixel the core Godot team is unlikely to consider something like this to be maintained as an GDExtension in official capacity, so I think this won't happen, I have no idea why you have such an expectation.

I say this because I used to be part of the Godot core team in the past, and know their stance on this really well. There's a strong reason why I decided to develop Goost extension back in the days, see godotengine/godot-proposals#3864.