[Applejinx]

I'm curious to see how quickly it gains a performant 3D layer now that people capable of getting performance out of Unity are looking at it.

It was interesting seeing some people bounce off it on the grounds of woeful inefficiency. I don't remember the person, but one Unity refugee traced the path of a raycast and Godot more or less needed to treat it as a dynamically typed generic thing, going through a huge rigamarole to get a result.

It's possible to hack in more direct access for those who can make sense of it. I don't think there's a thing going on in Godot's 3d engine that some of these Unity refugees can't understand. They're running into arbitrary obstacles based on Godot's attitude towards what's clean and elegant code. These obstacles could go away really quickly under the right conditions…

[krapp]

>I don't remember the person, but one Unity refugee traced the path of a raycast and Godot more or less needed to treat it as a dynamically typed generic thing, going through a huge rigamarole to get a result.

There was a whole HN thread about it[0], and the response[1].

[0]https://news.ycombinator.com/item?id=37561762

[1]https://news.ycombinator.com/item?id=37598985

[gumballindie]

> it gains a performant 3D layer

It already is pretty darn performant - but without the many convenience features unity and unreal have. Also it does lack means to modify vertex buffers directly on the GPU - a feature I liked in Unity (https://docs.unity3d.com/ScriptReference/Mesh.GetVertexBuffe...). However, I think godot shouldn't try and implement everything - the project should focus on getting core functionality performant and flexible enough.

Everything else - managing massive world, etc, should be done by 3rd parties and monetised. I hope the game dev world wont take the web dev world path where code is in oversupply and there are little options to monetise.

Unity's asset store allowed many people to gain freedom by selling assets. I think godot should follow the same path. But indeed for that the engine needs even more low level access exposed in a nice manner.

[ajvs]

> I hope the game dev world wont take the web dev world path where code is in oversupply and there are little options to monetise.

Very beneficial for the consumer however. Right now the bar to create a good videogame is rather high, and this leads to the current hellscape where so many videogames are plagued with lootboxes, season passes and other microtransactions to make up for the multiple years in dev time required with many employees.

If the tooling gets better to the point that it takes less time and less devs to create good games that don't require the insane levels of monetisation, then this trend is more likely to be reversed.

[DonHopkins]

Unity also has a C# wrapper layer around C++ objects. Most of the performant stuff is written in C++, and the C# source code they provide as reference is just a wrapper around it.

For example, the Cloth bindings with annotations like [NativeHeader("Modules/Cloth/Cloth.h")] and [NativeClass("Unity::Cloth")]:

https://github.com/Unity-Technologies/UnityCsReference/blob/...

[imtringued]

>It's possible to hack in more direct access for those who can make sense of it.

>These obstacles could go away really quickly under the right conditions…

I'm not sure why you feel the need to paraphrase this so much but the GDextension API is a thing and it is more efficient but it hasn't been implemented for C#. The blog poster extrapolated from the C# bindings that there are unfixable flaws in the engine when in reality the C# bindings aren't up to date yet.