Work In Progress / [LOCKED] The Cogwheel Chronicles: Volume 1 Mechastica

Author
Message
lorddweeb
7
Years of Service
User Offline
Joined: 22nd Feb 2017
Location:
Posted: 6th Nov 2018 03:18
Love that submarine and the character model.
PM
DVader
20
Years of Service
User Offline
Joined: 28th Jan 2004
Location:
Posted: 16th Nov 2018 16:52
This is coming along nicely Awesome stuff! I love some of the shader effects here and the style is looking nice. Your characters look great as well.

I would slow the main player down a tad, as he seems to slide along the floor at the moment (unless you have fixed that now), or of course, speed up the anim to match the current speed. Changing the players speed would probably be the easiest way to get the walk anim looking correct. It just needs reducing slightly imo.

Great work!
SPECS: Ryzen 1700 CPU. Nvidia 970GTX. 16 Gig Memory. Win 10.
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 27th Jan 2019 01:45 Edited at: 27th Jan 2019 02:29
Thanks guys for the encouragement.

Masses amount of progress has been made with Cogwheel over the last few months, some of the engine changes to support the game are illustrated below by associated new lua commands:

SetSkyOptions(mode,skytime,rotateandlight)
--mode = 0/no change, 1/off, 2/sky as local time, 3/sky as skytime(input)
--skytime = decimal hours (e.g. 14.5 is 2.30pm), only used when mode = 3
--rotateandlight = 0/no rotate or light calcs, 1/rotate only, 2/light calcs only, 3/rotate and light
--so SetSkyOptions(2,0,3) sets sky dome/boxes to local time and rotates sky as local time progresses and also adjusts sun factor lighting

SetAllMeshLightsOnOff(1)
-- allows all mesh lights to be turned on or off together, saves performance, lights only used at night or indoors

ChangeTerrainAndPosition(OffsetX,OffsetY,OffsetZ,"example.fpm")
-- allows in game change of full terrain, can be positioned anywhere, created to allow terrain islands to load without new level shenanigans being needed. Huge amount of change for this one to allow shadows to work properly and player to move anywhere in open world

CreateExplosion(explosionX,explosionY,explosionZ,explosionSpriteSheet,smokeSpriteSheet,lightFlag,smokeSize,sparksCount,sparksSize,explosionSize,explosionDamage,explosionRadius,soundID,sourceEntity,spriteRows,spriteCols)
-- allows any type (row,column) sprite sheet to be used for explosions, created anywhere required - needed this for dramatic air battle scenes.

TakeInGameScreenShot("test picture.jpg")
-- creates a screen shot and stores in bespoke mydocuments folder. Used for automated capture of killer views and quest achievements.

RaiseAndLowerTerrain(0,X,Z,Radius,Height)
-- allows in game modification of terrain height (like editor controls). Also repairs terrain collision and water mask after update.

Setup.ini - terrainsizefactor = 2
-- changing this value affects the linear size of the terrain - so set to 2 and get 4 times stock size, 3, gives 9 etc. Tested up to 10 (100 times) but get terrain tearing at very high values. Still amazing how large can go with this value. Also needed shader changes to allow the terrain textures to tile properly and watermask to work, and lots of engine change to allow the editor to address and update the larger terrain. I've settled on a factor of 2 for Cogwheel. This creates nice large islands to visit (that are loaded in game).

AddAnotherExistingEntity(e of entity to clone,X,Y,Z,AngX,AngY,AngZ)
-- creates duplicate entities on the fly in game. Used to populate trees and grass on the islands loaded in and also to generate money, food, collectables etc when needed.

DeleteExistingEntity(e)
-- counter part to AddAnotherExistingEntity, so can manage memory usage.

HighlightObject(e, type)
--Allows in game highlighting of any object where the e value is known
--type --101(red),102(pink),103(green),104(blue/green),105(gold)
-- this is coercing the editor capability for game play purposes (where hover over an entity and it changes color).
-- Used to highlight items for player to examine etc

GetFPS ()
-- used to retrieve FPS in game so that settings can be dynamically modified to help smooth out game play and keep FPS up, e.g. turn off light rays if FPS drops too far etc

ChangeToRealTimeOrBaked(v) 1 = pre-bake, 2= real-time
-- allows in game switching of lighting method. Used to switch to baked lightmaps indoors and down the mine.
-- Changed the engine light-mapper to only bake entities that have strength/health of 99. This is because I don't want outdoor entities to be baked, nor do I want to set them to dynamic as slows engine down. This allows faster bake time and also keeps the lightmaps and lightmap entity sizes to the minimum. Also update custom shaders to allow illum textures to work with lightmapped assets and for specular reflections (PBR) - blends lightmap with PBR response to dynamic light (sun or placed lights).

I'll post some screen shots soon.

Edit - just so not a wall of text





Cheers.

Attachments

Login to view attachments
Pirate Myke
Forum Support
13
Years of Service
User Offline
Joined: 31st May 2010
Location: El Dorado, California
Posted: 27th Jan 2019 14:32
Always a pleasure to see your updates.
RIP
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s), 8gb RAM, Nvidia gtx660, Windows 7 Pro 64bit, Screen resolution 1680 x 1050.

