/3/ - 3DCG

There actually will be metric fucktons of hidden geometry. The engine however does have built in occlusion culling, therefore geo that's not visible to the camera at all is not drawn. However the backside of geometry on the same object is drawn.

So in short yes there is a lot of hidden geo. but it's not exactly a metric fuck ton when the game is built.

This workflow saves time at the cost of polycount. However polycount is the least of anyone's concern.

It's actually ok because if you think about it, if you were to individually model all of your cliff specific assets, you would need a lot of different uv unwrapped and baked normals with different materials each. Just having a couple rocks that you can rotate and merge to get different effect is aria log pretty shader and lighting efficient.

Just some correction on that last post:

>Aria log

Actually pretty shader and lighting efficient

Also they aren't merged, they just clip through each other

>>475166
>>475167
wow, thank you for that reply.

well I remember when you had to be as efficient as possible regarding the polycount and was a bit surprised about this. but yeah, makes sense when most of its hidden geo does not get drawn so it's probably not that big of a deal nowadays.

again, thx.

>>475161
>metric fucktons of hidden geometry

Those boulders are probably like 10 polys each. Stop freaking out, you sperg. This is UE4, not the NES.

>>475175
Oh /3/

Always so constructive.

Those boulders are also a couple hundred easily

>>475161
Breh, those boulders are instanced, the extra copies take very little extra processing power.

There will be metric fucktons of hidden geometry, but you don't need to worry about it. Modern games aren't optimized the same way old ones were - the primary concern is no longer about the computer's limited resources but the development time and the limited budget: devs can't afford to be sitting there chopping every unseen polygon off every boulder.

It's a bit of a shock if you're just getting back into this sort of stuff without having done anything since the quake and half life days, but this kind thing has been standard for a while now. Don't worry about it. The engine can handle a lot of shit.

>>475184
UE4 is especially developed to handle monster loads of polycounts. Their demo scene contained a 4M terrain with rocks and trees and motion blur which rendered at 50fps without a drop.

>>475184
>devs can't afford to be sitting there chopping every unseen polygon off every boulder.

you have no idea what you're talking about. Tris that are outside the view frustrum or facing away from the camera get culled automatically before anything else happens. This is a basic property of directx and opengl

>>475186
It's not automatic, it has to be coded in.

Just because it's not in view doesn't mean it's not wasting resources.

Occlusion culling isn't automatic.

>>475187
Without the culling it's still loaded into ram and vram

>>475187
>It's not automatic, it has to be coded in.

the added code is the following:
>glEnable(GL_CULL_FACE);
>glCullFace(GL_BACK);

similar for directx

>>475191
That's not occlusion culling. That's backface culling.

>>475241
Similar, but ultimately not useful as well as being CPU bound. You see, when we render to the gbuffer our shaders are very simple and we only do a final shade once in the deferred lighting pass. In the past with forward rendering, sure, occlusion culling could work, but in modern AAA deferred pipe its no bueno :^)

>>475181
I don't know why people keep saying this. That's not how instanced geometry works. Like, at all.

>>475538
Actually, yes it is you dunce. How instancing works is that you have a single version of the object in memory, and each instance is simply a xyz coordinate with rotation/scale values and an identifier for which object in memory it is an instance of. Each of these instance points will read from the same memory location, which is why instancing is so much more efficient than duplicate geometry, and is why we can have tens of thousands of foliage objects in modern games without much issue. All the instances will also share the same draw call as they are on the same material.

>>475541
Wrong, you dunce. You have instanced geometry for "foliage" in "modern" games and what does it end up looking like? Shit. It ends up looking like fucking the witcher 3 and ue4 kite demo. Just a bunch of folded planes waving in the wind, just generally looking like shit.

>and each instance is simply a xyz coordinate with rotation/scale values and an identifier for which object in memory it is an instance of
this is called an arbitary matrix, and not "rotation/scale values".

>All the instances will also share the same draw call as they are on the same material
There is no such thing as "material". There is a shader program. A call to draw isnt the same as a call to "change shader program" you dunce.

>>475542
What does how shitty the foliage looks have to do with instanced geo?

