Wednesday 22 May 2013

Wednesday LOD and LIGHT

Plenty Code Crunched

A full day of coding, both last evening and this evening sees the low and high LOD system implemented. I also added in some test artwork from Mark for the segment visuals to see how the popping would look.


I have run into some logistical issues however as performance is very much tied to the size of a single segment, how many of those segments are in close proximity and the cumulative processing required to fill the buffers as you traverse through the space.  If I spread out the segments, all is smooth. When I bunch them up, I get stutter as I move through the level. Not ideal by any means, and something will have to give. Currently my high LOD test segment uses over 3000 polygons so one thing that might give is to set an upper limit for segment art.

Thursday will see these logistics put under scrutiny and some rules established so I can have 120fps smooth scrolling through the level with the LOD system in play.  I can report the 'LOD popping' is minimal with my test segment which is good, and I have also increased the size of the overall level from 200x20x200 to 500x20x500 as when I walked from one end to the other I felt I needed more distance, and it's only an extra 50MB (with further optimization in memory use possible).

The Lighting Issue

A new situation has emerged that might affect deadlines, and just like the memory resource bar and massive levels was discussed in the blog, I felt it was a good idea to broke the new subject here as well.

I was about to add the real-time light mapping system to the instance stamp code I have been working one when I got an email from Mark suggesting that adding directional light to the level would not work in cases where a soldier or object was placed alongside a wall that would cast a shadow over the subject based on the angle of light.

For an outdoor scene, it is common in some FPS games that a single directional light representative of the sun would allow all objects in the scene to cast a shadow. This shadow would render on the floor, walls, characters and objects of the scene. The common technique used is a variation of shadow mapping and uses a second render from the light position and clever shaders to achieve.  It was suggested that before I embark on adding my real time light mapper to the new static scene system, we look at the possibility of adding dynamic directional lighting into the scene, and perhaps even deferred rendering.

It must be stresses that starting a series of prototypes to experiment with deferred rendering techniques, and implementing those to replace reliance on baked light mapping would add considerable time to the project deadline. Although I am familiar with the technique, I have not created one personally and there are bound to be a hundred small details that relate to creating a deferred rendering system for an entire game engine. It would also mean we basically throw away the real-time light mapping system developed so far as a dynamic lighting system would not need secondary shadow baking and surface lighting.

Rick suggests we implement both, baked lights for interiors and dynamics for exteriors, but this of course means all the work of a deferred renderer, plus implementing, perfecting and then combining these two techniques into the final engine, producing the most amount of work.

One advantage of dropping baked light-maps is that no memory would be required to store the UV data sets and of course the light map textures, which when considering a 500x20x500 level, would amount to quite a sea of lightmap textures and most certainly some form of streaming system to ensure the texture and UV data was streamed in as the level scene required the data.

Decisions Decisions

I am loathe to drop code that I spent weeks theorizing, coding and perfecting, but at the end of the day it is about creating the best product and if that means smashing the sculpture to pieces and starting again, then these are the hard knocks of game development.

I have decided to crack on with things that need coding and not debating such as getting the static LOD system smooth and predictable, adding it to the main map editor so I can edit with the new instance stamps, and then seeing what I can do about physics and player controls.

Physics and Player Controls

Just to highlight that game engine development is not all peaches and cream, another issue to tackle in my immediate future is the fact that as the geometry is being constructed on the fly as you get near to it, so to does the physics geometry. 

In the current FPSC all physics level geometry is loaded in at the start and stays solid until you go to the next level. Apart from placing pseudo static boxes, I have never tried generating polygon data and adding it to a physics scene on the fly. My mind tells me such a thing would introduce instability and cause distant objects to start flying out of the scene, and at the very least add more processing overhead as you advance to new parts of the level.

A prototype will need to be created to answer these questions before I can introduce physics to the map editor and allow the user to drop down and run around the instance stamp based level.

All these things can be worked on without answering the lighting question, so we have some time to debate the pros and cons of creating a whole new shader based lighting system over the traditional baked lighting system we have right now.  Its worth noting both COD MW2 and Black Ops are forward rendered using some baked light-maps, and they look just fine.  Deferred rendering you would see in games such as the latest Far Cry. I am not pinning my 'alternative flag' to deferred, simply opening up the possibility for developing a new lighting system that does not use baked lights and instead produces all it's lighting from clever shaders and even cleverer techniques.

Signing Off

I am quite pleased with how the LOD work went, and with some tweaking of buffer sizes, asset sizes and load balancing so not too much happens in the background, I should be onto the next thing soon. If anyone looks at these daily antics from outside the cult of coding, you should begin to realize just how fluid development can be. Where I to stick with a deadline and meet it, I would not be implementing instance stamps, I would probably already be working on physics and player control systems, running around a light-mapped level created under the umbrella and protection of a resource meter. The big question is whether the lighting question is one of those deal breakers, or whether we can stick with baked lighting and return to outdoor directional dynamic shadows and lighting during an update after Christmas.  Feel free to post some comments on this!

