Liquid Rock Games Dev Blog

New LRG website update and blog

2010-12-17T09:34:00.000-08:00

Hi guys,

Just to update everyone that we've updated the new Liquid Rock Games website (http://www.liquidrockgames.com) and moved our blog to Wordpress.

Word Zen Unlimited released!

2010-12-13T20:33:00.001-08:00

We have just released Word Zen Unlimited for USD 2.99 !

Features:
* Advertisement free! No advertisement pop ups for Word Zen Unlimited.
* Save and continue your game anytime you like and upload your high scores later.

Purchase available here:
http://www.slideme.org/application/word-zen-unlimited

Word Zen ver 1.1 update

2010-12-02T08:27:00.001-08:00

Hi guys,

We have just updated Word Zen to version 1.1.

Changes include:
1. Fix bug on ad buttons not showing correctly.
2. Apk install now installs to SD for froyo.
3. Solved certain input not responding issues.
4. Added return button to exit app in main menu.

Download the updated version from the official Word Zen website: http://wordzen.liquidrockgames.com/

Word Zen Gameplay Video

2010-11-30T15:16:00.000-08:00

Check out the Word Zen gameplay in action :D

Tips to increase score count in Word Zen

2010-11-29T06:32:00.000-08:00

Some tips on how to rack up scores in Word Zen quickly:

1. Make plural words.
2. Destroy obstacle tiles whenever possible by making them fall 2 tiles as they produce the most points.
3. Use shuffle often !
4. If you're stuck in the bonus round, click on the Pass button to skip to the next puzzle fast !
5. Know your 2 letter words such as: AD, AH, AR, AW, BI, ED, EF, EH, EL, EM, EN, ER, ES, EX, FA, HA, HM, HO, LA to name a few.
6. Know your 3 letter words such as: GEE, WEE, TEE.
7. Common word endings to include are: -ING, -ED, -ER, -IER, -IEST, and -IES.

Visit the official forum for more tip updates!

Alternative download links for Word Zen.

2010-11-27T20:21:00.000-08:00

Besides the official Android marketplace, Word Zen is also listed and available for download from these following sites:

http://www.appbrain.com/app/word-zen/com.liquidrockgames.wordzen

https://www.slideme.org/application/word-zen

http://android.handster.com/word_zen.html

http://andappstore.com/AndroidApplications/apps/Word_Zen

Word Zen Reaches 1000 downloads in 24 hours!

2010-11-27T09:10:00.000-08:00

Thanks guys for the support ! For those who has not tried out Word Zen yet, get it from the official website. :D

http://wordzen.liquidrockgames.com/

Word Zen - Android Word Puzzle Game

2010-11-26T01:10:00.000-08:00

Hurray its finally finished! Liquid Rock Games is proud to present Word Zen for Android phones and tablets. :D

Official Word Zen website: http://wordzen.liquidrockgames.com/

About Word Zen
Word Zen is a simple yet addictive word puzzle game from Liquid Rock Games with a relaxing zen-like theme which will appeal to players looking to test their word vocabulary.

With thousands of official crosswords words to form from, the possibilities are endless!

Features:
* Swipe letter tiles in any direction to form new words!
* Over 100,000 words to solve as seen in official crossword games!
* Global leader boards for players to update their scores and to compete for world ranking.
* Use special tiles to your advantage and form new strategies.

Screenshots:

Physics Data Format Reconstruction

2010-10-27T00:58:00.001-07:00

Over the past week I've been doing a major surgery on the core Solid State Engine to restructure our physics data format especially on the batching front. Due to the requirement of invisible physics meshes for certain simulations in Aftershock, I had to fix this long overdue feature. Previously, batched meshes from our editor are forced to be static physics meshes thus allowing us to do precise world collision. However, there are times when we don't require such precision or when we want an invisible wall to keep things within a boundary.

Being so, I've redesigned the internal batching architecture to take into consideration of invisible physics meshes. To improve efficiency, I made a new file format to define physics meshes which can both be exported from Blender3D or from our world editor.

After all said and done, a major surgery can be quite an issue. Unexpected bugs started to emerge all over the place. I've probably fixed about 20+ of them already. There's still some more to go at the moment. At any rate, with this new change, our fellow artists will need to reexport their prefabs to the new format. Fortunately scene structure still remains the same. So it's not too big a deal. On the plus side, we get a much more well defined physics system and a more efficient file format. In the process, I've also removed the need of physics definition files for visible static meshes. This will cut down a massive load of unnecessary files which would lower our level file size! Yeay!

Ok. Back to debugging and get this work ASAP. Major surgery sucks. *_*

Grapple With Animation Revision 2

2010-10-14T12:04:00.000-07:00

Updated the grapple machine with 2 rotating rings.

Disruptor Weapon FX test

2010-10-07T10:14:00.001-07:00

Very early weapons FX test for the disruptor weapon.

Effects System

2010-09-25T03:52:00.000-07:00

Wow, this blog post is long overdue. The past few months had been a rather busy month for me. I had to juggle between a few projects which saw work on aftershock slowed down to a crawl.

However, I'm now back to speed. :-D

So today I'm going to talk about our effects system. The effects system has been in my head for a long time. I had been doing lots of thinking through making sure that my idea was sane and useful. I'm rather proud to say that the effects system is very well capable of complex effects that combines lighting, particles, ribbon trails and even animations.

The idea was not a revolutionary one though. What I came up with was a node graph system to define a behavior of a given effect. Imagine blender's material node system but instead of applying on materials, we apply on entities. If you're quick to notice, this idea is pretty much a high level primitive scripting system. Only that instead of using scripting, we build nodes. One could also think of it as shader nodes for effects.

However, to keep things simple, I omitted conditional nodes and forced all value type to be float. Hence we only have float, float2, float3 and float4 value type.

Bellow is an example of how a flickering light effect can be described with the node system:

Figure 1 - Flicker Light Effect Example

To aid the ease of node building, I've also made the node system do auto conversion between the defined types. This mainly means single float can be easily converted automatically to multi float type. Any other combination is not possible as that would be ambiguous as shown bellow:

Figure 2 - Value Type Auto Conversion

Adding on top of that, I've allowed nodes to support multiple slot mode. This is similar to the method overloading of C/C++. The only difference is that the number of input/output slot must retain the same. Only the value type can be different. With this, depending on how the node graph is linked, my node compiler will use the best fit mode for any node processing.

Bellow is an example of how it would work given a mock up node graph scenario:

Figure 3 - Multi Slot Mode Use Case Example

So why do we need this? This is very useful for primitive operations for example Addition, Subtraction and Multiplication nodes which requires different input and output value types for all possible combination.

Once the effect node graph is defined, we can simply bind them to entities that demands the given effect. :-) Obviously the whole implementation and design is much more complex compared to this. However I felt the node graph idea to be most interesting to report about. Imagine the possibilities of extending this into animation systems which interestingly is very similar to the animation blend tree idea.

Oh yeah, one nice effect of the node system is that when designed carefully, we can reuse the compiled node graph on all instance of the same effect in the scene. Also, if written properly, this is actually much more optimal compared to using a scripting engine which I personally feel should be left to handle less CPU intensive logic like game rules.

There, I hope this is long enough to justify for my lack of blog post. I will put up some programmer art effects video if possible when I get the effects system running and tested. As of now, I already have the node graph system and entity binding in place. However, I've yet to deal with all the possible node types I planned to add to allow complex effects. Still, having the base system means we're pretty close to a complete effects system already. So stay tuned. ;-)

2nd Craft Update