All games use alpha planes for foliage, what's your brilliant solution to that?

>>475545
>All games do X

>>475548
Well they either don't use them at all or they use them. They never make each blade of grass from scratch.

>>475549
>they
>they

>>475542
>You have instanced geometry for "foliage" in "modern" games and what does it end up looking like?
So what? That's not the argument.
The argument is that instancing works by having
>the extra copies take very little extra processing power.
Which is still not%100 correct...I'll explain below.

>this is called an arbitary matrix, and not "rotation/scale values".
so what? Still doesn't change the argument.

>There is no such thing as "material".
WHAT?!??!!?

>There is a shader program.
a MATERIAL is a shader tweaked and named for categorization by humans.
>The leather material uses this shader
>Now we want another colored leather. Duplicate the first mat, tweak the color, now we got 2 MATERIALS. Same shader, 2 different materials.

>A call to draw isnt the same as a call to "change shader program" you dunce.
The shader is made of maps. Each map is a draw call.
With PBR rendering the amount of draw calls is 4 per material/shader because they're composed of the normal map, albedo map, roughness map, metalness map. 4 maps = 4 draw calls.

So instancing is still more MEMORY efficient than duplicating the geo because the same mesh is being instanced, and using the same materials.
-HOWEVER, it's not a magical solution because polycount still has to be taken into consideration. NOT because the engine can't handle it, but because poor fag anon has a computer/mobile device that can't run the game. THE GPU STILL HAS TO PROCESS all the polies on screen. I made this mistake when I thought I can create a game where a castle was built out of one cube/brick that was simply instanced. Tried to run it and I couldn't. Noob mistake, but now I know better.

>All games use alpha planes for foliage, what's your brilliant solution to that?
Maybe mobile games and pre 2006 games, and even then it's minal foliage.
I never played the witcher, but speedtree has had the foliage monopoly cornered since its use in oblivion put on the map.(for most high end games)

>>475567
>The shader is made of maps. Each map is a draw call.
>With PBR rendering the amount of draw calls is 4 per material/shader because they're composed of the normal map, albedo map, roughness map, metalness map. 4 maps = 4 draw calls.
Wrong. a drawcall differs from amount of times you call a texture() function within a shader program. I can tell you haven't been doing this long.

>>475567
Speed tree's leaves use alpha planes you dipstick

>>475573
He never said they didn't, dipstick.

i cringe at non optimized scenes. I hate it when people think this is a great feature when in fact its not professional at all

>>475722
How optimized do you want?

>>475161
Alright. You will still need to optimize your level mesh.

Although remember some artists don't actually bother as they claim it's a waste of time.

>>475722
I agree... You can argue that it's not necessary because modern GPUs are so fast and modern engines are so smart, but unless your game runs at a constant 120 FPS without *ever* dropping one frame to 119 FPS, then I'll still do it. And, if your game does run at a constant 120 FPS all the time, then you aren't doing enough. You should use that extra power to make the visuals better. I guess the better way to say it is:

Unless your game is 100% photorealistic at 4K resolution and 120 FPS, then you should optimize your geometry.

>>475799
Would that demand hold up in 1999

I don't think that demand holds up now, there's more to a scene than "geometry"

More geo = more surface detail and less Jaggies. Less Jaggies = more real

Pick one.

>>475806
>More geo = more surface detail and less Jaggies. Less Jaggies = more real

You've just identified yourself as a noob to 3D. Smoother surface curvatures from higher polycounts to not decrease jaggies. Jaggies are a result of rendering at a sample rate of 1 sample per pixel. When you use anti-aliasing techniques that aren't post-process based, they force the engine to do sub-pixel sampling of these surfaces so that each pixel is an average of the sub-pixel samples, resulting in cleaner looking edges/curvatures the denser your sub-pixel sampling is. Most techniques do some edge detection (and even alpha edges with some) and try to only focus on those areas to increase performance, like MSAA. Supersampling will simply rendering the whole render target at a higher resolution and downscale it to your screen resolution, which by far looks the best, but performs the worst for obvious reasons.

>>475814
jagged edged geo, my bad. I know what a fucking Jaggie is, it's aliasing.