Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 3.3

godotengine.org

Post reply on HN
Print view View original

131–138 of 138 posts

Re: Godot 3.3

#131

Post by pjmlp »

lewispollard wrote: post #110
IshKebab wrote: post #81

Earlier quoted context omitted.

But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.

Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on…

That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.

Re: Godot 3.3

#132

Post by jay_kyburz »

TeMPOraL wrote: post #47
jay_kyburz wrote: post #43

Earlier quoted context omitted.

There is no built in occlusion system. So I would say no.

Wait, so if it's not good at 3D outdoor scenes, and not good at 3D indoor scenes, then... what is it good at, in terms of 3D games? That would only leave 3D models + minimal scene (e.g. top-down/isometric games), which minimizes the amount of occlusion?

Any game where camera frustum culling can easily cull the number of object rendered. So when the camera is pointing in a fixed direction and you have control what moves in front of it.

Re: Godot 3.3

#133

Post by meheleventyone »

ganonm wrote: post #75
meheleventyone wrote: post #73

Earlier quoted context omitted.

I’m not wrong just being more specific. All three engines frustum cull by default and all three do it at the level of the complete model. I said Unity and Unreal don’t frustum cull at the level of the individual triangle which was the factor the person I was replying to insinuated Godot lacked.

Apologies, misread your comment as "won't frustum cull by default".

No worries I can see how the original could have been more clear!

Re: Godot 3.3

#134

Post by IshKebab »

lewispollard wrote: post #110
IshKebab wrote: post #81

Earlier quoted context omitted.

But that's how 2D games actually work. They're really just 3D games with an orthographic camera. It doesn't really make sense to have separate 2D and 3D engines.

Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on…

> There's a pretty big overhead even if you're not using any 3D features.

Graphics cards haven't had 2D acceleration for decades so you're always using the 3D features.

Re: Godot 3.3

#135

Post by lewispollard »

pjmlp wrote: post #131
lewispollard wrote: post #110

Earlier quoted context omitted.

Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on…

That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

Re: Godot 3.3

#136

Post by lewispollard »

IshKebab wrote: post #134
lewispollard wrote: post #110

Earlier quoted context omitted.

Not true. Something as simple as transparency in a 3D engine is far less performant than a true 2D engine because of all the depth testing, shader overdraw, lightmapping, etc. There's a pretty big overhead even if you're not using any 3D features. Plus, in a true 2D engine you just work in pixels, rather than arbitrary 3D units that you have to work out the pixels from the projection, scale, camera settings and so on…

> There's a pretty big overhead even if you're not using any 3D features. Graphics cards haven't had 2D acceleration for decades so you're always using the 3D features.

Apologies for repeating my reply to the other comment, but I am interested in getting an answer to this question.

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

Re: Godot 3.3

#137

Post by pjmlp »

lewispollard wrote: post #135
pjmlp wrote: post #131

Earlier quoted context omitted.

That would make sense 20 years ago, nowdays all graphic cards are designed for 3D APIs, regardless what you do, the driver only knows about 3D stuff.

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

Yes naturally, GL ES 2 is a 3D API.

There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card.

So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side.

Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers.

However then shaders came into the picture, as consumer hardware finally became cheap enough to adopt capabilities of graphics workstations hardware.

First only Assembly language for GPUs, but by the time DirectX 8 and OpenGL 2.0 became widespread, we got C like shading languages.

GL ES 2.0 is basically OpenGL 2.0 only with shaders and hardware transform and lighting removed.

If you want to make best use of the GPU there is no way around writing shaders, regardless of it being 2D or 3D graphics engine.

In fact you want to code most of the typical 2D effects as shaders running directly on the GPU.

Re: Godot 3.3

#138

Post by lewispollard »

pjmlp wrote: post #137
lewispollard wrote: post #135

Earlier quoted context omitted.

Is that true of eg, the graphics chip in an older android phone, that only supports gles2? That's mainly what I mean by that statement.

Yes naturally, GL ES 2 is a 3D API. There used to be a time when we had accelerated 2D graphics cards, even with support e.g. GDI, and then the 3D graphics accelerator was an additional card. So there was a transition period when GPUs were still 2D accelerators that could do some 3D on the side. Then graphics cards got the ability to do matrix operations in hardware, this was still mostly 2D with 3D super powers. How…

Ah, thanks for your explanation - I'm with you now. I've done some shader programming myself, both "from scratch" and also in Godot, but I'm not an expert. So if you're using a 2D transform type, on the hardware it's still using a 3D/quaternion transform? Interesting.

And so even if I was careful to write shaders that efficiently operate in 2D space, those efficiencies would be trumped by the hardware converting it all to 3D space anyway?

I guess my intuition was that if you have a full 3D shader setup, eg the Unity renderer, that you add a layer of new shaders on top of to give a friendlier 2D API, that's going to be slower than just writing the 2D API on its own.

Post reply on HN