(November 2021) Monthly WIP Screenshot Thread

@pspeed That is looking awesome! I believe that you are using batching, but how many geometries and vertices do you end up with?

1 Like

Here is an image with the JME stats turned on:
https://i.imgur.com/5C1DtVG.png

The way the far terrain is configured at the moment that will be thee of the objects and a couple million of the triangles. (I can reduce the quality as needed and cut it in half with little discernible difference in quality except when moving… and also right now it’s rendering the terrain behind us, too because it’s one giant ring that is not split up.)

The block terrain includes the near trees and are in 32x32x32 chunks but mostly this terrain has one chunk per 32x32 map area except where trees/hills cross a chunk boundary.

The far LOD trees are shader-billboarded quads in batches of 1024x1024 area tiles. There are at any given time 5x5 of these tiles.

Edit: to save some clicking:
image

7 Likes

I’m quite surprised by your (M) and (F) stat numbers for the Textures and Shaders.
How to explain than 31 textures are used by objects in the current frame while only having 1 texture in the opengl memory ? (Same for shaders).
Usually my F stat is <= M.

It seems I’m missing something…

I can’t explain those numbers and they’ve barely ever made any sense to me. Especially the (m) number.

I know (F) is supposed to be the number of shaders in the frame (keeping that down is good) and (S) is supposed to be shader switches… also good to keep down.

I suspect (M) is a garbage value. There is definitely more than one shader, after all. Perhaps the stats are displayed after the value is cleared.

I guess @vxel you have your stats always visible while @pspeed you maybe toggle them off in your simpleInitApp? Unfortunately toggling them off internally disables the renderers statistics and thus nothing that happens while the stats view is hidden will be tracked and since (M) refers to the objects in memory which is not checked each frame, but only incremented / decremented upon creation / destruction, those objects will be missing when turning the stats view back on. So when always turned on then M should always be greater than or equal to F

Also i guess @pspeed does not use the built-in comparator but instead uses a custom one with the sideeffect of more switches per frame which is why the (S) are rather high compared to the (F) stats. Its a pity anyways how jme handles textures, the scene could easily be rendered with 0 texture switches independent on the geometry comparator used

2 Likes

So, I’ve been working on volumetric lights for foggy scenes. Performance has been cranked up quite a lot, so I am able to render an arbitrary number of volumetric lights. Yes, volumetric lights!

Screenshots below are for 500 meters visibility.

Before: Notice how dark the lights become with increasing distance. This is really a problem at night, because the lights are way too dark to make it feel real.

After: Yep, this is how it looks in reality.

12 Likes

I do leave the stats switched off by default as I’m not interested in them yet and it keeps me from forgetting to turn them off before that perfect “beauty shot”.

JME sorts the opaque buffer by shader ID first and then front to back distance second. There are at least four compiled shaders in the “block area” of that screen shot: bark, top-bark, side grass, top grass. So there will be at least four texture switches there.

…but the transparent bucket has sorting back to front else transparency won’t work. Shader ID is only used if there is a tie for distance. Since the leaf blocks are transparent then there will be a lot of shader switching for those. Essentially each chunk will render back to front and then cycle through each shader/texture.

There is so far only one texture+material for the far trees… they are also in the transparent bucket.

There are six texture tied up in the far terrain. Very far, far, and 2x2 grid for the ‘nearest’ low detail terrain. These will be across 3 different materials that will be a different SID because they have different constants compiled in. (and actually if you include the water then that’s 6 more textures, 3 different materials with different SIDs.)

It would not be possible to render this scene with zero texture switches.

1 Like

I was not trying to be aggressive, I was just trying to make sense of the stats that “barely ever made any sense to [you]”

Which is why i said “its a pity anyways how jme handles textures”
Texture switches have nothing to do with shader switches only due to how jme handles them. Also the hardcoded limit of 16 texture units has little to do with OpenGL (it just simplifies things) because OpenGL has a global and a per stage limit and assuming your hardware is not literally from 2005 just looking at the “Textures (F) = 31” tells me i can still claim its a pity how jme handles textures and the scene could easily be rendered with 0 texture switches

Before the month ends I want to sneak some screenshots here.
During November I participated in the E1M1 Jam #2 to make a retro shooter.

My entry is Omega Syndicate:

Imgur
Imgur
Imgur
Imgur
Imgur
Imgur
Imgur
Imgur
Imgur

14 Likes