Hhhmm... needs geometry shaders!

Finally going to break down and add some geometry shader instanced grass soon now I have the shader based fbm ( no texcoords! ) tweaked a bit for flora spawning / layout for testing.  The other cool part will be that grass will be opaque now.  I may add some faked transmittance to that as well.  Then again playing with some procedural animation and IK might be more fun.

Screenshot Weekend

Well, mostly focused on non-renderer stuff this weekend like bringing more of the web editor interface into in-game viewport UI.  A few minor improvements to sky with a simple per fragment Preetham, and ported all my shaders to the updated Kagura shader lang to get ready for Vulkan.  

Same scene -- different foliage seed -- with some general lighting improvements:

Below is a simple test for tiling fbm independently for foliage generation with the threaded voxel sectors, so there is no need to do another physics based ray cast pass.  Each pixel is 0.5m^2 per sector here.  Basically this is using a multi-level frequency hierarchy to generate the foliage overlays independent of other tiles, yet still match up.  I might try to expand this to 3d vol tiles for things like clouds for proc sky + ray marching later.

        KaNoiseFractalBrownianMotion2d( octaves,

                (x + tx * 512.0f) * frequency,
                (z + tz * 512.0f) * frequency,
                amplitude, lacunarity, gain );

Holiday screens cont

Played around with some aerial perspective blocked out for forward / deferred, and a little LoD systems update.  Also an old indirect lighting hack via bi-directional sun tossed in for good measure, which isn't a bad fallback when IBL data is not generated for a scene.

A little screenshot

Playing around a bit with the old engine voxel terrain with erosion and procedural foliage deco.  Maybe something better to post next weekend.

Screenshot Sunday?

I have been busy and had a bout of illness, so I haven't updated my blog in a while.  Mostly I've been researching new procedural content systems and re-reading SIGGRAPH papers while reworking my TDD.  Been looking into merging GPU clipmaps with the old 100% procedural voxel terrain system to allow easier content creation.  Also a lot of other stuff not worth showing even as a WIP like proc sun/sky.  Right now I'm going to focus on sun only tests for physically based light until approx phyiscal units for color temperature, intensity, et al are choosen.  Also various materials are being reworked to be more correct via tweaking until this is stood up for comparison with PBLs.

Right now my VR work on kagura is halted with the death of Linux SDKs for Occulus DK2.  One of the reasons I'm starting this blog back up is I hope to get a Vive kit this year.  In the meantime researching physically based lights and cameras along with other subsystems is a huge enough task.  Physically based shading is great, but you end up hitting a brick wall without the other two -- I suggest reading SIGGRAPH 2015 The Order 1886 slidedecks, and "Moving Frostbite to PBS" is still one of the better introductions.

Playing around with various light models and LoD again in the old mesh terrain test scene aka breaking things that used to work.  You might notice no IBL, no SSR, and no shadows in these; however they're not even the same BRDFs in the same materials in these shots either.  Easier to me to lower amount of variables.

KaAllocator / KaTask Refactor Cont

Now my hand works again I decided to do a little bit of coding tonight on my new allocator system.  Inspired by an old bitsquid blog post I decided to move to a full explicit allocator model, and reworked a ton of old subsystems ( like 2006 and older** ) to be more data-oriented as practice.  

Will soon be reworking the task management system to have easy dependencies.  Right now 'jobs' -- which are really tasks or jobs -- have to be explicitly enqueued or synced internal to their work unit.  This is because this code was written previous to modern task systems, which are now en vogue.  Instead it focused on specialized threads with process affinity and a collection of generic 'worker' threads.  Think render, game, io, general pool.  For example the screenshot 'job' would enqueue itself to the explicit renderthread to grab a framebuffer into memory -- HMD FBO, camera render target, or framebuffer -- then hop over to an encoder step and then finally explicit IO thread queue to dump out to disk / http.  What a pain.  Moving to a flatter generic system that can sit in a single ringbuffer is much easier to manage and debug.  A screenshot for systems code update blurb?  Sure why not!  Also cleaning up the embedded stats UI.  I want to put some of this on github at some point, so more people will think 'correctly' about this issue in the future.   :D

** The oldest source code had emacs mode lines, and was from the 90s.  :D

Snow and such

Well, got to bang on the hobby project a bit during Monday.  Mostly fixed particle emitters and some old rarely used timing code gearing up for the new curves based systems.  All the particles look ugly still, so here's a skeleton sneak:

Little tweaks here and there

