To that end I have dug out my version of NSIGHT which is a tool which helps me analyse frames of the game to find out what is being drawn and in what order, and my findings are pretty revealing. Lots of very small and distant objects are being rendered, there is no batching system currently active so there are huge amounts of individual draw calls that could be combined, there is some really HEAVY duty work happening for reflection rendering, even when there is no water visible and the amount of rendering taking place seems a LOT too much for what is effectively a cosmetic touch. It should NOT affect the core game play speed and the enjoyment of the main purpose of the level. Finally there are lots of opportunities to extend the occlusion system and hide even more stuff when you look closer at the two-compounds level. Going to spend the next day or so continuing to play with the features of NSIGHT and learn even more about the current engine performance and workload, and then I will probably launch into doing some geometry batching work around Wednesday. I will also be keeping touch with the feedback forum on V1.007 so I can stat tuned in to what the community are finding in this new version.
We are also starting some work on speeding up the A.I system, starting with some deep drilling investigation of the AI UPDATE command which seems to be causing most of the slowdown. We will also be casting an eye over the grass system as we have identified some possible improvements there!
Before I sign off, here is a cool shot from our Zombie Clown collection, soon to be available from the Reloaded Store. They look pretty calm now, but when you add them in a dark room with the player, armed with nothing but good intentions, get ready for a freight!
It is not recommended you design your competition entry around Zombies from this pack as they will not be ready in time for you to work into your creations. Unless you have your own Zombies and are good at scripting, best to leave these specimens for another compo!
Never done work with reflections in this type of context. Maybe this is already what you're doing, but what about wrapping a semi-transparent viewscreen around the reflecting object (like as an additional texture layer)? For sharp reflections, the resolution's higher. For duller reflections, make it lower (which would be easier on processing power). You'd have to calculate the viewscreen-camera's position and orientation based on the player's and the object and their relationship to each other. This would work really well (effect-wise) for water I think. But I'm speaking of reflective objects as well. The only thing for curved objects though is ideally you'd have to warp the camera, according to the object's normals, and that might not be so practical, although DirectX already does the inverse of this process with texturing, so the math is already there; it's just a matter of whether Microsoft had the foresight to make it accessible in this way. Although, not warping the camera may not be that noticeable by your average player, in most situations.
ReplyDeleteFor distance rendering, it sounds like your imposter system is missing some ques to engage.
Anyway... sounds like you're gonna be having some fun looking into the performance and improving it! :D
What's a "ques"? *confused*
Deletecues? :D I had a spelling phopa.
DeleteOOOOH right now I get it! :D Sorry, I thought you were trying to spell "queues" and that didn't make any sense...duh :S And since we're on the subject and you brought it up....it's spelled "faux pas", not "phopa" :P
Deletefox pass, you say? ;) hehe
DeleteHa. Ha. Actually lol :P
DeleteNo batching system?? No WONDER Reloaded is slower than most engines! Well, maybe it was the AI, but even so! Look, as much as I love the fast level testing, I really think we should be pre-calculating as much as possible. I mean, Half-Life 2 still looks better than Reloaded, and it ran at 60fps on gaming machines in 2004! Ok, so we don't need to go as far as having lightmapping and light probes to handle shadows, but they still pre-calculated a lot of stuff and created the highest-scoring game in history (literally!).
ReplyDeleteIf we need something to not be pre-calculated (say, not pre-calculate the occlusion effects of a wall that will be destroyed at some point), we have a toggle in that object's settings for different pre-calculable things (occlusion, batching, etc.).
Having said that... I'm glad you're still working on performance. I doubt you will ever go as far I would with pre-calculating stuff, so it's great to see there's still a lot of room for improving performance with a dynamic world :)
Oh, did I mention those clowns are looking GREAT! I'm not sure how good the animations are going to be (as animations have generally been a bit of a weak point for FPSC), but I'm sure if the room is dark enough and the lights are flickering it'll be terrifying!
ReplyDeleteOne point, though: Pretty much any modern zombie FPS has detailed gore mechanics for their zombies. That is, in Left 4 Dead, you can shoot various parts of the zombies off and have lots of realistic blood spurt out. In other games, while you might not be able to shoot of parts of them, you normally can shoot off the head and at the very least, when shot, normal-mapped bloody damage marks appear on the body. My point is, Reloaded's zombie are going to be fairly static-feeling by comparison. Not complaining, just pointing that out :)
Dismemberment in L4D2 was done with a eclipse shader, more about how this was achieved can be read here http://www.valvesoftware.com/publications/2010/gdc2010_vlachos_l4d2wounds.pdf
DeleteHowever something like that might not be wise for reloaded at least atm.
Ah, that's the PDF I was looking for!
DeleteNo, of course it's not a good idea right now (would require too much time and infrastructure), I was just pointing out that without it, Reloaded's zombies will look very static, so it will be necessary to at least plan for some system like this.
There is a way to achieve partial dismemberment, something along the lines of sof2 double helix and it would mostly require brakeable characters and some heavy scripting and this might be a better solution however its still a bit early for this. One of my game projects for reloaded depends on dismemberment so i for one will try the sof2 way.
DeleteFor the ones that dont know what am talking about
http://youtube.com/watch?v=hGsdDO672ps
This approach should be possible
Well an easier way to dismember characters might be to just do a quick/rough bisect and split the parts in two. For example, every vertex on one side the bisection plane is on one split. Every vertex on the other side is on the other split. And just let physics do the rest.
DeleteIndeed now with bullet this might just be the way to go, even if this has 0 to none priority it would be nice to hear what lee thinks about this!?
DeleteWhat may be more ideal for this project is to have, along similar lines to what you and Clonkex are saying, already broken characters, with their limbs glued together... until they're not. ~Then~ let physics do the rest. That way bisection calculations & updates need not be done during gameplay.
DeleteThis comment has been removed by the author.
ReplyDelete