2010-09-23T02:06:00.000-07:00

Finally another update after a long holiday and some projects and it's back to Aftershock :D

Shown here is an in game shot of the 2nd craft in progress.

another project completed...

2010-08-17T09:50:00.000-07:00

Phew...sigh of relief upon completion of another project for a client. :D Time for some rejuve and then its back to Aftershock ! >:)

Updated powerup

2010-06-27T11:18:00.000-07:00

Decided to go for simpler icon looks for the powerups which players can pick up along the tracks as the older powerups were harder to identify from afar.

Here's a sample rocket pack powerup.

Outdoor Test Scene Vid

2010-06-22T14:09:00.000-07:00

Small real time outdoor test scene to test paging geometry as well as our new water shader materials. Several future wish list improvements include more material blending for terrain surfaces. Further stress tests and optimizations for dense foliage systems needed.

SSAO update

2010-06-12T19:37:00.000-07:00

More screenshots on our SSAO implementation. This time with all textures+lighting+post processing on.

Image01 Before SSAO

Image01 After SSAO

Image 02 Before SSAO

Image 02 After SSAO

Image 03 Before SSAO

Image 03 After SSAO

Image 04 Before SSAO

Image 04 After SSAO

Image 05 Before SSAO

Image 05 After SSAO

Image 06 Before SSAO

Image 06 After SSAO

Mine Powerup Trap

2010-06-11T12:03:00.000-07:00

Touch this powerup and several mines spawn on the track within the area.

Missile pack powerup

2010-06-10T22:58:00.000-07:00

Just completed this missile pack powerup to replenish those used missiles.

Screen Space Ambient Occlusion !

2010-06-10T10:12:00.000-07:00

Oooh yeah. Left-Hand just added in screen space ambient occlusion (SSAO) to our Solid State Engine. Now all added details such as normals really POP out ! >:)

Image01: Without Screen Space Ambient Occlusion (BEFORE)

Image01: With Screen Space Ambient Occlusion (AFTER)

Image02: Without Screen Space Ambient Occlusion (BEFORE)

Image02: With Screen Space Ambient Occlusion (AFTER)

Image03: Without Screen Space Ambient Occlusion (BEFORE)

Image03: With Screen Space Ambient Occlusion (AFTER)

Image04: Without Screen Space Ambient Occlusion (BEFORE)

Image04: With Screen Space Ambient Occlusion (AFTER)

Image05: Without Screen Space Ambient Occlusion (BEFORE)

Image05: With Screen Space Ambient Occlusion (AFTER)

Ammopack powerup FX test

2010-06-06T02:27:00.000-07:00

Early stage ammopack powerup FX test.

Network frenzy

2010-06-04T10:27:00.000-07:00

Just a day before I tried back network play of aftershock and to my dismay the jittering issue came back. I thought I had nailed it but apparently I did not. So I delved more into the design of my code and did tons of debugging again. After a few test cases, I finally found out the issue. It was two fold.

Firstly, there was an issue where my client side's simulation was shifting farther and farther away from the server's simulation due to time discrepancies between both systems. Secondly, my camera simulation code was not entirely in sync with the physics simulation code when applying frame smoothing.

After some tinkering, I managed to fix both issue. For the first issue, I kept a 5 frame buffer of frame latency to get the average latency across snapshots. From there, I use it to cap the frame difference between the current physics frame and the given server physics frame.

Now everything works like a charm and no more jittering from my test case. In fact it's so smooth compared to my last work that I'm mightily proud of it! :-) I do know that I'm not revealing much of how I did my network syncing here. I'm rather busy working on many things right now. But I promise I'll put up a post with some diagrams some time later to explain the approach I used. In short it's what Gaffer suggested for the server client approach though like I found out as I did this, it's not as simple as it sounds. There's slightly more to it than just sync and smooth.

Aside from that, I wish that bullet provides a proper method for me to selectively simulate a group of rigid bodies. This would help a lot for the prediction simulation after snapping of server update state; we don't want to end up wrongly simulating non networked local rigid bodies or non important rigid bodies that are not part of the network update snapshot.

Solid State Engine logo

2010-06-02T21:10:00.000-07:00

Decided to work on our new Solid State Engine logo which is responsible for all the visual goodness which is seen in Aftershock.

The 2 gears in the center represent our engine's earlier loading screen :D created by Lih-Hern.

More lighting fun !

2010-06-02T04:28:00.001-07:00

I could not resist playing with our new semi-deferred renderer and decided to add play around with more real time lights in our editor >:) Imagine it with lightning effects emitting from the device.....

We'll be able to place in virtually unlimited lights real time for not only indoor scenes but also FX effects like fairy dusts...sci fi weapons blazing....the possibilities are just endless !

Mish mash of props for the industrial racing zone

2010-05-17T20:52:00.000-07:00

Just thought I'd post some prop updates on the next track level which features an industrial powerplant-nuclear feel to it which will be rearranged later. Decided to go on smaller building blocks for the buildings as it'll allow me to scale the size of the level easily. The track is meant to be surrounded by industrial like complexes. So expect lotsa labyrinthine tube like old machinery for the level.

Drain water test

2010-04-02T20:15:00.000-07:00

Heres a sample drain water test for the industrial level theme. A lil difficult to view the refraction on the base adn reflection with this youtube vid but its there.

Deferred progress 6

2010-03-20T07:49:00.000-07:00

As mentioned, previously, I pointed out two method to render volumetric lights. I have successfully implemented the first technique for both point and spot lights. Here's a screen shot of it in action(4 point lights & 1 spot light):

Notice the frame rate with my crappy hardware. This is with shadow, HDR and refraction on. Previously, when we were still using forward rendering, I get about the same FPS at ~40. This has proved my speculation was right that when all features are on, I will not see any significant frame rate changes. In fact, we gain the ability to do cheap lighting! The old renderer would have done a horrible job to produce the screen shot above. Hence, deferred lighting FTW! :)

However, since the current method is rather brute force in that all lights will use stenciling technique, this means we might hit a limit quite quickly(probably around 30+ lights). To solve this issue, I have plans for light batching. The idea is to group lights that only encompass a small area in screen space. Then we use shader instancing to render the lights without the stencil pass. Obviously this will end up rendering some redundant portion of the screen. However, I do believe the optimization on less render state changes will offset this cost. As to what is the right screen ratio, I currently have no clue. I probably need to build a test level with tons of lights to figure out. :)

As for the second technique I mentioned during the last post, I intend to use that for custom non convex light volumes. This method allows me to scrap the light group masking idea I had which not only complicates rendering, it also gives the level designers a lot of headache. The goal for this custom light volume is to allow level designers to define light volumes that will not leak into areas they do not want to due to no shadowing; for example spot light casting across adjacent room.

So there, deferred lighting conversion, success! Woot! :-D I must say I have learned a lot over the course of attempting this rendering "upgrade". Now I finally understood the tricks of getting view space position from depth buffer. I was having some trouble especially on figuring how to generate proper far clip plane coordinates with a volume mesh on the screen. But thanks to nullsquared the genius, he solved it for me in a forum post I found. Still, let's not get into the details less I become too long winded; which I already am. :-P That's all for this post.

Ciaoz

Deferred progress 5

2010-03-16T04:26:00.000-07:00

Local lights are the main factor that made deferred lighting so appealing. The fact that they are rendered in screen space allowed the process to be fillrate dependent instead of vertex bound; where in the forward renderer, for each light lit on a geometry, we have to send the whole geometry to the GPU for rendering.

