Thursday, 23 May 2013

Thursday Thmoothness

Happy Camper

A nice day indeed. I cleared my inbox in about 15 minutes, and was able to dive right in today. Thanks to new improved LOW LOD meshes from Mark, I was able to get the prototype for Instance Stamping back to a nice smooth fluid 120fps experience, and also discovered the stutter was caused not by the iterations to process the vector transforms to get parent mesh data into the buffers, but the constant creation and deletion of buffers that where found to be too small. By predicting the final size of the buffers, and making them larger initially, such a release/recreate was avoided and everything smoothed out again. Hurray!  All these issues are pointers to watch out for when it comes time to integrate and refine within actual game and editing scenarios, but it was necessary to go through it.

Phone Interview

I also had the pleasure of being interviewed for a Case Study on the perils and potential of Perceptual Computing development. Had a great call and imparted lots of little coding gems, so hopefully you will get to read that soon. I will post the link when it goes live. It's being commissioned by Intel and professionally authored by people who do this for a living, so I am looking forward to reading it myself.

Surprise Email

As you may know Mark's primary mission in the project right now is the creation, rigging and animating of our central character for Reloaded. It's a lot of work, especially as our mandate is to push the envelope. An email dropped in this evening which got me quite excited and shows the potential of the AI system when I finally get around to coding it.

For some reason the Google Blogger is not showing me the YouTube videos associated with my account, so here is the link instead.  

As you can see, having these as part of the character behaviours will mean making a successful hit has become much more challenging, and if you don't know they are hiding, having them leap over an obstacle and start firing will come as a real shock.  Can't wait to get it into the action..

The Lighting Question

Thanks for the comments so far. I have done some brief research already and it looks like we don't need to choose between deferred and forward rendering as such. A technique called 'Cascade Shadow Mapping' will allow an entire scene to be shadowed from a single spot of light up in the sky. I say spot as that is essentially what the technique uses (spot light) so would not be ideal for a point light source for an interior scene but perhaps the idea of baked lighting and then CSM for outdoor scenes would be the solution. The research and thoughts continue. I am curious what hardware my readers have in terms of graphics card right now. A major factor in whether or not to 'defer' is how many users have the graphics cards required to run the technique. Deferred rendering relies on drawing a large portion of the scene three times over, as opposed to the forward renderer which can do it in one.  For this you need monster graphics horsepower and plenty of video memory, so what do you guys have (and what does your end user have)?

Signing Off