New:
Intel(R) Core(TM) i5-8400 CPU @ 2.81GHz, 12GB RAM, Nvidia gtx660, Windows 10 Home 64bit, Screen resolution 1920 x 1080. System Passmark 3774




Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 27th Jan 2019 15:45
I agree, you are always a trailblazer when it comes to new features.
synchromesh
Forum Support
10
Years of Service
User Offline
Joined: 24th Jan 2014
Location:
Posted: 28th Jan 2019 02:35
Its going to be a stunning game for sure
The only person ever to get all his work done by "Friday" was Robinson Crusoe..
PM
Bolt Action Gaming
GameGuru Tool Maker
10
Years of Service
User Offline
Joined: 24th Oct 2013
Location: Harrisburg, PA (USA)
Posted: 28th Jan 2019 18:08
So @cybernessence is this list of features something you plan on merging into the core GG engine or is it something you created just for your game?
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 28th Jan 2019 19:34
Thanks for the replies guys. I am hoping it will be something special (relatively speaking of course)

@BAG - absolutely will release to Lee to see if he wants to add any of it to the core (after I’ve got the game shipped)

Cheers.
PCS
7
Years of Service
User Offline
Joined: 7th Jul 2016
Playing:
Posted: 31st Jan 2019 18:10 Edited at: 31st Jan 2019 18:11
if i look in the setup.ini i don't see this ( terrainsizefactor = 2 )
what do i do wrong?
Windows 7 Professional 64-bit
Intel(R) Pentium(R) CPU G3260 @ 3.30GHz (2 CPUs), ~3.3GHz RAM 16GB NVIDIA GeForce GT 730
DirectX Version: DirectX 11
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 31st Jan 2019 23:50
@PCS - the changes listed are in a custom version of GG at the moment, once I've got the game released I'll put them on github to see if Lee wants to add some or any of the new features to the core for everyone.

Cheers

PCS
7
Years of Service
User Offline
Joined: 7th Jul 2016
Playing:
Posted: 2nd Feb 2019 03:57
cybernescence, thank you .
all the best for your game. still amazing work you do.
Windows 7 Professional 64-bit
Intel(R) Pentium(R) CPU G3260 @ 3.30GHz (2 CPUs), ~3.3GHz RAM 16GB NVIDIA GeForce GT 730
DirectX Version: DirectX 11
DenZelik
5
Years of Service
User Offline
Joined: 4th Sep 2018
Location: Novoaltaisk
Posted: 4th Feb 2019 01:20
Wonderful job! I am amazed at what you were able to do at GameGuru, and especially when you are amazed by the traffic. Yes, and the setting is also unusual. Good luck in your development and successfully bring the game to release! I will look forward to!
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 10th Feb 2019 23:39 Edited at: 10th Feb 2019 23:41
Thanks PCS & DenZelik

Been working on the seaplane script, can now successfully fly (fuel permitting) anywhere as it can land on sea and terrain with enough space. Got a hat-tip to 'Tales of the Gold Monkey' going on, though I know its not a Grumman Goose by any means .

It's a very responsive biplane to fly, just need to finish off the AI flying enemies now.





Cheers

Attachments

Login to view attachments
osiem80
5
Years of Service
User Offline
Joined: 24th Jan 2019
Location: Poland
Posted: 14th Feb 2019 21:51
nice, remembers me a little bit to bioshock infinite from the atmosphere, can i donwload the demo?
PM
synchromesh
Forum Support
10
Years of Service
User Offline
Joined: 24th Jan 2014
Location:
Posted: 15th Feb 2019 23:19
Quote: "can i donwload the demo?"

I wish ..
The only person ever to get all his work done by "Friday" was Robinson Crusoe..
PM
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 19th Feb 2019 20:44 Edited at: 19th Feb 2019 20:45
Doh!

Doh, doh, doh!

It was going quite well, but as I started to add more richness to the main explorable air city (and replacing place-holder assets with PBR) the level has now started to stutter.

I'd been adding and replacing only a few assets at a time with an associated test so have spotted it quickly.

Since Preben's image optimization work on the engine, I'd been using large atlas textures that are common to many assets, on the belief that unique textures are only loaded once, thereby reducing overall video memory consumed, albeit at the expense of a few large textures being loaded.

So I was surprised that stuttering had started, after digging into this with the debug facility Preben also added I realized how stupid I'd been.

