(October 2018) Monthly WIP & Screenshot thread

I welcome any constructive feedback. However, the API is still unstable.
I’ll issue a call for testers once the API settles down.

Nice work @sgold
Last time I tried KinematicRagdollControl result looked so buggy, with DynamicAnimControl it looks much better now.

Thanks for your contribution.

1 Like

Trying out various isosurface generators, not quite the result i’d hoped really. I kinda wanted somewhere near a good third in reduction. Total saving: a whopping 1362 verts for a 128x128x128 chunk - in all the data I found it promised a bigger reduction than that. I guess it shows that proof overpowers whatever you want to believe. Results are pretty much blanket for any dataset :confused:

Marching Cubes: 34,860 verts
SurfaceNets: 33,498 verts

MarchingCubes

SurfaceNets

5 Likes

And depending on whether those flat areas should be flat or not… one of these is not as good as the other.

yup, exactly same dataset, the “flat” area is just:

if (loc.y <= 1) {
    return 1.0f;
}

to give it a floor instead of an empty hole. I don’t understand how the algorythm works entirely, I just converted it from javascript, so I don’t really understand that either tbh… It’s definitely not just bad normal data, there are genuine movements in the mesh. Pff. Enough for one day…

I was always felt like marching cubes was ripe for some post-processing to reduce triangles… certainly for farther away chunks but even for near chunks. I felt like the general overall regularity of the subdivisions along cube boundaries should make it easy to join shapes.

…but even still, for flat areas I would think there must be something to reduce polys.

GPU gems describes increasing the block size as opposed to actual LOD, or scaling for want of a better description. It does work, but you end up with small chunks surrounded by ever growing sized ones, and although I haven’t put it into practice (I got sidetracked with alternate methods) it seems that the overhead of generating them might make the load-time pretty bad. I’ll have to do a practical before I can say for definite… This is the mock-up I made to work from. If I move outside my dead zone imagine how much data I’d have to gen. I feel like apologizing to my CPU :confused:

        /*

            The four "center" squares in our setup are going to be our "dead zone".
            Only when we move out of the dead zone do we update our scene.

            +----------------+-------------------+------------------+----------------+
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            +----------------+---------+---------+---------+--------+----------------+
            |                |         |         |         |        |                |
            |                |         |         |         |        |                |
            |                |         |         |         |        |                |
            |                +---------+----+----+----+----+--------+                |
            |                |         |    |    |    |    |        |                |
            |                |         +----+----+----+----+        |                |
            |                |         |    | DZ | DZ |    |        |                |
            |----------------+---------+----+----+----+----+--------+----------------+
            |                |         |    | DZ | DZ |    |        |                |
            |                |         +----+----+----+----+        |                |
            |                |         |    |    |    |    |        |                |
            |                +---------+----+----+----+----+--------+                |
            |                |         |         |         |        |                |
            |                |         |         |         |        |                |
            |                |         |         |         |        |                |
            +----------------+---------+---------+---------+--------+----------------+
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            |                |                   |                  |                |
            +----------------+-------------------+------------------+----------------+

         */

This topic may deserve its own thread.

In my experience, the GPU gems approach only works well with fairly regular terrain… and even then not great. You can also tweak a bit the surfacing threshold but that also comes with some artifacts.

But one of the things I always wanted to look into was just getting rid of the nearly degenerate triangles for a mid-range LOD. There are already reasonably easy to detect during the generation phase because they are close to edges/corners… and it feels like there are a lot of them.

For the larger flatish zones, I always wondered if during triangle emission we could collect similar surfaces like used in the greedy block meshing (similar normal + similar origin distance along normal)… then go triangles → polygon → simpler triangles. Trick is doing it fast enough and without blowing out memory… which is already kind of an issue for this algorithm anyway.

Known issue - streamable blocks embedding videos using the “standard” URL, which is what the one-boxer sees. It probably plays a few times before it realizes that it’s getting multiple hits from a web-server.

1 Like

I’m working on duplicating (sort of) the character control features using drivers in the SiO2 bullet integration. I know of at least one person that was struggling with this and I will need something similar for mphys as well and the ideas should be mostly transferable.

