(April 2016) Monthly WIP screenshot thread

Ups, solved. Try now!

It’s a very basic MatCap material, SSAO & 2xAA, on my crappy old rig.

I also think it’s really cool what jME can pump out.

1 Like

new stuff! Music :smiley: Enjoy!

Some sweet towny stuff.

The animated version of my last picture x)

6 Likes

Hello, Sakura Sword 2.3

7 Likes

ToneGodGUI modified to support input from joystick, keys, whatever.

Here, joystick is used (apart from when I’m filling text fields to check correct data is returned).

4 Likes

Can’t figure out how to do that in blender, but I did finish the modelling so here it is clay

It’s ‘meh’ accuracy, high enough to be recognizable and low enough so that I can about 80% or so of the ship.

5 Likes

yeah of course, that’s why I didn’t guess it …

1 Like

In-pass shadows, ambient map, HDR.

If something as simple as a teapot can be rendered that well, then imagine what a typical textured scene would look like.

19 Likes

is that open source? definitely a nice picture. definitely something that my gamers will want. why only 103 fps? :chimpanzee_smile:

Teapot Simulator 2016 - GOTY

4 Likes

Would that work with fully dynamically generated meshes? It seems like it might not because “ambient map” means (according to Google) ambient occlusion pre-generated into a texture.

Well it can be made at runtime, you just need to render the soroundings of an object onto a texture which is quite performance consuming I believe.

8 Likes

How far along are you with your implementation, since i didn’t get around to port my shadow system to material parameter overrides yet.
If it is anywhere close to useable i would like to add it to the PBR shader and help with bug fixing.

1 Like

Would you please share the project?

This code has been optimized quite significantly. The reason for the low FPS is because I turned on antialiasing and bloom filter. Also this is running on an Intel card.

It is an ambient occlusion map so the lighting can change but not static objects in the scene. Depending on how you generate your meshes you might be able to compute AO dynamically. E.g. for voxel worlds you can compute AO per block.

For now I just have it working with directional lights, a la PSSM.

The idea is to have support for in-pass shadows in the engine, given that rendering shadows in a post-pass doesn’t look good. So at some point this is going to go in.

4 Likes

Hi guys, this month was interesting: in many ways I am behind my goals(especially in code quality), but at least I mostly got the feature set I wanted for my self-determined release date.

So let me announce SkyHussars R4:

The new features:
Windows exe generation is back. Release is available in both sh/bat format and exe.
Positional audio update: sounds are better positioned, however attenuation and reference distance is still not right.
Logging into file.
Planes are loaded from files from the planes directory in the assets. Only basic attributes are loaded so far.
Experimenting with parallelization.
Main menu update: number of enemies, plane type and hour of day are selectable.
Exit menu. Esc will show up a menu, it won’t drop the player immediately to the desktop.

Release at:

3 Likes

Will this contain something built-in to autogenerate the AO or will that have to be done by the user? Also, if it needs to be done by the user, will it be problematic if the dynamic meshes have significant texture reuse with an atlas (ie. the same texture is used in different places where the lighting conditions are different)?

Also, how will this work with objects that are constantly moving (ie. players, vehicles).

Sorry if I wasn’t clear, but baked AO required the scene to be static, however the lighting environment can vary. Meaning you can blow out lightbulbs, bring a torch, move the sun, etc, but you cannot change the scene itself. Objects that can move will need to be excluded from the baked AO. Generally I think having AO on the non-destructable parts of the scene, like floor, walls, ceiling, etc is enough.

Of course there’s always the option of using SSAO instead but in my opinion it looks bad and requires a lot of GPU power to compute. I think using baked AO on the static parts of the scene is a good tradeoff as opposed to not using any AO at all.

Would it be possible to use both baked AO and SSAO at the same time? What about simply darkening the areas near edges or verticies? I doubt that would be too expensive or need to be tied to anything in particular. Also, about how long does the AO computation take if it is done via multiple CPu cores as it may be doable at runtime on some higher-end computers?

I am trying to think about how it could be applied to a Minecraft-type game.