Friday Map Editor Fun

Inside the Map Editor

A small triumph today as I manage to get the Instance Stamp system tentatively working inside the current FPS Creator Reloaded map editor.

What you are seeing is the system that only creates segment renders when the camera needs them operating inside the map editor.  You can also see, there is no lighting being applied and they are all using a single texture, but there are no nasty artifacts and you can paint segments as normal. You also cannot delete segments at the moment, though this functionality is now added to the instance stamp system.

From this foundation I can start to craft in all the bits needed to get it back to where the map editor was about six weeks ago.  Might seem like a giant step backwards, but given a few days the new system will be able to edit segments as before, but now those levels can be 500x20x500 in size and the memory footprint won't go above 1GB unless seriously taxed with polygons.

The Long Walk

Before turning my attention to editor integration I did a quick test and discovered it would take you just under 5 minutes to jog from one end of the new Reloaded level to the other end, which is a long time when you consider that is in a straight line along the shortest distance of the level edges.  Now consider how long it would take you to fill a space 500x20x500 (or even 500x500) with meaningful detailed content and you will realize that by coding the engine for the worst case polygon scenario, the actual usage patterns would hardly scratch the surface and protect both memory and performance levels.

There are some unknowns still be to discovered such as the extra memory footprint of the mip-mapped textures, the sound and music, the memory required to store and operate all the AI, the data banks that drive all the logic of a level and who knows what else.

I don't think we're going to get infinite worlds here, but we should end up with a level too large to populate in a single sitting whilst remaining inside our maximum memory capacity of 1.8GB.

Light and AI

It's great to see comments and conversations spring up around these two issues, and as much as AI is an exciting feature to think about the code will have to wait until we have cracked the fundamentals.

It looks like the voting scales are ever so slightly leaning towards the deferred approach to rendering, and I am happy to leave the subject bubbling a while longer until my brain leaps out the bath and yell eureka.  Quite rightly, Mark warns of severe performance issues when rendering deferred, as you really do need to render the scene at least two times.  With the forward render layer trick for transparent and secondary shader elements, that count increases to three. When you add shadows through CSM, you are anywhere from four to six times. I don't need to tell you that all this spells massive slowdown if your graphics card does not have the video memory and GPU grunt to process all that. It could be a quick and dirty prototype is the way to resolve this question, and then try it out on what we all agree would be the Reloaded minimum specification.

Signing Off

I am taking the weekend off to visit family and friends in my shiny new car (well, new to me) and probably doing to have a beer or three before the weekend comes to a close. For those who asked, the car is a Honda Accord, voted the most reliable manufacturer seven years on the trot. It's bank holiday Monday here in the UK I think but I will be cracking on finishing off Instance Stamping in the editor, getting textures and shaders working there again and ensuring the same functionality exists as before. From there we can look at lighting prototypes and basic physics so we can run around the new instance-stamp universe and jump off crates!  If anyone can find some good deferred rendering demos that run on very basic PC's, send me the link so I can try them against my array of devices. See you Monday!