However, deferred lighting incurs fillrate issue that is typically encountered with particle effects. In the naive approach, one would render quads on the screen representing each light. This method though working well with small attenuating lights does not work well at all for lights that covers a huge volume of the screen space. Hence we would like to come up with a solution of optimal lighting where only affected pixels are rendered.

The answer to that problem is light volume rendering. Instead of rendering quads on the screen, we render volume meshes that represent the lights; sphere for point and cone for spot. Being that they are real true mesh rendered in the scene, we could utilize the Z-Buffer depth test to cull areas that are occluded (Figure 1 - A). Unfortunately, this is not optimal most of the time. With only simple volume mesh rendering, surfaces that are not affected behind the volume mesh will get uselessly rendered as well. Another way about this is to render the backface of the volume with a "greater equal" depth test (Figure 1 - B). This method would cull off unnecessary surfaces that are behind the light volume. However, it does that at the cost of never culling for surface in front of the light volume. Hence such naive methods do not work well at all for what we are trying to solve.

To illustrate, lets give a 2D visual of a given scenario:

Figure 1 - Naive light volume approaches

Interestingly, there are a few methods to solve this and they all uses the stencil buffer. The idea in fact came from the good old stencil shadow volume rendering technique. There are many articles out there on this topic if anyone is interested. However, to summarize, these are the two more popular technique used: Depth fail hybrid and XOR stencil technique.

Let's start with the first. To understand this technique, we need to first take note of one interesting fact. If you look closely at Figure 1, you would have realized that to get the desired result, we could combine the two naive approach with an AND logic operation!

Figure 2 - AND logic operation

Now with that in mind, lets talk about how the depth fail hybrid technique works. The reason why I called it a hybrid technique was that instead of the full depth fail stencil volume technique which uses two stencil render passes, the technique applies the first depth fail stencil pass and then combine the second depth test pass with the lighting render while applying the generated stencil mask. Effectively this is equivalent to the AND logic operation but with better fillrate optimization due to using one stencil pass instead of two (I'm referring to stencil shadow).

Figure 3 - Z-Depth fail hybrid

Lets get on to the second technique. This is actually a less common technique due to it being more fillrate intensive compared to the previous technique. The concept of this technique is to flip the stencil value without triangle face culling. Hence, it pretty much mimics the XOR logic operation. Truth be told, this technique could be done in two ways; Depth Pass(Figure 4 - First row) or Depth Fail(Figure 4 - Second row).

Figure 4 - XOR logic operation

From what I gather, the latter implementation seems to be the implementation of choice just as the Z-Depth fail technique. If I understood it correctly, it is due to typical scene structure where camera views are mostly looking at sparse areas instead of having plenty of near eye occlusions. Hence it will optimize off some fillrate in the stencil pass. Also, an interesting note is that doing a Z-Depth fail technique for this XOR method actually avoid the problems of when camera is within light volume.

Having said that, the light volume stenciling technique obviously does not follow stencil shadow techniques. Due to this, the two mentioned technique actually assumes some limitations.

For Z-Depth fail hybrid technique, the system assumes enclosed convex light volume. The usage is also not applicable when camera is inside the light volume (Frontface is behind camera resulting in no lighting).

For the XOR Z-Depth fail technique, the system assumes enclosed light volume. However, due to it's nature of XOR operation, the light volume can be concave type as long as there are no intersection issues. This is an interesting behavior as it means we could have specially controlled light volumes that will not bleed into areas we do not want!(Think point and spot lights that has special light volume to avoid bleeding to adjacent rooms) Adding on to that, as mentioned before, this technique do not suffer from the camera in light volume glitch. Obviously there's always a catch when things look so good. The fact that we have to turn off backface culling during the stencil pass means that our stencil rendering is more expensive.

Phewh~ this is a long topic and I'm still not done yet. To think most reference slides describing these methods I could find online discussed them in two slides. O_O Anyways, to conclude for this post, I've outlined two methods that I will integrate in our deferred lighting pipeline. My next blog post will talk about when I would use them. ;-)

Deferred progress 4

2010-03-15T08:09:00.000-07:00

I have completed porting directional shadow casting and refraction to the new system. This means we now officially have all the original features running with a deferred lighting renderer. A test run with all features on (single shadowmap, HDR and Refraction) got me an average of 40fps at 1024x768. Overall, that's pretty much a 10fps dip from previous test. This is mostly due to the shadow casting cost which shows how expensive shadow rendering is. I'm a bit disappointed with this since it makes PSSM useless even on fast machines. I'm planning to have a way to allow artist to define non shadow casting batched entities in the editor to narrow down shadow casting to where it matters. Hopefully this will improve shadow casting performance.

Aside from that, I've also changed the depth G-Buffer format into PF_FLOAT16_GR to add one more channel for material ID. I came to the conclusion of needing this due to the limitation of any deferred renderer which is having different materials with different lighting properties. The main reason I added this functionality so soon was that our tree leaves and grasses are using custom shading. This limits us from utilizing the deferred lighting system to lit them. It would be fine for the first level since there's only one light through the whole scene. However, we have plans for night scenes in the future which wouldn't work very well then. Hence with material ID introduced, the custom shading for leaf and grass is now done in the deferred stage. Obviously this potentially allow us to extend it even more into other types of materials like cloth.

Unfortunately since we are trying to limit the G-Buffer's fatness, we're limited with the number of channels we have to store data. This means that any material type that requires extra info cannot be integrated. Unless we introduce 64bit buffers, this is not possible.

At any rate, with this done, our artist can now happily do outdoor night scenes that has lights affecting grass and tree leaves. My next move is to get the major feature of deferred lighting in: spot and point lights. Since this blog post is already getting long, I'll leave my local lighting thoughts to my next post. So stay tuned. ;-)

Deferred progress 3

2010-03-08T11:15:00.000-08:00

I finally got to the stage of being able to render our first level using the deferred lighting renderer. It is still not complete yet however. Only the default materials required for level01 has been updated. Also, due to this changes, refraction needs to be redone in a different approach.

Along the way, I actually hit a few problems. First one was due to my mistake. When designing the G-Buffer, I assumed I will be able to construct the lighting pass with just the depth and normal. I was wrong. I needed the specular power value as well. Hence, I had to go back to the drawing board again and decided to go for the least accurate model of R8G8B8A8 where we store compacted view space normal map in the RGB channel and spec power in the Alpha channel. Interestingly, it turned out pretty good. So much for the "not accurate" crap mentioned in the CryEngine3 power point presentation slide. Personally, the inaccuracy is not really distinguishable. Besides, with proper good textures provided by artists, this small error isn't really a big deal; especially considering that we are not trying to achieve realism. What we want is beauty and style. :-)

Another of my issue was the way Ogre did its rendering. For every render target, Ogre would do a scene traversal to find all visible renderables and render them. This I found unacceptable. Reason being that it means Ogre would traverse the scene at least twice; First being G-Buffer stage, second being the final compositing and forward rendering stage. This is a waste of cpu resources hence I ended up listening to the render queue event during the G-Buffer pass and keep my own copy of all queuing renderables. Then I manually inject the render queue during the final compositing stage with a custom subclassed SceneMgrQueuedRenderableVisitor that tries to refetch the right material technique base on the new material scheme.

And the end result? I had our first level running at ~40-70fps with an average of 50fps at 1024x768. This is with HDR on but without Shadow. Not too bad for a crappy 8600GTS.