For some reason (can't quite believe this now with hindsight) I'd assumed unique textures were being identified by texture name (only). Of course this isn't correct, they are being identified by path including texture name. Unfortunately I'd organised the game assets by type e.g. prop, building, railway etc. So whilst they were sharing textures these were also held in separate folders.

So I sat with head in hands wondering how on earth I could swap all these assets around - essentially remove all and then add them back from correct/new folder - hundreds of assets to do.

Quite soul destroying ... until I remembered the map.log and map.replace 'hidden feature' Lee built in.
https://www.youtube.com/watch?v=qAp6TT2oT2o

And though it has still taken 2 hours, I've got it all squared away and all the assets reorganized per texture type in new folders and all automagically updated into the fpm by way of the 'replace' function.

Since doing this, the level has gone back to being silky smooth (large drop in video memory), proving, if there were any doubt, that Preben's changes for this are extremely effective (if used the correct way) .

In other news, I've gone back to checking most major builds as standalones, and once past the tiresome build errors where images and such aren't copied over (which thankfully can be sorted for repeat builds by the .fpp technique Lee has added) have been working on updating the custom menus. I have so many options to add, but for the beta tests have landed on only a few for now (as below in the 'advanced' menu):



I also came across a bug where after saving and reloading, characters were shaded very bright. Think I have tracked this down in the engine as the non PBR character shader being reapplied to a PBR level after a reload of a level. I seem to have fixed it but am still testing.

@ osiem80 - as synchro says, nothing to download as a demo. I'm hoping a few of the veterans on this forum will help with some beta testing st some point Bioshock influences will be apparent in the player control


Right, on to the next challenge

Cheers.

Attachments

Login to view attachments
GraPhiX
Forum Support
19
Years of Service
User Offline
Joined: 15th Feb 2005
Playing:
Posted: 19th Feb 2019 20:57 Edited at: 19th Feb 2019 20:58
LOL well done with ya bug squashing this has been a long time coming I wish you the best with this and cannot wait to play a demo myself
Welcome to the real world!
Main PC - Windows 10 Pro x64 - Core i7-7700K @4.2GHz - 32GB DDR4 RAM - GeForce GTX 1060-6G 6GB - 1TB NVe SSD
Test PC - Windows 10 Pro x64 - G4400 @3.3GHz - 16GB DDR3 RAM - GeForce GTX 950 2GB - 500GB SSD
Laptop - Helios 300 Predator - i7 7700HQ - 32GB - Nvidia GTX1060 6GB - 525GB M2 - 500 SSD - 17.3" IPS LED Panel - Windows 10 Pro x64
Various Tutorials by me
Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 20th Feb 2019 19:52
Yikes! I could see myself making the same mistake though.
No idea how you are going to implement a difficulty level too! You are very resourceful. Best luck with the further development.
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 21st Feb 2019 15:53
So last night's work threw up another interesting GG feature / issue.

Continuing the work on texture optimization I wanted to see how much video memory would be consumed if I halved all of the textures in size and thought the setup.ini option "dividetexturesize" would allow me to easily do exactly that.

Except, when set to dividetexturesize=2 or dividetexturesize=4 etc, only a few of the textures seemed to change, the terrain did and some of the entities but most did not.

Well, this required more hours going through all of the many engine function 'loadobject and loadtexture' overloads, but eventually I got the changes in play so that setting dividetexturesize > 1 does reduce all the entity and terrain textures.

Interestingly this now allows me to move around the level and see what textures really don't need to be as high as they are. I I set dividetexturesize=2 and then load level and I can't really see any appreciable differences in the entity, I know I can go back and reduce the texture size for the entity itself so when I revert to dividetexturesize=1 then I know I'm saving video memory without compromising the look of the game (too much).

Also it means that this is now a real option to invoke if people start getting stuttering when playing the game.

With dividetexturesize=1, video mem consumed is c. 1.95 GB
With dividetexturesize=2, video mem is c. 1.56 GB (don't notice too much visual impact, though there is some where textures have been optimised already towards very low)
With dividetexturesize=8, video mem is c. 1.22GB (quite a large impact on some entities, others not too bad, showing I could push things further here).

My other thought on how to save video memory is that I can bind PBR textures together (like Unity and other engines can do), so for example one channel textures are combined into one texture only, e.g.

_ao (gray scale only)
_metalness (gray scale only)
_gloss (gray scale only)

So these could all be mapped to one texture, with e.g. R channel being _gloss, G channel being _metalness, B channel being _ao.

This would be time consuming to prepare the textures, though the shader code change is trivial. Think I'll just keep this up sleeve in case I need it. Preben also had a clever idea about doing this binding in the engine, so textures would stay the same, but merged at load time in engine and those then not needed discarded freeing up video memory that way. This would be a brilliant way of doing it - not sure I have the skill or time to do this myself though. Maybe

@GraPhix - thanks for the best wishes
@Wolf - thanks, luckily there are a few 'levers to pull' re difficulty such as 'stamina', 'breath hold time' (for under-water) and 'Tesla Power' (the ability to use sky-hooks from afar), weapon damage etc.

Cheers
Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 21st Feb 2019 17:40
I've been working with increasingly lower resolution textures myself lately. Its simply more efficient in a lot of cases and I made the big mistake to work with some 4k textures when I originally started my project Acythian.

The issue was that years ago, GG simply rendered god awful. Normalmaps would look off, everything seemed blurry and muddy. I think to remember the old bloom shader being to blame.
Back then I thought I'd have to combat that with higher tex resolution which has proven somewhat succesful. I was prototyping stuff at the time that mostly looked like this.
As a result, all my architectural prop now have an absurd texture resolution and need to be readressed one by one. Oh well.

What would be great would be a command to set a maximum resolution rather than a division. If we set divide texture size to 4, lower resolution textures for smaller and background objects will suffer immensly. However, if we could set a maximum texture resolution, everything above that would be scaled down to the new cap and we would have more control over the visual quality of our game. Lower resolution textures would remain unchanged. (I hope I explained that idea coherently.)

Anyway, battle on Looking forward to more!



-Wolf
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 22nd Feb 2019 22:33
That’s a great idea Wolf and does indeed work very well.

Rather than introduce a new setup.ini flag I just changed GG so that if the dividetextre flag is greater than 128 it acts as a texture cap rather than a divide by factor.

I set it to 2048 and saw immediate material texture memory savings with only slight visual degradation of some assets.

I think the only improvement might be to ignore normal maps as they appear acutely sensitive to reduction antics.

Great idea - cheers.

cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 23rd Feb 2019 23:59
So today's fun and games revolved around player sound.

I had mostly already got player character switching built, so decided I'd finish it off for the beta (I also got sick of testing with Isaac).

So I changed the standalone menu system and also added hot-key support so you can play as a male or female and switch during the game if you want to.

But then it came to player sounds / voices and I found there is no way to switch these dynamically (only by changing the soundset folder via the player start marker). Hardly surprising I suppose as it's not supposed to be a GG feature. But I couldn't have beautiful Cathodia sounding like a 20 stone bloke

So this needed another lua command in the engine, now added: ChangePlayerVoice. So as well as third person view and first person arms, the player sounds also switch. And it's a relief to now also be able to test with another character:







Oh I also added some goggles to Isaac - can't have steampunk without goggles :



Cheers.



Attachments

Login to view attachments
Pirate Myke
Forum Support
13
Years of Service
User Offline
Joined: 31st May 2010
Location: El Dorado, California
Posted: 25th Feb 2019 03:58
Very nice. Glad you got that sorted.
Great Screen shots.
RIP
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s), 8gb RAM, Nvidia gtx660, Windows 7 Pro 64bit, Screen resolution 1680 x 1050.

New:
Intel(R) Core(TM) i5-8400 CPU @ 2.81GHz, 12GB RAM, Nvidia gtx1050ti 4gb, Windows 10 Home 64bit, Screen resolution 1920 x 1080. System Passmark 3774




Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 26th Feb 2019 14:32
You actually get to choose a player character in the beginning! Its amazing what kind of functionality you can implement.
If someone would have asked me how to do that in the past I'd have sworn that its not possible.

Did you happen to modify the third person controller?
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 3rd Mar 2019 16:05 Edited at: 3rd Mar 2019 16:07
So last week has been a continuance of performance testing (GTX750Ti/I5 is going to be minimum spec without having to resort to texture and resolution reduction to get a reasonable FPS) in parallel with building out and enhancing core game level (swapping out place-holder assets for PBR).

I felt the air city just wasn't full or interesting enough, so have referenced a lot of artists steampunk work for more inspiration and concluded an air city just needs a lot more correctly themed props. So spent a few days on that, reusing the mega atlas textures where possible to ensure it's only polys I'm adding not extra texture usage.

Then I realised something was completely borked with the lighting in respect of shadows - it's amazing how I can see a set of scenes so many times and not notice things properly - definitely requires fresh/different eyes to check out this kind of thing from time to time.

Naturally this wasn't easy to fix (nothing ever is it seems) and when I eventually found the problem (using the normal map normals instead of entity normals in the shadow calcs) it then showed up that the lighting had been previously tuned with place-holder code I'd forgotten about (cue a bit of head banging on desk again).

So that made me check and re-work the custom PBR shader from the ground up - this took 10 hours or so to get things all sorted, and also I changed the engine sliders to be more honed towards PBR deployments (when pbroverride =1). There was some good news in that I spotted a bit of unused engine code to do with snapping shadows to texels, so as an experiment I enabled it and the shadows moving around the world now look a lot better (less shimmer).



I'm still getting a reasonable FPS, but am always expecting to 'hit the wall', so thought I'd check the resolution options within setup.ini back to the engine code. They didn't work. So have changed the code to allow them to work when running in standalone mode. This is now another option on release to help people get a reasonable FPS on lower end machines, and is a contingency for higher spec rigs.

Being mostly an open world adventure I've not used the 'SetOcclusion' lua command or tab tab slider (always had it set to zero as can't have popping of assets in the distance), but realised I could actually use it when the player is in buildings or in the scary mines or actually when it is pretty dark (from the day/night system), so updated the environment manager (lua code) to use this.