So to facilitate this, I’ve started creating a demo environment:

The dark blue objects are moving platforms and the dark gray strip is a sort of conveyor belt.

Jaime can run around with basic physics forces (just barely)… I haven’t really gotten to the real driver implementation yet. I’ve just put in enough to test other things. How forces are applied in the context of kinematic platforms was an important consideration so I was trying to get as much of that odd platformer stuff into the demo.

Right now I’m working on the locked third person camera but I also hope to do a more free-look contextual based third person camera like in “insert most action games here”. First person camera is the easiest case so I’m not worrying too much about it.

I’ve also been reading a lot of articles on platformer jump physics and stuff… hopefully something good and tweakable comes out of all of this but frankly I was just happy to have moving kinematic platforms that Jaime could walk onto and ride. :slight_smile:

13 Likes

I am using a combination of Lemur and jmejfx for the UI for my game and needed to embed JavaFX components into a Lemur element so I created a JFXAnchorPane Lemur component that embeds a JFX Anchor Pane and all it’s contents into a Lemur Panel. The code is available in this thread → I created a Lemur element that displays a JFX panel

image

7 Likes

Been toying around with post-processing meshes… Havent solved the normals yet but seem to be getting somewhere at least.

It’s surprisingly fast.

Simplify: 10552 / 21108 50% removed in 132 ms
Simplify: 10554 / 21108 50% removed in 100 ms
Simplify: 5276 / 21108 75% removed in 50 ms
Simplify: 9498 / 21108 55% removed in 54 ms
Simplify: 3166 / 21108 85% removed in 45 ms
Simplify: 5276 / 21108 75% removed in 53 ms
Simplify: 5276 / 21108 75% removed in 91 ms
Simplify: 7387 / 21108 65% removed in 41 ms
Simplify: 10553 / 21108 50% removed in 41 ms
Simplify: 10554 / 21108 50% removed in 34 ms
Simplify: 7384 / 21108 65% removed in 38 ms
Simplify: 5276 / 21108 75% removed in 53 ms

Takes a run or three to get the old VM warmed up but it’s within the acceptable range I guess.

11 Likes

… and then it hit me, add texture coords to geometry shader grass blades, daaaah :

20 Likes

That is the dopest grass ever for that framerate.

But I do have to ask…

…is that how it works? :stuck_out_tongue:

yep. That framerate is meh, 720p @ 4x MSAA on a GTX 470. Instancing will help down the line.

I think that comment was in reference to a different use case. I want very clean close up toony grass detail, so: mesh → triangles → 10 random points w/ clusters of 5 points → geom shader uses those 5 points as origins for 5 ‘blades’ of 7 tri’s each that are randomly offset, rotated and scaled.

Working backwards, I wanted grass clumps of 5 blades, randomly scattered across a mesh.

2 Likes

Procedurally generated level (Terrain + Landscape) using Binary Space Partitioning (BSP) method.

Still WIP…

13 Likes

Finally managed to release something which can be called multiplayer “pvp mode” in game menu (screenshot are from old release) . Because of firebase you need put some email and password which does not have to be real one (I have to figure out something more intuitive). Unfortunately there is still poor gameplay and need to put some mobs when there is no one connected to server. Other features are just scrap before i found out zay-es and SimEthereal

(p.s. bug: close the app after initial log in and start it again)

1 Like

LOL you know it’s called “*& Screenshots thread” for a reason :stuck_out_tongue_winking_eye:
looking forward to trying it when it’s released :wink:

It is released I m currently logged in.

You can’t really see it because there’s nothing to show any kind of scale, but it’s basically a 49x49 grid of chunks (2401 in total) at an acceptable frame-rate. Previously I’d only managed to use maybe a 8x8. The LOD system @pspeed encouraged me to work on really threw me on its effectiveness. The mid chunks are using 20% of the verts, and far chunks only using 10%.

The second image below shows how well the mesh simplification works, with the right-side only having 10% of the verts of the left side - and joins perfectly (hence the fanning on the edges).

Very pleased indeed! Thanks for the tip, paul :slight_smile:

15 Likes