Oh, one thing interesting to note is that since the G-Buffer stage does not require much texture sampling, it actually renders really fast. That being so, and because we keep the Z-Buffer intact throughout the whole process, we actually gain some performance during the final compositing pass due to early Z-out. So you loose some, you win some. :-P (In theory, if you do a pre Z-only pass before filling the G-Buffer, you might speed up more if your scene is complex. But it will also increase batch count. So I'm not too sure if it's worth while.)

Unfortunately for us though was that because we did not planned to have deferred lighting from the start, we had to abide by some bad decisions done in the past. One notable issue was that our G-Buffer stage requires the diffuse, normal and spec map in the worst case scenario. This is because in the case of an alpha-rejection shaded material, we need to sample the alpha channel of diffuse for alpha-rejection, and specular power from the spec map. This means that we are sampling at least two textures for each material during the G-Buffer stage. This is not ideal as we should try to sample as little textures as possible in this pass.

That said, if I could fix this, I would make specular power part of the normal map's alpha instead of in the spec map's alpha; making only one texture sampling needed typically in the G-Buffer stage. This would also leave an extra alpha for reflection factor in the spec map for envmap reflective materials; which would be a win win solution(less one reflection factor texture map). Sadly, we're already a long way in art asset creation. Changing this now would mean loads of work fixing the old textures and materials.

Deferred progress 2

2010-02-25T06:51:00.000-08:00

I've begun working on light buffer generation. While tackling this, I realized my normal buffer generation isn't accurate. I'm using the view space normal compressed with only XY where Z is reconstructed. While using 16bit float keeps accuracy pretty well, we loose the Z's sign info and this does not bode well for us. The reason is that while for the most part Z is always positive facing, there is bound to be edge cases where it is not. Especially when we are using normal map to distort a surface's normal. So I begun a search to find if I could improve my normal buffer rendering. To my surprise, someone by the name of Aras did the homework for me. Thanks Aras! :)

Just so you know, I'm not a math junkie. So deciphering what was done within that page took me quite a good while. That said, I decided to pick two method out of the selection to test out; Stereographic Projection and Cry Engine 3 method. From what I understood, Cry Engine 3's method sacrifices the X, Y's accuracy for a very good Z value. Comparatively, Stereographic Projection produces more even distortion. However, since we're using two channel 16bit float g-buffer format, both data loss is pretty insignificant. After some testing, I came to the conclusion that both method produce almost 100% similar lighting. The difference is unnoticeable to the naked eye. Hence, I decided to use the cheaper of the two, which happens to be Stereographic Projection.

So.. Normal G-Buffer fixed!

Now, as we know, shadow casting is a very expensive process. So for the most part, we would want to avoid shadow casting. However this leads to one problem; light leaking. Given a light in a room, if light is not applied with shadow casting, the light will leak through the wall into the adjacent room. This becomes an ugly behavior. So how does one fix this? When using forward rendering, we had the flexibility of doing selective light masking. This worked very well for the case mentioned, but how do we bring it to the deferred model? From what I see, my best bet is to use the stencil buffer. However, I'm not quite sure how cheap stencil buffers are. From what I read, clearing stencil buffer is expensive. Also, stencil depth is only 8bits for any modern cards (being that the other 24bits are for depth buffer). Also, for fillrate optimization, we would want to mask out the depth bound of lighting volume for each local light we render. Hence, that would take up 1 bit of the stencil buffer, leaving only 7 for light grouping.

I am not familiar with stencil buffer and do not know exactly what kind of cost it would impose on rendering. But writing and switching stencil ref value during the G-Buffer rendering phase seems scary to me. I will have to keep setting the stencil ref value for each Renderable being rendered. From what I gather, the best way for me to implement this is to add a RenderObjectListener during the G-Buffer render state, then set the stencil ref value for each renderable in the callback. Then after G-Buffer mode is done, remove the listener. However, there is one issue with this. Since the callback is dealing with Renderable, I have no way to find out the light mask for that Renderable since the light mask is set in the MovableObject. As of now, I have no clue how to handle this.

Deferred progress 1

2010-02-24T01:03:00.000-08:00

I started working on our deferred lighting / light pre-pass / semi deferred / or whatever you wanna call it renderer. Right now, all it does is just generate the appropriate G-Buffer.

As simple as it looked, it wasn't so for me since our engine have pretty complex mix of custom materials. I had to restructure the way we sort our render queues to filter out unwanted meshes from the G-Buffer pass. One draw back of our current system was that our models consist of both shaded and unshaded materials; E.G. Buildings with holographic ads. The other was the AO boxing overlay that shares vertex buffer with the mesh that is being overlayed. So in the end, I had to hijack them away during the renderableQueued() callback stage. This method feels ugly though. Unfortunately, I can't think of any other way to solve this. Especially since the problem is mostly about filtering submeshes, so there's no way to use the visibility flag in Ogre.

Nevertheless, it's done and I'm beginning to see how to build this renderer in the most optimum way possible(in Ogre). I must admit that the reason why I am working on this now is all thanks to the Ogre dudes. Without the recent added features, I probably wouldn't be working on this now. So lemme give my thanks to Noman and dark_sylinc for making this possible. :) Oh, I should also thank Google too since they technically funded Ogre's compositor improvement.

As always, I like posting some graphics since I'm a graphics person. So, without further ado, here they are:
G-Buffer normal:

G-Buffer depth:

and since the depth buffer looked so strangely satisfying, here's two more just for kicks.

Don't you think they set the post-apocalyptic mood? :-)

A light deferred approach

2010-02-19T03:21:00.000-08:00

As we progressed with the building of our second level, we hit one major issue with our rendering solution; lights. Since level 2 is an underwater level, it requires tons of lights to set the mood. Our current rendering method is a forward rendering system. This means for each mesh lit by a light, an additional pass is needed to draw the affected mesh. This becomes a problem as the GPU will be re-rendering meshes for each light.

To solve this problem, most games uses pre-baked light map for this case. However, we opted not to rely on this method as our tool chain is designed for more dynamically build levels (Levels build with prefabs put together). Also, we prefer to have a dynamically lit scene where we can freely move lights around. We believe it actually would save us more time compared to baking lighting which will only slow down the level building.

Having said that, I've decided to tackle this problem the deferred way. However as we know, full deferred renderer has many caveats. They're problematic with different materials and expensive due to sampling of 4 render targets per light. Thankfully, there appears to be a simpler method known as the light pre-pass rendering method, introduced by Wolfgang Engel.

The light pre-pass renderer basically does a lighting pass that accumulate all lighting to a light buffer without the diffuse/albedo part of the scene. The idea is to use less render textures (RT) hence less texture sampling during the lighting stage.

So I began to draft out how I would build my G-Buffer and handle the rendering pipeline.

Bellow is how I plan to layout my G-Buffer:

Note that RT2 is optional and only generated when we want to have full scene motion blur.

Then, to implement the light pre-pass rendering pipeline into our existing shading pipeline, this is what I'm planning to do:

An interesting thing to note is that this method does not incur much extra memory compared to the deferred approach. In fact, the additional memory required for G-Buffer is pretty much already a required memory size when enabling refraction in our current pipeline. Hence, refraction effect pretty much becomes almost free in terms of memory needs.

Obviously this is only just one side of it. On the other side of things, we actually need a light buffer and this is where things start to cost more. For the sake of HDR, we would need to use PF_FLOAT16_RGB or PF_FLOAT16_RGBA. Both format here is actually a 64bbps format which means double the cost of the normal render buffer. For an accurate lighting model, we would need two render target. One for N.L phong lighting, the other for N.H specular lighting. So we would impose extra memory requirement to build a perfect specular lighting model. Annoying. Hence, I'm planning to have an approximate specular mode where we only keep specularity as a luminance value. This way, we only use one light buffer and we leave the specular colour lit base on diffuse light and the material. It shouldn't look too bad I hope.