But of course it didn't work (properly). If this command is called continuously it causes a game play stutter every 5-10 seconds. Of course it does! So back to the engine to change the command so it only does its thing if the value changes. This now works and is squeezing more FPS out of non open world parts of the game.

Another aspect that was annoying me was that illumination / emissives were 'always on', so changed shaders so that lua can switch these on or off - so the windows of the houses and other 'lights' come on at night only and aren't glowing through the day (along with the actual lights that were already time controlled). Also made a tab tab slider to allow the intensity of the illumination maps to be controlled when on.

I have one last major bug to find (for now anyway), in that the third person controller is borking periodically and refusing to play animations.

@Wolf - yes the gameplayecontrol.lua has been largely re-written to allow character swapping, swimming etc - I also placed a lot of other code in here as a central always running place to manage game events.

Onwards and upwards ...

Cheers.

Attachments

Login to view attachments
Pirate Myke
Forum Support
13
Years of Service
User Offline
Joined: 31st May 2010
Location: El Dorado, California
Posted: 3rd Mar 2019 16:55
Wow, Wow, and Wow.
Nice fixes. I hope Lee will take into consideration the engine and shader changes you have done and can get them into the engine after you release your game.

What great progress.
RIP
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s), 8gb RAM, Nvidia gtx660, Windows 7 Pro 64bit, Screen resolution 1680 x 1050.