6 comments:

  1. Hi Lee,

    Your work seems to be progressing well. Thank you.

    With regard to the lighting I guess that at some time the theory (prototype) of each of the proposed methods given you developed a prototype for each and the work involved in both - each would have to be tested integrated to the whole. I dont think we would be in a position to judge the benefit as opposed to any disadvantage on performance and so on as you would be actually working with and getting the feedback of what you are doing instantly as it were.

    I guess theres no real way to know which will work best and actually be possible to integrate to best effect unless you do it which means a lot more work for you and a longer development pipeline.

    As with most of these things the end user and game player does not really care how its done as they judge by the result. Point being is it a feature which is required absolute or not and is is viable. If there is little benefit one way or another then either is good. If there are any serious disadvantages (to the end users) then its not good. On balance if its not needed and the investment in resources is not matched by the benefits then theres no point in doing it.

    If its just a little eye candy benefit then I am not sure it could be said to be necessary. However if it needs doing for the future benefit of the product then now is the time to do it I guess so it can be tested and built into the early core rather than chop that about later.

    Personally I am not actually aware of the exact overall differences to the end user visually in the end game play and if one or the other would have much benefit to them one over the other considering the engine development ongoing either short or long term. i.e. if the dynamic type would be a better bet or not for the future of games made with the product.

    I am waffling now about what you already are aware of....

    I think your comment about moving on with the physics and so on and getting some things into the editor is about right at the moment and adding any current lighting proto work to it may throw more light scuse the pun on the subject for you to access yourself. Will that integrate and work and will it be enough for the product?

    Better is always good if it can be done if indeed overall something is better by real benefit.

    ReplyDelete
  2. So here are my thoughts about the deffered rendering system or backed lights:

    I see some real benefits in using deferred rendering. As first the memory needed for baked lights is gone (as you already mentioned). Than in advance we can use multiple dynamic light sources for all surface shaders (which adds to immersion).
    Than there is the point, that you can enable and disable dynamic lights based of visibility in the level (so something like portals, which deactivate unneded lights --> performance save).
    Another interresting part of a deffered renderer is, that you have a base shader on every object in the scene, which lets you render all needed stuff like World Normals, World Space Positions, etc... This can later be used for example to generate an alpha map for (multiple) water planes, which than do not cut into objects but create a nice alpha transition to every object. Also you can use this pecific base object shader to generate depth info for maybe an Depth of Field shader etc.
    The possibilities gained by at least an unified (deferred) rendering in this case are endless.

    A big thing would be, that FPSC-R would gain much more attention (even in the future) as a lot of newer engines tend to use deferred rendering, as it gives you a lot more possibilities in all ways. Real-Time map editing with real-time lighting, more immersive worlds with dynamic shadows etc. This would be a huge boost for the overall visuals and is something FPSC-R could really need.

    In combination with Object LoD, light LoD and different light sources (Point, Spot, Directional) the performance hit should not be that bad. Maybe there are some things connected to DBP source which would help improving the overall performance.

    So to keep it short here (could talk about this a lot more, why I would go with a deffered renderer rather than baked lights), my opinion is, use a deffered renderer, even if this pushes the deadline.
    I think the time for this has come and by putting such a possibility to the side now, would result in problems later, if you want to put it in at another time.

    ReplyDelete
  3. To me; the reduced memory and real-time shadows would be my preference. Maybe the new light mapper could be made into a separate application to create baked light map environments to import into FPSC-R?

    ReplyDelete
  4. First of all: Just remember, Lee, you're using a fairly massive PC to test this on, and we don't all have massive PCs.

    Second: I say go for the deferred renderer. I'm terrified at what cost this might come (in terms of speed I mean) but it's just so much more powerful. As DarkGoblin said, it makes it far easier to create one giant unified shader system.

    I expect to allowed to place any number of dynamic point, spot and directional lights in my FPSC-R scenes. Compared to forward rendering, deferred rendering is MUCH faster when you have many lights, because deferred renders them all in one go whereas forward renders them one by one.

    So as much as it scares me, in that I might be helping to create a slower-rendering FPSC, I vote we go for deferred rendering (without pre-baked lightmaps). Just so long as you put a lot of effort into making it as fast as possible and making everything lightable.

    Also, read these, they apply to Unity but are very general and might give some insight into how to implement shadows and (importantly) what level of detail your characters should have (no more than 10,000 at highest LOD):

    http://docs.unity3d.com/Documentation/Manual/DirectionalShadowDetails.html
    http://docs.unity3d.com/Documentation/Manual/ShadowSizeDetails.html
    http://docs.unity3d.com/Documentation/Manual/Shadows.html
    http://docs.unity3d.com/Documentation/Manual/DrawCallBatching.html
    http://docs.unity3d.com/Documentation/Manual/ModelingOptimizedCharacters.html
    http://docs.unity3d.com/Documentation/Manual/RenderingPaths.html

    ReplyDelete
  5. Hi Lee

    I feel you must go with the deferred rending for FPSCR.

    Dynamic shadows were cancelled in FPSC X10 and it would be a significant loss if this happens again in FPSCR.

    We really must go for a more advanced lighting system for the next generation of FPSC and I think you should take a bit longer to deliver if it means we can get this.

    Please make deferred rendering and dynamic shadows the next highest priority for Reloaded.

    ReplyDelete
  6. I've changed my mind (as of Lee's comment about deferred potentially costing 4-6 renders of the entire scene. It would be very (extremely) disappointing not being able to actually use the latest FPSC just because I voted for deferred and that caused it to run at 5fps...

    ReplyDelete