Aside from that, this new method does introduce a problem. The opaque part of the scene has to be rendered twice. Once for filling the G-Buffer, and second time for the actual material and light composition. This basically means that the initial rendering would not be faster compared to our forward rendering approach. However, it will impose very low cost to having additional dynamic lighting. Personally, I hope this is a correct direction to head for. I do know cards in the range of 8800GTS (which is medium range by now) can handle this no problem. However, lower end cards would suffer, E.G. 9600GTS - which is what I am using for testing. It's already trudging along with all features on at 1024x768 doing 30fps or less which is bad for a racing game.

The Gamer's Hub Developer Interview

2010-01-26T18:15:00.000-08:00

Hi guys, heres an interview on Liquid Rock Games by Anthony of The Gamer's Hub.

http://thegamershub.co.uk/2010/01/developer-interview-liquid-rock-games/

Thanks a mil Anthony ! :D

Forcefield with refraction test update 2

2010-01-26T09:59:00.000-08:00

An update to the underwater track forcefield with refraction.

300k hits to LRG website!

2010-01-20T04:20:00.000-08:00

Looking back since the first Liquid Rock Games website was first created. We have had over 300k views to our website. Thanks a mil guys for checking out our site. Lets push for 1 million views with Aftershock's release!!

New members to LRG !!

2010-01-19T09:09:00.001-08:00

We would like to welcome our latest addition to the team. MD as our game artist and Pang Lih Wuei for additional game programming for Aftershock ! Welcome aboard guys.

Underwater Track Forcefield test

2010-01-15T08:23:00.001-08:00

Heres a forcefield test for the undersea track to keep the seawater out from flooding the tracks.

Event Scripting and computer troubles

2010-01-15T00:36:00.000-08:00

I've got the basics of event trigger to script working. With this, we can now easily trigger AngelScript code from our C++ event delegate system transparently. However, due to the requirement of knowing about the existence of AngelScript component, C++ events would need to use a specially subclassed scriptable event object. But aside from that, triggering of events from C++ does not need to know about the script bound delegates. This is a big plus to our engine as it means we can fully utilize scripts for in game logic base on event triggers.

Out side of the coding development, I had a bad situation yesterday. For some odd reason, my house's power went nuts leaving all the power points malfunctioning for a few hours. Oddly enough, after trying in vain to go out to look for help, I come back to find it working again. But two things went wrong after that. Firstly, my computer went bonkers with the display flickering and goes black every time I logged in. Secondly, the switch hub I'm using died.

It took me the whole night trying to figure out what's wrong with my computer. Trying to find the culprit was a pain in the ass. Had to switch to safemode and normal mode alternately for a bazillion times. x_x Thankfully it wasn't any hardware issues. After downloading a new display driver, it got working again. Sheesh, talk about weirdness. But now I can't connect it to the internet since the switch died on me.

Ah well, sigh... wasted a day's worth of work. I need to go get a new switch. Yet another unexpected cost of indie game development. !@$!@$!@#%!

Happy New Year !!!

2009-12-31T07:20:00.000-08:00

LRG wishes everyone a very happy new year 2010 with more development goodness coming in the year ahead !!!

Official Aftershock website

2009-12-16T17:03:00.000-08:00

Just released Aftershock's own official page:

http://aftershock.liquidrockgames.com/

Will be updating it with more content to come in the future.

LRG wins Most Promising Start-up Games Studio

2009-12-09T08:02:00.000-08:00

Just won the Most Promising Start-up Games Studio at MSC Malaysia Kre8tif! Digital Content Conference. A million thanks to the judges and the organizers for this award. We PROMISE to continue to innovate and continue push tech for our future games as much as possible.

Holographic advertisement projector prop

2009-11-26T18:39:00.001-08:00

Lamp post prop

2009-11-18T07:39:00.001-08:00

Broken lamp post prop.

Track node update

2009-10-28T19:51:00.000-07:00

Track node editor has finally been completed with ability to define checkpoints for race route. I did a real world test with our first level and successfully defined the whole track without any issues. :D Yay! It's a bit cumbersome to use though since we don't have a proper UI. Our level editor as of now truly requires a pro. lol.

Anyways, for some eye candy shot to please our fans, here it is :D

Facebook URL

2009-10-22T02:11:00.001-07:00

Just changed our direct facebook URL to: http://www.facebook.com/LiquidRockGames

Booster pads!

2009-10-20T07:57:00.000-07:00

The name speaks for itself.

includes: parallax mapping+animated glowy parts.

More misc screenshots

2009-10-14T09:55:00.000-07:00

of the ship interior this time with a work in progress racing track:

Teleport effect

2009-10-13T07:57:00.000-07:00

While waiting for my code to compile, I started thinking how we want to do re-spawn effect. Blinking the player craft directly into the track is downright ugly. Hence, I thought having some teleporting effect would be cool.

Here's what I got after a few minutes of hacking into our already crazily mega shader.

Imagine that + some particle effects. :D However, it'll still take a while before I actually get this into the game. I need to work on an effects system to easily apply custom effects to the scene.

Track node editor

2009-10-12T15:30:00.001-07:00

Over the week I've been working on a very important feature; Track system. The need for this system was due to requirements of a racing game. In a racing title, we need to know if our player craft is inside or outside of the track. We also need to know how to respawn back into the track. Last but not least, we need to have a way to know if a player has finished a lap.

Thus the track system come into place. With a way to define tracks, all of these will be possible. What's even cooler is the ability to give a good estimate of how long a track level is. :)

However, the problem lies in defining the track. Because it's impossible to do it outside by text file, we need an editor to lay our tracks. This turned out to be quite a pain in the ass to implement. In fact it's more complex than prefab placement since we need to link tracks together to form a track chain.

Anyways, I've finally got a usable editor tool in our world editor.

Here's a screen shot of this WIP track edit mode:

Ignore the lighting. The main point is the track. Obviously lighting is just default crap since I created a new level just to test this in a quick manner.

P.S. For those who are wondering, I'm using cubic bezier curves for each path segment. Thanks to my bro, we've got quite an advanced bezier curve functions like getting arc length, finding closest point on path and splitting a set of points evenly along the path. Trust me it's no easy feat. Requires lots of integration maths and Newtonian Interpolation. That plus our rusty math, this took us almost two days to figure out. :P

Twitters!!!

2009-10-10T23:57:00.000-07:00

Catch us at our official Liquid Rock Games Twitter site! Live updates ! Rants and raves !

http://twitter.com/LiquidRockGames

Digital Distribution Summit

2009-10-10T04:03:00.001-07:00

Must watch for indies looking to go the digital distribution route.

Digital Distribution Summit - Sandra Sdraulig Opening & David Edery Keynote from Digital Distribution Summit on Vimeo.

US court says software is owned, not licensed

2009-10-09T19:59:00.001-07:00

Finally about time. Read the article here.

Ship interior update 4

2009-10-08T10:41:00.000-07:00

Here's an update on how the ship interior looks like within the level editor plus detail maps with some test lights. no ambient occlusion map yet though as the model is not fully completed yet. Lighting will be further tweaked when the entire track is set up and finalized.

update: 10/10/09 Tweaked the lighting abit for more contrast in the scene to make the middle part of the track stand out more plus added colored specularity maps.

Ship Interior update 3: Lighting tests

2009-10-01T09:53:00.000-07:00