New:
Intel(R) Core(TM) i5-8400 CPU @ 2.81GHz, 12GB RAM, Nvidia gtx1050ti 4gb, Windows 10 Home 64bit, Screen resolution 1920 x 1080. System Passmark 3774




Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 5th Mar 2019 20:09 Edited at: 5th Mar 2019 20:13
Impressive!

I know that this might be counterintuitive to your designs, given that you can fly planes in this BUT have you tried lowering the "camera distance" and hide the very far away thingies in fog? I'm always surprised how far I can lower it without getting visible asset popping and it certainly buys you a lot of FPS.

Second: Given that you are an abolute expert at custom shading in GG, maybe you can overhaul the default postprocessing and bloom a bit? I find it eats up a lot of FPS for what it is aswell.

Odd question too: given that you can starkly modify what you have with GG. Do you ever feel like switching engine in the middle of all this? I can only imagine that it requires a lot of trial and error.

Just throwing out ideas.



-Wolf
maiacoimbra69
6
Years of Service
User Offline
Joined: 14th Sep 2017
Location: Faro
Posted: 9th Mar 2019 20:47
I am not a fan of this type of game but i must say "Respect" this is a great work , congrats
granada
Forum Support
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 13th Mar 2019 13:28
Just love following the progress of this game

Dave
Windows 10 Pro 64 bit
GeForce GTX 1050 Ti
AMD FX (tm)-9590 Eight-core Processor
31.96 GB RAM
1920x1080,60 Hz
PM
osiem80
5
Years of Service
User Offline
Joined: 24th Jan 2019
Location: Poland
Posted: 13th Mar 2019 16:37 Edited at: 13th Mar 2019 16:44
if there was a competition like "Game-Guru Game of the Year"(btw.IMO it should exist) you would win it easly!!
PM
lorddweeb
7
Years of Service
User Offline
Joined: 22nd Feb 2017
Location:
Posted: 14th Mar 2019 03:29
I'm definitely always glad to see updates on this project. It certainly seems like GG going to GIThub has opened up possibilities for you, both in terms of features and just getting the engine to behave as you'd like.
PM
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 24th Mar 2019 14:41
@ Pirate Myke - thanks for the encouragement . I'm not sure that all of the engine changes will be relevant to all GG users, but I think some will definitely be useful and give some other options for people, larger terrain sizes for example

@ Wolf -
Quote: "I know that this might be counterintuitive to your designs, given that you can fly planes in this BUT have you tried lowering the "camera distance" and hide the very far away thingies in fog? I'm always surprised how far I can lower it without getting visible asset popping and it certainly buys you a lot of FPS."


I'm really trying to keep those open vistas and have the camera distance set at max. Fog I'm using as a game play feature - low level ground hugging fog that arrives randomly and rolls and swells periodically and poisons the player unless can get above it. It took a lot of shader dev time to get this type of fog working.

But as usual you are spot on and I've found that (ignoring performance aspects for a moment) that terrain and assets still 'pop in and out' at max camera distance and looks pretty bad, breaks the immersion. Fog would be a way of hiding this , but it needs to be 'thick' and relatively close to do so. I tried this approach and wasn't satisfied. I also tried depth of field, but even extreme blurring didn't really prevent the issue. So finally, after more thought I've introduced an 'alpha fade' into the PBR shaders - this makes pixels go transparent relative to distance from player. So far this is looking pretty good - it's more like far away things are fading into haze than fog. So far so good - will keep testing, code below if anyone wants to try it too (bottom of apbr_core.fx):



Quote: "Second: Given that you are an abolute expert at custom shading in GG, maybe you can overhaul the default postprocessing and bloom a bit? I find it eats up a lot of FPS for what it is aswell."


Preben did a great job on the shaders already, but I think there may be an engine bug to find/fix in that when using post-bloom and post-sao with exactly the same shader code, then post-bloom 'mode' will eat much less FPS. So in practice this means drop SSAO by moving the intensity slider to zero and if not using depth effects (motion and depth blur) drop these sliders to zero too. I have other tone mapping only shaders that can be used and you're welcome to try/experiment with them for your game when you want to - these don't impact FPS in any noticeable way as they are colour grading only.

Quote: "Odd question too: given that you can starkly modify what you have with GG. Do you ever feel like switching engine in the middle of all this? I can only imagine that it requires a lot of trial and error."


