(October 2020) Monthly WIP Screenshot Thread

It’s new IGUI : a minimalistic immediate gui for jme

2 Likes

More progress on the MOSS prototype. Light propagation, smooth lighting, lighting on the far terrain, etc…

Here is a quickly put together video:

…I should have done it at 1080 but I was in a hurry. Also whatever render target I picked really messed with the dark colors. I think it gets the point across, though.

Functionality is all there. Time to work on the next thing. The ‘real engine’ can be the victim of the endless tweaking I will need to make it look like I want it. :slight_smile:

Edit: at around the five minute mark I fast forward to sunset and then fly towards a far city at like 7 minutes. That’s where the far lighting really ‘shines’ (har-de-har-har).

19 Likes

Nice.

I did notice that between 7:05 and 7:13 ish, the far half of the city lights ‘skitter’ a lot.

Looks like only a subset of the lights are actually affecting the lighting, and which subset varies with view angle, or perhaps they are reflections off of nearby cube faces, and the angles at which that reflection is visible end up constrained at lower LOD.

Not sure if this is:

  • intentional
  • inevitable due to your pipeline
  • something you hadn’t noticed yet

@pspeed impressive.
I noticed that there is a short freeze at 1:16 in the video, i had similar freezes when i tried building my minecraft clone a few years back, and assume they were caused by the same underlying issue. Sadly i never got around to debug it.
Do you know what the problem might be? My uninformed guess would be a GC pause?

there is also case that GPU might freeze on wrong calculation(for example bad normals/tangents/etc when using parallax) that i also had recently. need care for proper shader values.

Thanks for the interest, guys.

To address some things:
The “skittering” from 7:00-7:15 is because that far lighting is just the stuff on the terrain and the buildings haven’t shown up yet. So it has a very tiny pixel fingerprint but we are flying at 40 m/sec. It’s like twinkling stars. (Also note: since the far buildings haven’t faded in yet it means this is more than 3km away.)

As for the ‘direction’ thing, I’m not exactly sure what you mean. Whatever the case, all of that part is calculated at runtime from combining the sunlight contribution with the local light contribution. It’s possible that this equation in the frag shader is still not exactly right. This is in no way the actual shader I will use (it doesn’t even do textures)… so maybe that will get fixed. It’s also possible that it’s related to the real bad video quality.

As to the slow down, it happens right at a 32 meter transition which was right after another 32 meter transition:
image

ie: we just crossed over x=512 and then we crossed over z=32. Since I don’t break out the queue stats by job done (yet), what I imagine happened is that crossing the 512 boundary started loading a terrain tile and set of far terrain tiles then along with some local ‘chunks’ in X and then Z. It doesn’t seem to be GC.

Right before that: image

There are 4 worker threads plus the render thread (and actually there is a separate high priority worker thread). This is a 6 core box running OBS at the time.

Given the memory display, I don’t think it’s GC related.

To be honest, I haven’t done any work tracking down frame drops yet. They happen rarely enough that I can test the tech and I already know there are some hard synchronize() blocks in the world database code that will have to be factored out later.

I take solace in a few facts:

  1. they are relatively rare
  2. on the whole we are traveling faster than a player ever normally would. (We never travel below 10 m/sec… which at best would be riding on a mount.) Even in the parts we are traveling at 40 m/sec, the chunk loading is mostly keeping up… which is still better than Mythruna would do at that speed.

I’m confident that I can fix those kinds of issues because I have already done that stuff before. The main point of this prototype is to figure out if I can do the “impossible” things… like show a lit block world town from 2 km away. Or that lit castle on the mountain from just as far.

Honestly, I thought none of this would work and I’m pretty pleased. I haven’t even gotten to making it look pretty yet.

8 Likes

Thank you. :+1:

Let me see if I can explain this better:

I was imagining that a shader might perhaps only be calculating the lighting correctly if being viewed within a certain angle of of ‘normal.’ Add this to a highly faceted geometry, such as cubes, and you might get an effect similar to watching the facets on a disco ball.

At that point, that portion of the city seems to be in the mid-distance, so IIUC, the cube geometry is loaded rather than the smoothed long-distance terrain?

I don’t know. The “proper rendering” is not something I’m really worried about yet as long as the visualization shows that the tech is working, ie: accuracy of the local light values versus sun values. I can see that even if the rendering is wonky. I make it look pretty enough so that I stay motivated but I’m also very cautious not to fall into the old Mythruna trap of spending 8 hours tweaking the color of fire.

It’s also hard to tell what’s video artifacts and what isn’t. For example, near the beginning of the video we can see grades of dark colors crawl in waves across the black terrain as the sun rises… that’s essentially not visible in the actual running application.

Edit:

It is pleasing that the transition is nice enough now that we can’t ever be 100% sure where the line is. :slight_smile: I mean, I always know because my eyes are trained to see it but generally only when I stop and look for it.

2 Likes

OK, today I finally sat down and did a experiment that I have been wanting to do for some time.
This is JavaFx 15 inside of jme3.3 inside of Javafx 15.

The ‘Click Me’ button is a jfx button in the jme gui node. The jme canvas is inside of a jfx window.

This is an important proof of concept, as the only way to get jfx ui working in jme in android is to put jme inside of jfx. My next step is to run this demo in android.

10 Likes

sounds crazy, but glad it works :smiley:

For this, you may need to deal with native-images.

Do not want to go offtopic, so just sharing here a quick link to an article that you might find useful.

https://medium.com/graalvm/introducing-the-tracing-agent-simplifying-graalvm-native-image-configuration-c3b56c486271

9.5/10 needs more javafx .
Jokes aside. Do you use sub texture updates to update only the dirty rects or do you refresh the whole screen everytime it needs to be updated?

1 Like

@tlf30 Great ! I was seeking for an experiment like that , can I know how you did it ?

I will upload the test project tomorrow after I isolate it from the rest of my jme test. I am about to eat dinner now.

1 Like

Working on a special effect for a spell called ‘Entangling Roots’ that snares the enemy in place.

I also included a short clip at the end showing how I animated the roots in blender, using a fairly simple tentacle shaped geometry with 3 bones. Then i copy pasted the initial one (with some minor adjustments to each new one) until it started to look like a bunch of roots coming up out of the ground.

10 Likes

Here is the repo for the jfx-in-jme-in-jfx:

1 Like

Did you mean that for the other thread?

Edit:

No, this is the repo for the screenshot that I posted above. The source was requested.

1 Like

So, I’ve been polishing my game development skills in Java. I believe I’ll be the person to create the Java/Vulkan game engine of the next generation we all need. Not bragging, just what I intend on doing.

This requires me to learn how to create a basic collision detection library.

What’s in the picture.

  • JavaFX window which is capable of handling keyboard input.
  • The java FX window is also running a game loop.
  • A sphere which will be turned into a capsule for character collision detection.
2 Likes