Here's a rough lighting idea for this part of the track to convey the feeling of a dark and dank environment. Image rendered in Blender3D. Will be destroying parts of the interior later on.

mini update (6/10/2009):

Started destroying parts of the ship's interior. Will be working on the racing track soon.

Ship interior update 2

2009-09-30T08:57:00.000-07:00

Here's a Blender3D render on a partially textured ship interior. Will be adding additional detail using detail maps once in game to enhance the details.

error C1083 Not enough space! O_o

2009-09-24T12:29:00.000-07:00

[begin rant]
Man, this sucks. Just as I was getting into more fun, VC hits the brick with our core framework static lib hitting the roof for file size. It's now at 600++mb O_O. Really sad... I couldn't link the editor with it anymore.

Guess I have to turn it into a standalone dll. Hope this will solve the issue. Woo hoo.. more dlls! Sheesh...
[end rant]

About what I'm working on, I'm building a track system to define what's an inside of a track and what's out. This system will be able to help detect when a craft falls out of the track and be re-spawned properly back in the track. It also will serve as checkpoint system. Two birds with one stone. v^_^v

Ship interior update

2009-09-15T21:19:00.000-07:00

more shots of the low poly ship interior track before I start working on the high poly version.

Ship Interior Track WIP

2009-09-11T22:17:00.000-07:00

Started modelling on a racing track through a massive sunken ship interior where players get to navigate through the ship's massive malfunctioned engines.

Sunken Ship Update 3

2009-09-04T07:06:00.000-07:00

Lossy floating point compression

2009-09-02T23:21:00.000-07:00

I've finally fixed the problem with my float compression. Just to note, the compression technique is following the IEEE standard somewhat. I forgot to deal with normalized values (-127 exponent) which made the compressor generate garbage.

If anybody is interested on how I compress, just have a look at how halffloat(16bit float) is stored. I'm pretty much using similar technique. Basically discarding some precision on the fractions and shifting exponent bias for more floating point precision at smaller values. (Note that I'm making it very specialized for delta type compression; meaning the closer the value is to zero, the more precise, the bigger the value, less precise.)

Aside from this, I found out that the compression worked really well even for important objects like player controlled entities and camera. Thanks to Glenn's article describing exponential smoothing, as long as I don't snap when compared values are very close, things worked very smoothly.

I'm very happy with the result thus far :) Next up is actual multiplayer race! Woo hoo!

Network syncing!

2009-08-26T21:42:00.001-07:00

After countless hours of sleepless nights, I finally got it going! Smoothed network physics simulation will little noticeable jerks. Yay! However, this is only for the LAN. I'm not sure how it will fare with the internet where latency isn't our best friend.

It took me a while to figure out that I had to synchronize the physics time frame and not the system time frame. Top that off with bad timing for the network syncing right after physics simulation was done, I was having a lot of headache beating around the bush for naught! Sheesh...

Aside from this, I'm having issues with float compression. Somehow it's giving weird values that leaps all over. Probably something wrong with the way I compress and decompress. While on this, I wonder if I should have some way to mark significant objects for non compression mode? How does other games normally does it anyways? Do they like make important objects like controlling player to always sent in non compressed mode while other non controlling objects get compressed mode?

A sunken LNG Carrier

2009-08-22T03:39:00.000-07:00

Sunken ship props

2009-08-14T09:12:00.000-07:00

Started working on some sunken ships which players can view along the tracks.

More network goodies! :)

2009-08-12T17:59:00.000-07:00

Finally something worth blogging. I've got the game networking with input syncing working like a charm. Yahoo! Looks like my action system is doing a fine job. :)

Right now I've all client players sit as observers on the server's craft. While the server is controlling, the clients get the input as well. However, since I've yet to do any entity syncing, the craft on the client screens start to steer off into parallel dimensions. lol.

Either way, it's nice to see that my hard sweat Action system is working like a charm. Very excited now. :P Entity syncing here I come!

P.S. Sorry, no pics for networking. I can't think of any creative way to represent them with pics anyways.

Ramen Shop Games & Network update

2009-07-31T03:47:00.001-07:00

I got this link from my sensei classifying our company business model as the Ramen Profitable. Rather funny name. So now we're noodle shop guys. lol
http://paulgraham.com/ramenprofitable.html

On the side note, I've just managed to get two PC linked together and entering the game. No game syncing yet. That's to be done after this. :)

While getting this done, I implemented a system I called delayed sync messaging. This system basically utilizes the time sync method I mentioned here. The concept behind this system is so that one can accurately synchronize a particular event that needs accurate triggering. For example, the beginning of the race, count down should be as synchronized as possible so client don't get a laggy start.

When dealing with this type of events, the only caveat is that the server side also have to synchronize with the client side. This means that the event has to be delayed as much as possible as such that all clients will get the request before it is triggered.

In a LAN environment, this usually isn't much of a problem because the ping rate is rather high; less than 1ms to 10ms. However, in the Internet scale, latency can go as high as 500ms to 1500ms or more. In that situation, time syncing becomes a necessity to accurately identify the server time.

I haven't really tested the time syncing algo I've implemented in the Internet environment yet. However, in theory, it shouldn't go wrong.. I hope... :-P

Sneak Peak:

Don't mind the UI. It's just programmer art to keep me going. ;-)

Scripting engine

2009-07-18T00:03:00.000-07:00

Ah.. time sure flies. Just to update, I had been busy putting a working network prototype together.

While doing so, I've also did some research on scripting to ease up game logic coding later. I was thinking of using V8 at the beginning. However after digging it through, I realised that it was designed to only run on a single thread (Google Chrome is designed as a multiprocess app instead of multithreaded app). So in the end, I'm back to square one of using Angel Script. It looked like it has evolved since my last use for it when I was still in my previous game company.

P.S. I did look at spidermonkey too. But getting from their source tree is a little troublesome with my ever so crappy always disconnect ISP. So I dropped it. Mercurial really sucks without the auto resume feature.

Multimaterial test

2009-06-19T01:26:00.000-07:00

Here's a multi phong material test for a submerged building overrun with coral and other sea plant life.

Close up on the building surface. Includes parallax and ambient occlusion map.

More buildings...

Seabed props

2009-06-17T23:00:00.000-07:00

Just completed some seabed props(dead coral collection) mainly to be used to add extra details to the seabed track. Also to be used as track obstacles.

More dead corals !!

2009-06-15T13:06:00.000-07:00

Another test for corals+parallax+ambient occlusion mapping. Will be adding paging geo coral meshes for added details later.

Dead corals.......

2009-06-12T11:33:00.000-07:00

Parallax mapping test on a sample dead coral mesh.

Misc screenshots

2009-06-11T21:17:00.000-07:00

Just thought I'd post some test screenies with a simple seabed mesh. Will be adding more details like rocks, debris to it later.

Track structure update

2009-06-10T10:15:00.000-07:00

Heres an update on the completed low poly model with textures in the level editor.

closeup pic:

Track structure

2009-06-03T02:40:00.001-07:00

Just completed the hi poly version of this track structure which is basically a huge shield barrier which prevents sea water from flooding the tracks.

Bridge Support

2009-05-31T21:05:00.000-07:00

Just completed some support structure for the track. Players would be able to race through them as they race on the seabed.

3.. 2.. 1.. Action!

2009-05-22T03:17:00.000-07:00

Interaction system. It's funny how the simplest and most important piece of a game engine could be so difficult to design. If there's no interaction, then there's no game at all. Hence, a game engine MUST have a unified way to deal with interaction.

