(January 2021) Monthly WIP Screenshot Thread

Controlling a JmE car using PI4 GPIO/Jotstick module by the help of MCP3008 ADC microchip , it was the end week self-training project model after studying some digital electronics , hope you like it , currently i have no idea about any IoT project with jme outthere , if you have let me know. :smile:

Video :slight_smile:

EDIT : At first the car starts to twist quickly , because I was accidentally touching the VRx & VRy jumper heads so there were involuntary pulses :sweat_smile:

Console Logs :

Details on GitHub page(a library to control the vehicle or charachtercontrol through joystick module & MCP3008):

10 Likes

I’ve experienced some performance issues when trying to record CrossCode with OBS on my low-powered Linux machine. I don’t think it is an isolated incident.
Are you using hardware recorders on your machine, @pspeed? I would think that would reduce overhead.

It’s true that if you have an older/lower-powered GPU that doesn’t support hardware encoding that it would be slower. But I also output as mkv and do the final mp4 encoding when I’m done recording.

My point is that it warrants investigation. On all of my various machines here, I was eventually able to find OBS settings that were acceptable. On only one computer was it relatively fine out of the box. Maybe someone should start a thread about OBS settings.

Yes, I too had to view a couple of tutorials to set up OBS studio to correct lag, dropped frames and stuttering.
I agree with you @pspeed, that a thread about OBS settings would help many newbies like me.
Regarding the low fps, I did a test without having OBS studio running.
The result was:

  • ~30 fps with filters
  • ~60 fps without filters

I am not yet very familiar with the use of filters, I understand that they significantly affect the fps.
Below is the setting of the startup parameters and the filters I used.

    public static void main(String[] args) {
        //Get the Resolution of the main/default display
        GraphicsDevice device = GraphicsEnvironment.getLocalGraphicsEnvironment().getDefaultScreenDevice();
        DisplayMode display = device.getDisplayMode();
        
        AppSettings settings = new AppSettings(true);
        settings.setResolution(1280, 720);
        settings.setBitsPerPixel(display.getBitDepth());
        settings.setFrequency(display.getRefreshRate());
        settings.setSamples(4);
        settings.setVSync(true);
        settings.setGammaCorrection(true);
        settings.setUseJoysticks(true);

        Test_DeadEyeControl app = new Test_DeadEyeControl();
        app.setSettings(settings);
        app.setShowSettings(false);
        app.setPauseOnLostFocus(false);
        app.start();
    }
        AmbientLight ambient = new AmbientLight();
        ambient.setColor(ColorRGBA.White.mult(0.3f));
        rootNode.addLight(ambient);

        DirectionalLight sun = new DirectionalLight();
        sun.setDirection((new Vector3f(-1f, -1f, -1f)).normalizeLocal());
        sun.setColor(ColorRGBA.White.mult(0.6f));
        rootNode.addLight(sun);

        DirectionalLightShadowFilter dlsf = new DirectionalLightShadowFilter(assetManager, 4096, 2);
        dlsf.setLight(sun);
        dlsf.setShadowIntensity(0.4f);
        dlsf.setShadowZExtend(256);
        
        SSAOFilter ssao = new SSAOFilter(5f, 10f, 0.8f, 0.70f);
        FXAAFilter fxaa = new FXAAFilter();
        ColorOverlayFilter colorOverlay = new ColorOverlayFilter();
        
        fpp = new FilterPostProcessor(assetManager);
        fpp.addFilter(ssao);
        fpp.addFilter(dlsf);
        fpp.addFilter(fxaa);
        fpp.addFilter(colorOverlay);
        
        viewPort.addProcessor(fpp);

maybe low-end hardware?

im using many filters and can easly run at max 60 fps with a lot of tris.

so also maybe its about animations that change 1 milion tris each frame? (myself i try do not exceed 20k tris per full-equipped character)

also worth to check if ColorOverlayFilter somehow might cause too much fps drop.

1 Like

Try commenting out the different filters one at a time to see which one is being a pig. I know SSAO with the right settings can slow things down, too.

1 Like

Also, don’t forget about DetailedProfilerState when trying to troubleshoot fps issues.
It will show you exactly where the cpu and gpu impacts of everything being rendered are, including post processing effects and filters.

5 Likes

Thank you all for the great advice. Below is the data I extracted:

  • the data of my pc not very powerful. Maybe a dedicated graphics card would help a lot :laughing:

pc-settings

  • the 3d models of the characters are composed of 55,320 triangles.
    There are a maximum of 7 characters in the scene at the same time.

  • Using the DetailedProfilerState it emerged that the filters are the ones taking more ms as shown in the two screenshots with the filters all on / off.

All on: 30 fps

All off: 60 fps

It appears that the SSAO filter takes longer to process than the others.

2 Likes