I think if Lee had not placed his engine on Git I would have given up with it and switched already. I'm hoping I can complete volume 1 of this game with GG after so much investment. I've been eyeing up godot for volume 2 perhaps, but who knows, I'm kind of hooked on GG

Thanks for the ideas

@ maiacoimbra69 - thank you sir! What is it that you don't like with this type of game?

@ granada - thanks Dave - I must find time to get back on Discord

@ osiem80 - that's kind of you to say, hopefully can live up to the praise

@lorddweeb - thanks! Yes as per above I think I would have moved to Unity or Godot before now without source access (as much to compensate for the lack of GG documentation as well as being able to tweak), but I also love the 'under-dog' nature of GG and the community is great

I've also been working on polishing some of the surrounding assets required for the standalone, game control below and obligatory screen shot







Cheers.



Attachments

Login to view attachments
Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 25th Mar 2019 21:05
Quote: "I have other tone mapping only shaders that can be used and you're welcome to try/experiment with them for your game when you want to - these don't impact FPS in any noticeable way as they are colour grading only. "


I would love to, yes. Anything to mask the current state of GG's lighting.

Quote: "I've been eyeing up godot for volume 2 perhaps, but who knows, I'm kind of hooked on GG"


Yes, the creators philosophy is really comendable. If I could code I'd jump on it right away. I am however glad to still have you along with Game Guru.
Screenshots look good!
I wonder what these flying cities look like walking through though. I can only imagine that you have to be very conservative when placing detail props / keeping an eye ont he poly count considering the openess of your game play.



-Wolf
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 4th Apr 2019 16:47
Wolf - I'll package something up re post processing for you to experiment with and drop you a message . It is definitely a balancing act with placing the detail and props vs poly and draw calls (which flick up into the several thousand with some air city views).

So taking inspiration from other peoples ideas on this forum, I've tweaked the engine to play intro videos (well can now play any ogv or mp4 video via file name using lua). So far so good with the testing of that - the memory load goes up when playing but drops back when finished as expected/needed. Weirdly I cannot get the engine to loop mp4 videos, only ogv. Must be something to do with the Theora code base but I've spent too much time trying to make it work, and as a non critical thing have left this now as a known issue.

Here are beta intro videos in action:



uses the following lua code in 'titles.lua':



Cheers.

cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 6th Apr 2019 02:47
A glimmer of a flashlight shadow, still a lot of work to do, incorrect perspective

Attachments

Login to view attachments
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 8th Apr 2019 18:16
I’ve been mostly performance and soak testing the last few days.

Overall GG has been really stable and responsive but I did notice some sub 20 FPS moments captured by the environment manager when high poly and draw calls spiked. The managers response is to turn off shadows and light rays which it did and this automatically recovered the FPS. But it looked really bad that the shadows just turned off then back on again after a configurable delay and FPS recovery. So changed it to gradually reduce shadows to zero and back up again when appropriate. This now kind of looks like a cloud has passed across the sun rather than a switch on/off of shadows for performance reasons. It doesn’t happen often but when it does hopefully doesn’t break immersion so much.

The memory allocation was also racing after 3 different terrain unloads and reloads and thought this might be related to what other people are reporting when they load other levels. Turns out though it was mostly due to the 1500 procedurally placed trees they weren’t being deleted from one terrain before being applied to another new one. Now fixed but there is still a 10000k ram increment for every terrain loaded even when previous one is (allegedly) fully deleted. Not sure if this is something not being released in code (can’t see anything obvious) or just something to live with. I wasn’t planning more than 8 terrains to visit as islands and even that might get boring so think will live with that for now.

Other tweaks and fixes to third person camera to stop it going behind geometry and increased swim speed - not realistic but more like console game swim speeds and is more fun.

I let the game run for 10 hours and flew the airship and biplane all over new terrains and the air city without incident though there is definitely a slow memory leak. I can’t find it but will maybe put in an auto save or something if ram goes over a threshold.

Cheers.

Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 11th Apr 2019 15:33
Quote: "Wolf - I'll package something up re post processing for you to experiment with and drop you a message "


Thank you!!
granada
Forum Support
21
Years of Service
User Offline
Joined: 27th Aug 2002
Location: United Kingdom
Posted: 11th Apr 2019 23:08
Very interesting as ever ,with great pics to go with great reading

Dave
Windows 10 Pro 64 bit
GeForce GTX 1050 Ti
AMD FX (tm)-9590 Eight-core Processor
31.96 GB RAM
1920x1080,60 Hz
PM
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 14th Apr 2019 03:30 Edited at: 14th Apr 2019 03:49
So I've moved on to light probes now to try and increase the visuals across different terrains and indoors/outdoors.

The IBL is fairly basic so far using this as inspiration:

http://casual-effects.blogspot.com/2011/08/plausible-environment-lighting-in-two.html

I've created a lua command that triggers the cube map creation. This I think will be easiest as any object can be created to be used as (physical representation of) the light probe. One for indoors and another type for outdoors perhaps.