When talking about interaction, input controls come to mind. Keyboard, mouse, gamepad or even those driving force feed back steering wheels. These controls would be bound with the in game characters, crafts or even turrets.

However, here lies the question. What about characters, crafts or turrets that are not controlled by the player? AI comes to mind. Better still, what about replays? Or how about in a multiplayer environment where certain crafts are controlled by some other players over the network?

These scenarios shows one thing. A controller that controls any element in a game should be abstracted from the physical input devices. They should only care about what to simulate when a certain command is executed without needing to know who is executing it.

Hence, I came up with what I call the Action System.

As you can see, the core of an Action System lies in the ActionManager. It will manage a list of action controls. These action controls are basically action devices(in red) bound to a controller(green) through what is called an ActionMap(blue).

Action devices can be anything that handles action inputs. It can be a real input device(keyboard, mouse or gamepad), AI device, Replay device or a Proxy. A proxy device is simply a device that clones whatever the true controlling device's(Owning devices) state. The proxy device is meant for network use only.

Bellow is a rough idea of how it would look like in a network environment with two clients connected to a server.

Now, the underlying structure of an ActionMap holds the key to how one interacts with a controller. It holds a list of actions that defines what is a toggle button, what is an analog axis or even a world vector for FPS styled games.

Having that, the next complicated one is the physical input. How does one bind a physical input to the ActionMap? Here's how I devised it to work. An action input device will hold a list of InputMaps. These InputMaps basically defines the bindings of the input to an action in the ActionMap. This design allows the designer to constraint what input type an action should use while allowing the players the freedom to define their own input within that constraint.

To cap it up, bellow is how the InputMap and ActionMap interaction will look like for an FPS.
Note the vector action doesn't have a direct input from the InputMap. It instead receives it's input from the controller that calculates the look-at of a player through the mouse axis input.

That's it. Next up I'll be talking about buffering the ActionMap for network prediction and Replay. Stay tuned. ;)

Track variations

2009-05-22T02:14:00.000-07:00

Just started working on different track variations. Heres a couple of destroyed track pieces.

Completed holo barrier model

2009-05-19T02:39:00.000-07:00

Heres the completed holographic road barrier.

Re: Holo Barrier Projector

2009-05-17T09:34:00.000-07:00

Wasnt too fond of the last holographic projector model. Decided to rework on a new design. Based on normal concrete road barriers but with a futuristic design.

Holo barrier projector

2009-05-14T02:46:00.001-07:00

Heres a hi poly version of a holographic "no entry" barrier to block players off certain paths for the 2nd level theme. Will be working on a low poly version soon.

Network time sync

2009-05-11T03:20:00.000-07:00

Time synchronization is very essential to a network game. Though for the most part, what I've read about realtime network games tend to not bother. But what they do bother was implementing client prediction to compensate network latency.

I suppose it's quite acceptable to use enet's rough estimate of round trip time. But I believe if we can improve the estimation of server client time difference, the client side prediction would be more accurate. Besides, getting a good estimate of time synchronization only takes up the first few seconds of a connection. So it's worth doing it. :)

The time sync i'm planning to implement is from this article: http://www.mine-control.com/zack/timesync/timesync.html

Though the design of time syncing is more for RTS styled network, it should still be very useful for realtime world snapshot based network.

However, implementing this time syncing algorithm requires that the internal logic code respond to the network as soon as possible. Any delay due to application layer will only jeopardize the quality of the time syncing. This being the case, I need to poll enet in a separate thread from the main rendering thread. That way, I eliminate the delay caused by any main thread's busy logic and also the beloved monitor vsync.

Then from this polling thread, whenever there's a new incoming streaming enet event, I immediately push them to the streaming thread. This gives me almost immediate event receiving for the streaming system. That way, I could implement the time syncing using the net streaming system which is a good thing. :)

However, I still need to pass normal messages back to the main thread. For that, I used a lockless queue system to queue the event messages back to the main thread without any need to do mutex locking. That means less expensive threading. Yay!

I've only just got this part compiling. Not tested yet. Hopefully it'll work. :P

P.S.
By demand, here's a list of articles I'm referencing when designing my network system:
http://fabiensanglard.net/quakeSource/index.php
http://trac.bookofhook.com/bookofhook/trac.cgi/wiki/Quake3Networking
http://udn.epicgames.com/Two/NetworkingArchitecture.html
http://developer.valvesoftware.com/wiki/Source_Multiplayer_Networking
http://developer.valvesoftware.com/wiki/Networking_Entities
http://developer.valvesoftware.com/wiki/Lag_Compensation

P.P.S
Oh, i forgot to mention about the net streaming system during the last post. Just a quick cap, the net streaming system is a way to write synchronous network protocol in a separate thread without interfering with the main thread. This works very well for stuffs like handshake and file streaming. ;)

Lf3T-Hn4D out.

Game investment talk by Matthew Le Merle

2009-05-07T23:14:00.000-07:00

TriplePoint Speaker Series: Matthew Le Merle, Chairman of Mindfuse from triplepoint on Vimeo.

Network beginnings

2009-05-07T10:04:00.000-07:00

I've got basic networking done. Now the game engine deals cleanly with connection handshake and network command messaging.

These two feature is essential for the game. Handshake exist such that verification between server and client must exist when initiating connection. This will allow server to verify if the client is the actual Aftershock game client and not some other random app who so happen to use the same port number. It also filters bad version matches so only game binary of the same version can connect. Last but not least, it also deals with filtering of conflicting user names.

Eventually, this system will be extended to authenticating with our central server for validating users in online play. :)

The second system which is network command messaging acts as a way for two computer to communicate and send command to each other. This is important for world synchronizing where the server needs to tell clients to spawn objects, shoot some fireworks, trigger some sounds, or even send chat messages.

Unfortunately, network is not as nice as graphics. There's nothing flashy to show even though the underlying part is a masterpiece. :P So no screenies for this post.

But one thing I must say before I end. I'm glad I planned for network when designing the engine. Writing a single player game engine and a network multiplayer game engine is two totally different thing. A single player game engine can never be enhanced properly in a multiplayer environment. I'm glad to have so many reference articles by Epic, Valve and id-Soft for puny little me to refer to. :) Gotta love living in this era. :P

Next up: Time synchronizing :)

Making of: Game Art for Project Aftershock

2009-05-05T08:16:00.001-07:00

Catch the making of game art for Project Aftershock in Blender Art Magazine Issue 21: Look What I Can Do! page 31

Download link here : http://www.blenderart.org/issues/

More lighting screenshots

2009-04-29T22:22:00.000-07:00

Been busy building more track varieties and adding new lighting solutions for our next level where there will be no sun light to light up the scene. Next step would be adding lightmap for smaller light sources whereby majority of the scene lighting will be lit up using real time lighting.

Votes needed to help Gamers Daily News grow

2009-04-16T10:39:00.000-07:00