Mostly worked on Lua R&D, minor polish, and content clean-up in the little time I spent this week.  Haven't had time to rig the new characters to demo the new animation system either.  Will be dropping all the old content not from CC0 / CCBy sources, so I can do a public demo once that is ready.  I also pruned a lot of the editor systems recently as I'm going to expand them with more in-game viewport editing support.  Progress is slow, but if there are new HMDs on the market by the end of the year with SDKs I plan to ship something to show off Linux GameDev + VR.  Yes, I am considering a VR specific editor mode too.  You won't believe how easy it is to spot issues in a level in VR!   :)

Dat water

Tweaked the basic tiled flow water shader and textures up a bit in between some other content fix up.  

In the middle of a brand new physically-based animation design / implementation  that is also data oriented.  Going for something pretty generic so curves can be used on everything from audiosource events, to UI, to of course IK blended skeleton animation.  Keeping everything SoA and flat arrays outside the high level user facing stuff of course.  Just something to do while doing some long work tasks over night I guess.  Haven't worked on an animation library from scratch in some time!

Bonus, post power outage dirt + freckles + eyes material fun:

Got 30mins in today

Played around with view weapons and such.  Awkward skeleton feels uncomfortable.

Ground work for grasping demo done

Got some assets and their physics setup while playing around with new light models and materials on previous content.  The best part is now if you try and stick your head into stuff you effectively get IK that will push the camera back in the game in a natural way.  It kind of feels like sliding your head down the wall when you try to peek through it.  Will likely do some proc animated enemies with a quick homemade ragdoll system next week if I get any free time.  Everyone loves ragdolls and physics fun.  Sword play, archery, and a little magic are still the goals for the public demo.   If you have a DK2, some move controllers, and are a Linux developer that wants to test stay in touch over the next couple of months.  Yeah hobby project.  Also looking into getting networked game sessions working again on a related note.  Coop VR RPG, anyone?  I'm looking for more CC0 and CCBy content I can modify for the demo too if you see any!  :)

Some PBS updates to forward materials

Using Oren-Nayar + GGX for about everything again, but will likely switch forward rendered stuff to Disney's diffuse using fresnel + GGX for lower end laptops.  I'm actually faking the GI like effect if you can even notice from this angle.  That glowly thing on the hut is a test volume that flickers like fire, because otherwise who would notice it?  I guess posting photos works to keep interest in a project even if I'm mostly playing around with light models and content a bit here and there this week.  Kind of relaxing thing to do working on art and tech art after you code all day.

I did a little research into IK driven animation, so maybe one day the stupid viewmodel hands will sync to your actual hands in rift + move mode.  The rift IR LEDs can be seen pretty well by the EYE if you seen my gallery.  Also if it comes to it I have PS VITA 'bird shit' cards, which are standard enough.  Need to hook up my leap motion to the demo!  So much to do and so little time.  :)

This photo blog thing...

So I barely got to touch VR all week given late nights at work, however I made some new physically-based shading textures and materials for a new tree model I found on blendswap.  Mostly playing around with SDL2 GameController DB support and paying bills tonight.  Hopefully I'll get around to a fully working grasping and throwing knife demo.  Will have to make a chest lock-picking and opening grasping "minigame" too.  Such rogue, much looting.

Minor update while purging tons of outdated shaders and art assets:

Linux DK2 saga in screenshots cont.

It seemed like a good idea at the time...  raining gaint swords down from the heavens is kind of fun in VR.  Maybe it's time to add back some AI monsters... but then nothing will get done... except hunting monters.  Time for bed.

Nvidia 346.35 Linux drivers on DK2 seem to help vsync.

I tried out the new Nvidia drivers for Linux tonight, and thank you very much!   My swap buffer time is *much* less.  Excuse the single eye menu / stats bug:

Installed run from:

http://www.nvidia.com/Download/driverResults.aspx/81252/en-us

Added this to my /etc/profile of course:

# thendrix - Add for oculus rift sync.
export __GL_SYNC_DISPLAY_DEVICE="HDMI-0"

* 5ms typical frame in 2d
* 13ms typical frame on DK2
* Ignore the spikes which included some shader uploads over HTTP, screen caps, and such.  ;)

Edit: TwinView and 3x displays could sometimes make typical frame 27ms previous to this change if you didn't know.  These new numbers are with Twinview enabled and not using a separate X display.  Previous to this it was recommended to disable Twinview or run game in a different X display due to sync issues between 60Hz IPS displays vs 75Hz DK2.   I'm using a GTX 760 on a i7 with 6 HT cores, and my game engine uses a lot of threads.  Looking forward to getting a 970 for CV1 if it has Linux support.  :D