So far the probes seem to be triggering the cube map generation nicely. The shader work to make the Image Based Lighting replace the stock 'Ambient Lighting' is underway and initial results look promising, though I'm not sure I have the tuning correct yet. I do like that reflective surfaces also receive the automatic cube map specular (from nearest probe) and reflect the internals of rooms and such now. May need to make some more mirrors .

The lua command so far is:
UpdateGlobalEnvmap(X,Y,Z,includeTerrain,includeObjects)

So this can be applied as part of a script on an entity (or zone) to be triggered via proximity (or whenever necessary). It can include surrounding entities, terrain or just sky.

It's far from pre-computed GI but it's a start towards better general illumination. Pics to follow.

Edit: Hugely exaggerated picture for illustration. There are no lights other than the sun in this scene. The sky and floor are being treated as ambient light sources (the probe fired as I approached) - notice the red from the floor on the wooden boards around the top of the building.



Cheers.

Attachments

Login to view attachments
Pirate Myke
Forum Support
13
Years of Service
User Offline
Joined: 31st May 2010
Location: El Dorado, California
Posted: 14th Apr 2019 19:33
Great start. Let me know if you need testing.
RIP
Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz, 2400 Mhz, 4 Core(s), 4 Logical Processor(s), 8gb RAM, Nvidia gtx660, Windows 7 Pro 64bit, Screen resolution 1680 x 1050.

New:
Intel(R) Core(TM) i5-8400 CPU @ 2.81GHz, 12GB RAM, Nvidia gtx1050ti 4gb, Windows 10 Home 64bit, Screen resolution 1920 x 1080. System Passmark 3774




cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 14th Apr 2019 19:41
Thanks Myke, will do, it's looking promising, I'm looking at 'spherical harmonics' now to see how difficult that would be.

Attachments

Login to view attachments
Bolt Action Gaming
GameGuru Tool Maker
10
Years of Service
User Offline
Joined: 24th Oct 2013
Location: Harrisburg, PA (USA)
Posted: 16th Apr 2019 16:25
This is literally the most exciting thing I've seen in GG this year man. Keep it up and please get that code to the core branch asap !
Bored of the Rings
GameGuru Master
19
Years of Service
User Offline
Joined: 25th Feb 2005
Location: Middle Earth
Posted: 17th Apr 2019 06:03
wow, this game is looking fantastic, I do believe cybernescence, you are a genius , my hat (if I had one), goes off to you
Professional Programmer: Languages- SAS (Statistical Analysis Software) , C++, C#, VB, SQL, PL-SQL, JavaScript, HTML, Three.js, Darkbasic Pro (still love this language), Purebasic, others
Hardware: Dell Precision 490; AMD Radeon HD 7570; 12GB.
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 21st Apr 2019 00:26
Thanks for the comments guys

Unexpected side effect of the IBL work - terrain self shadowing (looks a bit sharp at the moment, certainly drawing out the normals):



Cheers.

Attachments

Login to view attachments
PCS
7
Years of Service
User Offline
Joined: 7th Jul 2016
Playing:
Posted: 21st Apr 2019 22:15
wow
Windows 7 Professional 64-bit
Intel(R) Pentium(R) CPU G3260 @ 3.30GHz (2 CPUs), ~3.3GHz RAM 16GB NVIDIA GeForce GT 730
DirectX Version: DirectX 11
Wolf
Forum Support
16
Years of Service
User Offline
Joined: 8th Nov 2007
Location: Luxemburg
Posted: 22nd Apr 2019 17:10
Fascinating process!
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 22nd Apr 2019 19:57 Edited at: 22nd Apr 2019 20:25
Hi guys - it is actually quite interesting, it's consuming my dev time at the moment.

I'm trying to find the best tuning to keep things 'backwards compatible' to typical GG settings without compromising the PBR.

I've had to add another PBR slider (general illumination) to help explore how the lighting works dynamically and to update the shaders more easily.

And because the world lighting now reacts to the skybox/terrain or interior of a building (if you fire a refresh of the environment cube map) then normal operation of ambient and sun sliders doesn't really apply. And also as this version of GG moves the skybox and sun direction, the environment cube needs to be updated periodically to match. When the night sky transitions in everything then reacts on its own to the changing environment 'light'.

Whilst I found some great spherical harmonic resources on the internet, think it's a step too far until I can check the current IBL gets bedded in properly.

This is just a screen shot of a primary colour sky box (though you can only see two colours of it) I created to check that the IBL was applying to objects (PBR concrete ball in this case). This is with the new GI slider to the max.

Cheers.



EDIT: IBL lit terrain:


Attachments

Login to view attachments
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 27th Apr 2019 16:12 Edited at: 27th Apr 2019 16:19
So on the Image Based Lighting front, it took longer than expected (as actually usual I suppose) to get to a consistent coherent place to stop. It's clearly, definitely, not Unreal or Unity in its sophistication but I think it's pretty good for my purposes for now.

I'm quite liking the results, the IBL seems to properly 'root' the objects within the 3D world, just makes it feel more real (within reason, I'm not talking photo realism).

I think I've finally settled on the sliders for PBR including IBL - though TGC may have another view . Or maybe I haven't, I'm not sure that the PBR diffuse, specular, fresnel sliders should really have values that should be tweakable - they were really useful for testing the shaders though.



