Les voicis :
Et voici plus d'informations sur les sièges :Flags
For the flag pole on the KSC, that you can see on this week's KSP Weekly, we needed a loop animation for the flag. There where different ways to do this, cloth simulation in Unity, Mu suggested a special shader for the flag. But at the end we will be using an animation loop based on joints, the same as the EVA flag, and -of course- the kerbals.
I rigged the flag on Maya, and used a dynamic joints simulation. That allowed me to have a Unity-friendly asset, with cloth simulation, and some wind dynamics. The rest of the process is exactly the same as with all the kerbal animations. Joint rotations are baked, and everything that's not joint nor mesh is deleted. Leaving me a bunch of rotations to adjust so that the loop is barely noticeable.
There's also some designs for the flag. Being Space Center or EVA flag, and everything that has to do with flags.
There's three sources that I like to mention here, that helped with the flags.*The hexagons and symbols, I got the idea from animator and director David O'Reilly, (whose work is just amazing, you should see his short films on Vimeo)
There's Signalnoise unofficial NASA patches.
Et je ne sais pas si ces informations sont remonté il y as deux semaines (il me semble que non) :Hello again,
So, as you probably saw on that sneak peek on the Weekly article, I've started work on Kerbal Seats:
This really is as much fun as it looks like.
Seats are, in a nutshell, docking ports for Kerbals. That is, when you 'board' a seat, what's happening internally is that the EVA vessel is docking with the seat's vessel. Because Kerbals on EVA are parts like anything else, this process works very well. Instead of moving the crewmember's 'soul' into the part and destroying the EVA object, the EVA continues to exist, as another part on the overall vessel.
Now, EVAs not only are parts, they are also control sources. That means if a vessel has no control sources, but has a seat, boarding a seat will add a control source to the vessel, making it controllable.
All this means there is effectively no restriction in what you can control using a seat. It could be a moon buggy, it can be an RCS-powered hovercraft like that contraption there, or it could just be an SRB with a seat.
Also, the undocking process is handled by the EVA controller itself, whenever the FSM leaves the 'sitting' state. That works if you're leaving the seat normally, as expected, but it also works just as well for 'unplanned' disembarkings, as in cases like your head suddenly becoming part of the vessel's landing gear apparatus, and other such events.
There's still a lot of work to be done though. If you look closely at that shot, you'll see that the EVAs aren't sitting very well on the seats, because we still need to add a proper pose to them being seated... Also, leaving the seat right now can be... destructive. Anyhow, these and other issues are getting solved gradually. Eventually we'll get to a presentable state.
That's about it for now.
Cheers
VOilà, vous avez de quoi faire làHello everyone!
The team is hard at work on the 0.20 update, and things are coming along nicely. I've been working on a new scene loading system for the game, and helping out Mu with the new Game Database.
Both of these systems will provide some much needed optimization and upgrades to the game's core systems. The new loader allows us to have multiple screens at load, in addition to customized text during loading. It's a nice bit of needed polish on the game. We should be seeing some fair improvement times in loading as well. I'll leave the description of it fairly brief for now, since Mu is likely to post his own DebBlog that goes into more detail. For those interested in the technical side of KSP it should be quite a treat. The game database system will be revolutionary for the workflow of all the modders out there.
As for the scene loading system. While at GDC I spoke to the engineers over at Unity, and described the issues we've been having with memory crashes. Apparently during the loading of a scene, the new scene, and the old scene can be together in memory for a split second. We use some fairly large and memory intensive scenes, such as the flight scene and the tracking station. In those cases, even a partial load of another scene on top of the existing one can push your memory usage past the 32 bit "Wall". If that happens, the game will crash to desktop. It's unfortunately fairly common for computers with 2gb of ram, or ones that are running 32 bit operating systems. The new scene transition system will look ahead to the level being loaded. If the incoming level is the same as the old, the loader will keep the re-used textures and models in memory instead of wiping them. In the case of a scene to scene transition, like when going from flight to the tracking station, the loader will instead flush the memory completely and load the new level. This will clean up any memory and allows the garbage collector to do its job efficiently. On top of that, the new loader runs asynchronously in a co-routine, instead of attempting to do the level load in one frame. The benefit of this, is that Unity can continue to run its normal operations while the game loads.
Once I finish work on the Game Database and scene loading systems. I'll return to upgrading part modules and systems. As for youtube videos and streams, I don't have much to show that's visual this update. As most of my work has been on systems. Once I get back to parts, I'll show videos of their testing and development as usual.
* Side note : I've lost all my PM's in my inbox. If you've sent me a message and I didn't respond, that's likely why. Feel free to contact me again and I'll work through the backlog. Thanks!
-C7
!edit ::
http://forum.kerbalspaceprogram.com/con ... ay-07-2013