If you don’t have a dedicated graphics card, I think that’s the source of your issues. Integrated GPUs have come a long ways, but they’re still well behind dedicated chips. Filters do everything in screen space, meaning that they’re run for every pixel - that can place a lot of strain on an integrated GPU. You might try taking a look at the SSAO filter parameters and see if you can tweak them to trade off quality for speed (I don’t know enough about the SSAO internals to know if you can do that or not, but many effects can be tweaked to trade between quality and performance).

2 Likes

Thanks @danielp , for the moment I have to be content. :smile:
Thanks to everyone anyway for the advice, they were very useful to me.

2 Likes

By the way with ssaoFilter.setApproximateNormals(true) approximation will be 50% faster

8 Likes

just noticed that i use it myself. hehe

This morning I decided I would try my hand at writing a vulkan rendering pipeline from scratch.
Seven and a half hours later: single stage pipeline with one framebuffer drawing a triangle using a vertex/fragment glsl shader compiled at runtime, all using lwjgl.

When people say that vulkan is verbose, that is an understatement, this was ~1750 lines of code, not counting the shader.

My pipeline is currently only setup to use this single shader, next task is getting other shaders loaded, and figuring out how to render multiple objects in my command buffer. Wow, vulkan is complicated, but it is cool. The validation layers tell you exactly what and when is broken.

Not jme related, but still cool.

12 Likes

Brand new area. Fresh out of the oven.

7 Likes

This reminds me of posting a video - The last month (or two actually), I also jumped on the Vulkan train to see how far I would get with writing a jME-like engine in Vulkan.

I present to you: IceTeaEngine
(and sorry for the video settings, I recently messed up my OBS - The source is in 1080p without being blurry)

The engine currently features:

  • An application class giving you the possibility to customize init+update
  • A SceneGraph (Node, Spatial, Geometry, etc.) (that can be modified at runtime)
  • Controls to attach to scene graph elements for custom behaviour
  • Camera customization (FoV, loation, rotation, etc.)
  • Obviously Vertex + Fragment Shaders
  • But also Geometry + Tesselation + Computation Shaders (i.e. used for the sample water)
  • Lights (SpotLight, DirectionalLight for now)
  • Shadows (via ShadowMap, but only simple, not cascaded yet)
  • An abstraction of “rendering” & “computation” jobs and a way to chain them and use each others outputs
  • PostProcessing filters (for now Sepia + RadialBlur)
  • Custom Material Parameters
  • A very very very very very basic form of shader nodes
  • A few sample meshes (Quad, Grid, etc.)
  • Model Import (OBJ and GLTF (but not fully featured yet, e.g. animations are not supported yet))
  • Keyboard Input
  • Resizing the window at runtime
  • Building an executable jar
  • Cool waterrrrr (as actual tesselated mesh instead of a post processing effect, if anyone is interested I can link the paper)

Ultimately, it would be really cool to setup a community effort in this direction. But it would honestly be too much in such an early stage - With pretty much every feature I added, I learned something new about Vulkan, which led to me refactoring the whole rest with better ideas. And since I am a bit paranoid of people forking stuff and then demanding support, I haven’t really posted about this project yet´´ But in the end, it’s still open source, I just would like to refine it a bit more before taking the next steps of discussing code with whoever is interested and maybe even collaboration. My current plan is to improve everything a little bit more (e.g. I envisioned a core+samples library and I already have the project setup that way, but then I packed everything in core because of laziness). Who knows, if the next step of jME (in version 4 or whatever) is Vulkan anyways, this might be a very good base (even if its just for knowhow) of how to do stuff. But obviously that would be a very very long road that’s still to go.

… and I should fix my OBS settings :frowning:

13 Likes


Improved the PBR material of the mobile terminal. The following is the rendering between MobilePBR and StandardPBR. On the left is MobilePBR, and on the right is StandardPBR.

9 Likes

like you said, without support for more features+[maintaince of them] its only like demo engine.

Only if many of current devs would like to work on moving some of your work to new JME major version, it might make sense. But it all depends on them.

Myself i rather wait for pipeline/filters update first. Vulkan might be nice, but it require much work from many people to provide similar support.(physics/SDK/shaders/filters/animations/utilities/debugging/wiki/tests/etc) (but well, im impressed how much you done already anyway)

Currently anyway 3.4 is a topic.

1 Like

I have been improving MobliePBRLighting, this is the latest result.
In the same scene, the standard PBR lighting averages 35 frame rate, and the improved Mobile lighting is at 55-60 frame rate. I used the 2018 mobile phone test. As you can see from the screenshot, MobilePBRLighting is very close to the rendering effect of PBRLighting.
PBRLighting:



MobilePBRLighting:

11 Likes

Awesome :+1:, I hope it’s available on git so , we could build a Gradle one for android studio users !

2 Likes

I’m doing a lot of testing and will update to the store when it’s finished.

2 Likes