In the end I kept the Ambient Intensity & Ambient RGB sliders, in theory the GI Diffuse slider replaces these as it affects the light supplied to the scene based on what sky box or what interior is being rendered (assuming a light probe is triggered for interiors - I use the words 'light probe' loosely - these mean different things to different folks - here I mean it is a user placed probe within a scene that triggers a refresh of the IBL used to light the scene when player is in range). Where was I, oh yes, so in theory ambient lighting is not needed, but in practice we
may at any time want to add more light to a scene - artist override - for example in night scenes, with very dark sky box, very little light is added and environment can become completely dark - not usually wanted in most games so adding a bit of true ambient likely wanted in this scenario.

So now that I've got IBL changes mostly stable, I'm changing Cogwheel Chronicles to use it - it already has an automatic day/night system with blending of sky boxes from day to night, night to day, that adjusts sun direction, intensity and shadows. With the IBL I can now remove the ambient intensity hacks that were also there and simply just add a periodic refresh, perhaps once a game hour or maybe more frequently if any visual popping occurs (I've already tried refreshing IBL per frame based on player location and as suspected it drags FPS down, but refreshing every so often appears to have very little effect to performance). There are lots of very sophisticated ways to move this forward (and it's really interesting stuff), but it's taking me away from game development, so I'm going to leave IBL for now unless I come across some glaring issues when testing Cogwheel.

Some with/without IBL pictures below - I've been using Cryengine's Sponza model for testing interior IBL lighting:





(the first is stock white ambient, the second is IBL after 'probe' - lot of light bounce back - perhaps too much?)

And Honolulu mountain range for terrain (no other lighting adjustments other than sky box switch)







The testing of Cogwheel betas continues and frame rate stutters became apparent with some vistas that rocket up the draw calls. I'd previously discounted adding LOD to the models as not making much difference, but I was wrong to do so. I put a LOD_1 level on all of the main buildings in the air city and on first run using these new x files (!) I recovered and average of 5 FPS. Live and learn

Cheers.

Attachments

Login to view attachments
GraPhiX
Forum Support
19
Years of Service
User Offline
Joined: 15th Feb 2005
Playing:
Posted: 27th Apr 2019 18:20
This is fantastic work well done you have set a very good base for lighting this is awesome thank you so much
Welcome to the real world!
Main PC - Windows 10 Pro x64 - Core i7-7700K @4.2GHz - 32GB DDR4 RAM - GeForce GTX 1060-6G 6GB - 1TB NVe SSD
Test PC - Windows 10 Pro x64 - G4400 @3.3GHz - 16GB DDR3 RAM - GeForce GTX 950 2GB - 500GB SSD
Laptop - Helios 300 Predator - i7 7700HQ - 32GB - Nvidia GTX1060 6GB - 525GB M2 - 500 SSD - 17.3" IPS LED Panel - Windows 10 Pro x64
Various Tutorials by me
cybernescence
GameGuru Master
11
Years of Service
User Offline
Joined: 28th Jan 2013
Playing: Cogwheel Chronicles
Posted: 28th Apr 2019 23:55
Thanks GraPhiX, I do appreciate the comments .

I found a glitch with the IBL in that standalones don't pick up the cube map properly or in the same way as test game, so will have to try and find that.

But I decided to take a rest from shaders and back to c++ to see if I could get a memory reset sorted in between levels of games.

Still got more work to do here, but do have prototype code in play that restarts the GG core before every level switch/load. This obviously resets everything, so adds time to the load of each of the game levels and some compensating reload of information that needs to transcend level load will be required , but has the large advantage of freeing up all the memory for each level.

So it will depend on the type of game, number and size of levels within it as to if this approach works best or not. For few or smallish levels then it's not worth the wait time between levels.

Initial results that I think are telling me another story worth investigating (re what is happening before a level is loaded):

This test is from a game with 5 levels all very similar in size of assets and textures used:

Standard/stock:

Level Video Memory System Memory
1 1064 780
2 1307 794
3 1523 797
4 1743 799
5 1963 802

This agrees with earlier tests, in that it is video memory that is usually exhausted first and is why (I guess) Preben added the standalonefreememorybetweenlevels=1 option, so that this can be released between each level if required.

With the new standaloneresetallbetweenlevels=1 option set (work in progress), the results were:

Level Video Memory System Memory
1 1063 778
2 992 610
3 990 610
4 990 610
5 989 609

So I was expecting the result for the first level to be exactly the same ( and it is pretty much). I was then expecting this to stay static for levels 2-5, which it has except there was a marked drop first. So I think this is telling me this approach works but also there is a fair bit of video texture being eaten up before the game levels load (maybe the title screens and such?).

Of course there is video caching and all sorts of other things at play when games running in anger, but it so far does look like a viable way of getting larger and more levels when needed at the expense of longer loading times per level.

I'll have to try on some real levels now and see what happens.

Cheers.

Login to post a reply

Server time is: 2024-03-28 15:00:06
Your offset time is: 2024-03-28 15:00:06