The evening is not over for me as I want to put another hour into moving the Instance Stamp stuff over to the map editor to see where we are.  It never pays to stay too far away from your engine, and as much fun prototypes are you cannot sell them and they are by there very nature disposable. I might also spend an hour looking at the Bullet physics SDK and seeing what kind of demos and games have been created with the technology. 


  1. Blog content info and Character AI video is all good.

    Personally My current main system has some substantial power but its more than the run of the mill computer that perhaps and average user would have, unless they have a dedicated gaming machine with obvious qualities. They tend to be relatively very expensive so I dont know how many will have them.

    Clearly computers improve over time so more will have better I guess by next year, though the issue remains that in general your average user will have an average system, as to get more you have to source and spend towards the top of the range of systems. That is unless you are like me and know what to buy/get and still keep the cost sensible but get a lot more for your buck than you will from your run of the mill "Brand Name" machine which is generally a rip off.

    A lot of general game buyers/players almost certainly may not have the same level of computer as some of we game makers perhaps.

  2. It will be interesting to see how FarCry and UnRealEngine4 deferred renders operate on the average system for sure. I remember buying an off the shelf PC once in a moment of weakness. It was terrible, with hardly any horsepower and no expansion slots to speak of. It was around that time I vowed to build every machine from scratch after that - and the plans tends to work, with the only downside that my rig is no longer an 'average' system on which to test my software. I look around and I am hard pressed to find a PC in my office I would call average as they where all built with expansion in mind, and I sort of expanded them over the years ;)

    1. I do have a suggestion of a really good Computer that I'm using right now, it can run games really well! It might be a little too much for what you're looking for, but it's perfect to test the games!

    2. Though, it's nearly $900,00, and that's just the tower. O.o

  3. I'm on the deferred render side. Reason why some games still use forward rendering is because it is easier to maintain the current engine iterations, but as we speak many engines are developed using deferred technique. And with the new Xbox One (x86 8 cores, 8GB ram) and PS4 kick-starting the new generation of consoles people will expect more graphics wise. Personally I don't think it's a good business idea to invest a lot of time in a system which is already on the brink of becoming obsolete. Then again you have to think what works best for your guys (TGC). If deferred rendering will take ages to implement without substantial income guarantee, perhaps, it's not worth it at all. Then again, if you can make it look good, I expect a lot of teenagers cashing out on FPSCR to make their next CoD's and BF's or whatever they're gaming now. My laptop is a x64 i7 quad-core 2.3 Ghz, 8GB RAM, GeForce GT 630M 2GB (dedicated).

  4. I get very excited when I hear any talks about updating the AI.

  5. This comment has been removed by the author.

  6. A forum member, "Evolved", has done a lot with lighting techniques in DBPro. He has his DBPro Advanced Lighting library, it might be worth taking a look at it. Maybe it could give you some ideas, or even be a decent way to get an idea of what type of hit performance may take.

    Here's the link to his Advanced Lighting Library:

    And here's his website where he has many lighting-related shader examples:

  7. What might be an idea is to whip up some little program that users can run which will return the data in the correct form so it's unified.

  8. I'm vote for deferred (see my longish comment on Wednesday's post for an explanation and more info). My opinion is that deferred rendering isn't as slow as people make it out to be, particularly with lots of lights and shaders (compared to forward), so it will run well-ish on my laptop and if it runs on my laptop, I'm happy.

    My system is a laptop: AMD quad-core A8-3500M 1.5GHz, 8GB ram, Windows 7 x64, AMD Radeon HD 6620G and 6400M (the CPU is an APU, uses crossfire), total of 1.5GB of video memory (overall it's an average computer). I have played the campaign of BF3 (some time ago, actually, I even pre-ordered it), on lowest settings, very low FPS but JUST playable. I'm currently playing Far Cry 3, lowest settings (but still looks great, lots of grass and light and shadows), runs well-ish (40-50 fps) and perfectly playable.

    My target audience is people like me, who want to play all the cool games but aren't mega-serious gamers and haven't the money for a hefty rig like yours, Lee. So make sure you test FPSCR constantly on the oldest, least qualified system you own.

    Cascaded shadow mapping isn't what kind of light you use but how the shadows are spread out. They are usually divided into four shadow maps, the closest one (0-100 metres, say) is the highest resolution. The next closest one (100-400 metres) is a lower resolution, and so on. It means you can display shadows a long way off into the distance without rendering them at high resolutions where you can't see them. It's a LOD for shadows. Again, see my comment on Wednesday's blog for more info and some useful links.

    Generally, CSM is used for the single directional sunlight outside, and all other lights (light bulbs, candles, flaming torches in the dark streets of Rome at night) are rendered normally (these days often via deferred rendering).

    ---- HOWEVER ----

    Having just said all that, and having so far been a strong advocate for deferred rendering, if it would be at all possible, it would be entirely mega-super-uber awesome if you could support both; ie., deferred AND forward rendering. That way everyone's happy, because I know for a fact that generally, forward rendering is faster on older PCs (as in mine) when there's not 100s of lights.

    Sean, regarding Evolved's AL, first of all, everyone knows about it, second, Lee has already asked us about it, and third, it's slow and would be hard to unify with other shaders in Lee's systems so I think in the long run in would be a bad solution. I know you're trying to help but I'm tired so I probably come across a bit rude. Ignore me if you like...

    Andy: What data is this you refer to?

    I think that's all I wanted to say...

  9. Deferred renderers can handle a huge number of dynamic lights as their main feature, but they also tend to have the highest system requirements too. And they are terrible with alpha blending. I read an interview with the developers of Dead Space, and they said they had to put all their window objects near light sources as a workaround since alpha blending did not work with lighting on their deferred renderer, so alpha blended objects were always fully lit no matter what.

  10. Ah, yes, I forgot about alpha blending. Unity uses a combination of forward rendering and deferred to get around that. Plus, just because deferred can handle lots of lights doesn't mean it handles lots of shadows well; it handles shadows just as slowly as forward.

    Really, I don't care that much which render path you use as long as we can have ~8 or so lights visible at any one time with shadows and still have it run well.

    To be honest, if you could find a way to make dynamic shadow maps merge seamlessly with pre-baked lightmaps, that would be the best solution by far (very fast and looks great). Particularly if you then used forward rendering (now that Mr. Blosser has reminded me of the alpha problems of deferred rendering).

    Actually, Unity uses a combination of lightmaps (long-distance views) and realtime shadows (close-up views). It renders as much as possible with deferred rendering and renders things that can't be deferred with forward rendering. Quite clever, really.

  11. This comment has been removed by the author.

  12. Actually Unity runs REALLY poorly on my laptop, even running the simplest graphics, because it's a deferred renderer. I have officially changed my mind, and strongly vote for forward rendering (it'd be easier to implement anyway) because I want to actually be able to use FPSC-R without having to buy a monster computer. I think you'll find your greatest audience is actually hobbyists and people that "want to make their own game" but have no programming experience. These people generally own only an average PC.