As my original one hour Zombie side-task turned into three hours, I decided to commemorate the work with a small video, and a possible hint on our plan to improve the Zombie Pack for Reloaded.
As I increase the number of variety of entities being tested under the light mapper it's great to see old entities gain new life with the extra lighting fidelity. In the Church model you can now see shadows being cast inside the bell tower, the parapet details and even the subtle base relief, bringing out those geometry touches that were previously hidden.
The next chunk of work after light map file saving is GPU Memory exploration, specifically to find out what is being used, the proportions and any waste happening. I can then budget in my requirement for decent light mapping texture space and at the same time tackle the issue of Reloaded crashing out due to lack of video memory. I consider 1GB of video plenty for what we are doing right now, so there should be no excuses why we are getting anywhere near that number. Will be a fun adventure down the rabbit hole that one!
Zombie with no lower body and spine protruding - nice and gruesome!
ReplyDeleteNice one Lee,like the look of that church.
ReplyDeleteLooking good, Really set out the detail in the models. Cant wait to try it out on my stuff.
ReplyDeleteNice work! The zombies are improving also by the looks. I did notice an odd shadow on his left side (our right) as he crawled, not sure if it's the model deforming or the shadow effect. But looking good other than that. The speed of the anim was a bit fast for his crawl also, but those are mere tweaks.
ReplyDeleteThat zombie crawl animation is one of the worst animations I've seen. I don't want to be harsh but it's very, very bad.
ReplyDeleteThe animation is fine for any game not trying to make millions, and not the worst I have seen. Do you mean the speed the character moves at with the animation? Right now they clearly aren't timed correctly. All you need to do is reduce the animation speed and add sound.
DeleteIn addition to speed, you could also time it so that it only moves during the grab and pull part. There could be a slight pause with no movement after each pull so that it doesn't just look like it's sliding constantly. This could be done in the script and would make it look more realistic. However, I don't think Lee was trying to show off the perfect crawl animation anyway and it's up to "us" to time it and tweak it as necessary.
DeleteBoth animation and movement speed are adjustable, this was just a quick test to confirm an animation bug fix before handing it over to DaveH who has the job of refining scripts while I return to visuals and performance work. Huknar, I'm all for constructive critique, but I am now quite worried that you are experienced in how a chopped in half undead guy realistically drags himself along a slippery floor at night :) Perhaps you can post a link to a much more realistic 'dragging oneself along the floor with just your hands while missing your entire rear half' as I am sure Mr Blosser would be very interested in refining his understanding of how chopped up dead people move ;) Can't wait to see what you come up with!!
DeleteI was going to say pretty much exactly what Tommy has already mentioned. The movement should only occur when either the left or right hand is animating a pull motion. A pause in between when they are not. This will create the dragging motion you are looking for. Much more realistic and even creepy. Funny enough a good example is already in the WWII Zombie pack of the crawler. Though its a double handed pull and pauses. For this zombie its pause would be much much shorter.
Deletei agree with that comment. its just a terrible animation. would look better in water and at least you could say he was swimming then.
Deletea more believable animation would be with BOTH hands, reach forward then drag his body forward..small pause, and then resume.
perhaps your animator, lie on the floor and then try #1, this animation, and then #2 my suggestion, and see which one works.
___ thats my contructive critique ; im not being rude if it comes off that way ____
Here we go Lee! This is what you should be aiming for. https://www.youtube.com/watch?v=J5TSnXRJxYY
DeleteIndeed, Huknar, that's an excellent example!
DeleteThanks for the link! Are there any MAX animators out there who might like the challenge of improving our current Zombie crawler to resemble the one in this link: https://www.youtube.com/watch?v=J5TSnXRJxYY
DeleteHuknar's example wouldn't work in Reloaded, it's not a constant forward movement. You'd need in in-game IK solution for that to work. We could do the two handed pull as seen in the Zombie Apocalypse II pack, however. The current animation works with constant forward movement like the HL2 zombie seen here (although a bit comically exaggerated imo): https://www.youtube.com/watch?v=F-C2yi6cuIY
DeleteWhy do you feel it needs to be constant forward motion? You can script the entity so that it moves forward at certain frames of the animation and pauses for others. This is totally viable.
DeleteI know you can pause and resume in-game motion, I did that with the ZAII pack seen here: http://www.thegamecreators.com/?m=view_product&id=2298
DeleteI'm not talking about pausing and starting. I'm talking about IK, where forward movement speed is varied, and the center of mass moves AROUND various body parts. In Huknar's example, there is obvious IK going on, the forward movement is not constant. Animating with IK is one thing, but getting the engine to track the root movement while still respecting the IK is another thing altogether.
There may be IK in that animation, but IK has nothing to do with movement speed so I think you are still a bit confused. IK is when you move a bone and all the parent bones up the chain are affected as well. Speed is irrelevant.
DeleteMark refers to the movement 'inside the animation', which then needs to be translated to real world position changes. It can be done in script, but you need to map each key frame to a movement value and apply it in sync with the animation (cumulative approach). The current crawler relies on a constant movement, which can be easily achieved by changing the MoveForward value in the crawler LUA script.
DeleteRight. True.
DeleteWe're not understating each other, so this will be my last post on the subject. You're only thinking of ONE type of IK, as it pertains to a bone chain. The floor itself can be part of an IK chain! Setting a planted key on a 3ds Max biped is an example of IK. When a character limps, that is a prime example of IK. Root movement speed is affected depending on which limb is on the ground. Try animating a limping man in your 3d app of choice, then see how it looks in FPSC. A man crawling has 4 possible points of IK with the floor.
DeleteNo problem. I'm no animation expert so I'll just leave it at that.
DeleteSorry Mark for the additional critique and flak! My blog comments section is like the devils kitchen these days ;)
Delete(DE-LURKS)
DeleteMark, I know you've said you won't post again on the subject, but I hope you'll reconsider, or at least read this. I'm only a hobby animator (at least when it comes to character animation, I've done some paid logo animations for corporate clients), but I know the pain of unrequested feedback on WIP animation! :-P
I wonder if it's possible to animate a zombie walk cycle so that it appears to have varying speed when played back in FPSC, but underneath it is moving at a constant speed.
Wow, I described that really badly. Let me try again with an analogy:
Imagine motion capturing a human performer who is on a slowly moving treadmill as they limp like a zombie. To anyone present at the capturing session, the performer is moving slightly forwards on the treadmill when they step with their fast leg, and falls slightly behind when they step with their slow leg. But since the treadmill is moving at a constant speed, the resulting motion capture can similarly be slid along the ground plane at a constant speed, yet gives the impression that the zombie is walking with irregular speed. Obviously, this approach would place limits on the performer - too fast or slow at any point in their cycle and they fall off the treadmill...
But couldn't essentially the same effect be achieved with from-scratch keyframe animation? (in the case of a legless zombie torso, I guess motion capture isn't an option!) That is, animated as if the floor is moving at a constant speed, even if the character isn't?
For all I know, this approach might cause more problems than it solves, since the visual "center" of the animation would be moving back and forth compared to the actual root bone/anchor of the character which is moving at a constant speed, which might cause issues when the FPSC engine transitions from one animation to another (such as transitioning from limping to swiping or turning etc), issues which I know precisely nothing about when it comes to real-time game engines. Does FPSCRL have any non-linear animation features "under the hood" to deal with such issues?
But is such an approach worth a look?
(GOES BACK TO LURKING)
Yes, that's exactly what I would do. And you explained it very well first go. Definitely should be animated to look slow-fast-slow-fast but move at a constant speed underneath.
DeleteAs I had mentioned before, Lee, try to make sure you aren't forcing all video assets into video memory. Allow them to go into system memory if video memory is full. I'm not saying don't try to find ways to optimize, but just make sure there is no possibility that we'll get a crash even if we DO exceed video memory. Our games may suffer performance hits if we exceed video mem, but then that becomes a game dev issue and not an engine issue. The engine should handle it without complaining.
ReplyDeleteI wish you luck and speed in your future attempts solving the video memory crash.
ReplyDeleteI have all Wednesday to delve into video memory, and there is more than one mystery to solve! As for using managed textures to retain a copy in system memory, I am avoiding that as system memory is also a very precious commodity. There 'may' be a way to stream in textures via managed resources as worlds get larger, but my first task will be to take a sample of what is happening now and look for anything 'silly'.
ReplyDeleteSystem memory is far more abundant though and if you "run out" of system memory then the OS is going to cache to disk. So, again, you don't ever really run out. Just my 2 cents.
DeleteYip i agree with Tommy make full use of that 4Gb ;)
ReplyDeleteLee, this question is for the future of FPSCR, but why should the engine not stream all media from the HDD? This would allow for much bigger worlds and put less limits on the designers of a game. id Software has done it quite cleverly in RAGE.
ReplyDeleteAs far as I know they stream in high-quality models and textures for the part of the scene the player is looking at. When the player turns around, the high-quality stuff is replaced by low-quality versions. Seems they load only what the occlusion mapper thinks should be shown and throw the rest out of the memory.
It takes a second to load all the media, but RAGE uses 4-16k textures on many objects. If the usual texture size for FPSCR would be 1-2k, then the loading times should be much shorter and, as I already wrote, put far less limits on designers. Just imagine the whole FPSCR map populated with details and it would be all working perfectly... :)
@Tattie Bojangle
If you allow an application to use more than 2GB of memory, then it won't be able to run on 32-bit OS, as it would crash Windows sooner or later. So you are cutting off a part of your customers.
FPSC Classic (and pretty much every executable) can use up to 4GB of memory. Just google "Large-Address-Aware-Flag". That way FPSC Classic can actually use 4GB of memory, but not everyone will be able to play your game, unless they upgrade to a 64-bit OS and more than 6GB of RAM.
Actually virtually everyone has a 64-bit OS these days and limiting it to 64-bit only is not a big deal. Also, if I remember correctly, the large address aware flag thing has severe disadvantages (though I don't remember what they are).
DeleteThe thing where RAGE removes stuff from memory when you face away from it is dumb and annoying. The way UDK/Unreal does it is far, far more sensible; it loads everything in an area around the player, in all directions, so when you spin around fast (as you will do in a FPS), you don't get stuff half-loaded and causing stuttering.
The church picture is one of the first genuinely 'pretty' shots I have seen of FPSCR.
ReplyDeleteConcentrating on the lighting was a good idea.