Hi guys, just wondering if you guys could help out our friend, Christopher Rick, Editor in Chief for Gamers Daily News (http://www.gamersdailynews.com) win the business grant from Intuit to help grow Gamers Daily News which helps and features indie developers such as ourselves here at Liquid Rock Games.

All you need to do is log in and vote for the article below:

http://community.intuit.com/contests/ckb0mEE_yqllvkab8P4pmk#bottom

All help will be greatly appreciated! Thanks!

Project Aftershock on Indie Game Mag issue 4 May/June 2009

2009-04-15T10:15:00.001-07:00

Liquid Rock Games Launches Developer Diary Exclusively at Gamers Daily News

2009-04-15T10:11:00.000-07:00

Special thanks to Christophor Rick,Editor-in-Chief for Gamers Daily News.

Liquid Rock Games Launches Developer Diary Exclusively at Gamers Daily News

http://www.spawnpoint.com/news/14270/Liquid_Rock_Games_Launches_Developer_Diary_Exclusively_at_Gamers_Daily_News

And Lf3T-Hn4D says... Let there be lights!

2009-04-14T09:34:00.000-07:00

And there was lights:

Yep, that's our new quick addition to our wonderfully already hyper complex shaders. Not everything receives them lights yet though. Right now, only solid phong objects receives lights.

It's a per pass lighting system though. So it's not very efficient. I wish I could do deferred shading. Sigh...

Ah well, whatever. Better get this done fast and continue on my network coding.

New official youtube channel

2009-04-07T09:24:00.001-07:00

Just created our own official youtube channel for Liquid Rock Games. All future vids will be posted here.

Liquid Rock Games Youtube Channel

So dont forget to visit and subscribe today !

Also an updated vid of the first track environment. The next video will feature gameplay elements.

Texture atlas set test

2009-03-31T12:18:00.000-07:00

Here are the new texture sets for the floor track . replacing the old one. There will be some transparent parts showing off piping running through the track floors. Will mix n match parts of the texture atlas to create more floor pattern varieties.

Smoothness and frame rate independent

2009-03-30T02:24:00.000-07:00

Ahh... I finally got it quite right. Few days back I was trying to tackle frame rate independent physics. Sad to say, bullet physics as nice as it was, was horrible at interpolation. This is due to it doing extrapolation instead of interpolation which didn't work very well with force intensive physics (Having multiple forces applied to an object at each simulation step).

The reason for interpolation/extrapolation of physics is so that physics can be simulated at a fixed time step to maintain stability and determinism. This means that given an exact state of an initial physics world, the simulation will always end the same way with the given fixed input in any number of tries. However, as frame rate is not in fixed time step and can fluctuate depending on cpu/gpu performance, interpolation/extrapolation was introduced to provide "smooth" graphical display.

The sad part about bullet though was that it's doing extrapolation. In layman term, this means predicting into the future. In some sense it's correct if you think about each simulation is a few millisecond behind the current rendering frame. But it causes horrible jerks due to the prediction.

Hence I went and dig through bullet's source and modified it to do backward interpolation or I should say "true" interpolation as described here: http://gafferongames.com/game-physics/fix-your-timestep

After this, I managed to get good frame rate independent simulation which helped a lot on my machine where fps fluctuated around 30 to 60. All was nice and dandy until we tried it on the faster 8800GTS and 9800GT cards. It was giving horrible jerky motion due to fluctuating fps of 58 to 60. Thanks to Ogre for providing the frame smoothing feature. After turning it on and tweaking to a good enough value (0.05 - meaning average 3 frames at most), we got pretty darn smooth simulation. :)

But there were still some vital pops and jerks once in a while due to paging geometry. In the end, I had to crack my head and totally put all processing of paging geometry stuffs into the background thread. That solved almost all jerks and pops. :)

I think I'm happy with what I've achieved thus far. Now I can focus on network and scripts. FINALLY!

P.S. I'll be posting up a patch to bullet for that interpolation feature once I get enough time. I didn't remove the extrapolation technique. Just #defined them so users can switch between them when compiling. I think they should really embrace this method as the default though. It works a lot better for visual side of things even though it means visual is slower by 1 frame.

Exhaust flames

2009-03-29T00:07:00.000-07:00

Still screenshot of the exhaust flames coming out of the crafts engines. Looks alot nicer when the flames are in motion. Will be needing some refraction particles to simulate heat waves. Vroom....

Refraction update

2009-03-28T23:52:00.000-07:00

Here's an update on the refraction effect for flowing water coming out of drain pipes. Will be adding some particle effects for water splashing a little later. Player would be able to turn it on and off later in game if this effect is slowing down their framerate.

With refraction

Without refraction

Level 2

2009-03-27T10:19:00.000-07:00

Started working on the next track theme with the first building blocks.

Blog comments fixed!

2009-03-25T07:06:00.000-07:00

L3ft_H4nd finally got the blog comments working ! after many complaints bout the broken post comment link.

Refraction!

2009-03-18T14:49:00.000-07:00

Tada!

I know, I know.. Not the best shot to be proud of. But its the best shot at showcasing every single graphical feature we have in our game right now; HDR, Refraction, Shadow, Paging Geom, Baked AO (somewhat like light map but independent of light source), fuzzy holo and lens flare.

Yes, this post is more about the refraction than anything else. Getting refraction up was a real pain. Took me a few days of frustrations and hitting Ogre bug(s) before I got it working more or less. The FPS isn't too happy on my machine though. 8600GTS just doesn't cut it for such fillrate intensive feature. I'm getting about 40-50fps when every feature is turned on (shadow at lowest setting). I've yet to test it on the more powerful 9800GT, but I bet it'll be blazing fast. :)

The trick behind refraction is that it's a postprocessing feature. Thanks to Ogre's nifty compositor system, It allowed me to build this pretty much from a simple compositor script and a handful of materials and shader files.

What I did was basically tell compositor to render the scene in what I call the refraction pass. What happens here is that instead of rendering the scene with the basic materials, we render them with special refraction materials which sets the refraction and depth info into a temporary render texture. This is done by ordering the compositor pass to use a custom material scheme.

After this is done, the render texture is then used to distort the real scene texture base on the offset and depth info. Not too complicated. :)

However this technique has it's quirks and problems. Attempt at using it for effects like stained glass results in ugly distortion of the tinting. Stacking them up over one another will most definitely turn it into a muddle of crappy distorted glasses.

Still, this effect has it's use in many other cases. For one, we intend to use it for simple water based effect like the shot above. Uh.. yeah, it's not going to look like that, I'll be changing it to the proper shader later. :P

The second effect, which we will be using a lot, is heat haze and shield distortion. This will definitely spice up things. Hehe :D

Aside from this, there's still more to deal with. To get this working I had to work around a problem with the PCZSM(portal scene manager) that I was using. It was a bug that causes compositor to not function properly. I've yet to figure out how to solve that. Hopefully I can solve that soon and move on. There's already tons of things in my todo list and it's piling up! :(

That's it. I'm done. Shader programming should be a full time job. Sheesh.

P.S. I know I didn't really properly explain the whole process of the refraction shader. But I'll leave that to the imagination of any reader who intends to add refraction into their system. :) It's not that hard to figure it out.

Updated game logo

2009-03-13T11:52:00.001-07:00

Redid the game logo as the first version lacked the feel of the game. So heres a new one.

Background threading success!

2009-03-12T08:56:00.000-07:00

I got background threading working and it's working mightily well for paging geometry's batching. With it, I no longer get the annoying periodic jerks that happens whenever a page gets batched in to view.

I've also added an option to dynamically tweak the "density" of the paging geometries so that lower end machines can have less details as necessary. :)

Also to improve performance due to fillrate issues, I've made grass shader's shadow receiving technique pervertex instead of perpixel. This means only cards that supports vertex texture fetch will work. I wonder how many ATI cards I just killed. Hmmm... will need checking.

Henceforth, mission success! Very happy and proud of myself :P Now, back to refraction technique. Then after that to do the most important thing; Network, Script and Game logic!

Game logo!

2009-03-12T06:48:00.000-07:00

Just created a new game logo for aftershock. The red color circle represents the core gameplay mechanic of the game.