[dteviot] Posted March 30, 2008 Report Share Posted March 30, 2008 (edited) Hey we're the art dep, we are supposed to bug you Prog guys And often its the other way around... I suspect that's because there's not enough up front communication about what each team is trying to achieve, and what it need it needs from the other team to be able to do it.All the is different is the texture, so no need changing the model...From a programming view, there's negligible difference in the work required either way. Not meaning to be nasty or anything, but supporting multiple models for X-Corp soldiers is WAY down my priority list.So far, in fact, that it isn't even on the list.This statement isn't correct.There is currently provision for supporting 4 models for X-Corp soldiers. "no armor", "combat armor", "powered combat armor" and "flying armor". The information on the image to use (for all but the no armor case) are held in item.xml. But there is no provision for variants of each of the four types. e.g. Sex, camo, etc. Note, I'm not saying that I can't or won't support multiple models, just that I wasn't aware of the need to do this. And that if I do, then it needs to be prioritized along with everything else. So, if we're going to have multiple X-Corp soldier models/textures then someone needs to tell me now what the plan is, so that I can prepare for it.Also, does this mean we may have different alien models/textures as well? Note, there is provision for each rank of an alien species to get a different model, but assumes there is only one model for each combination of rank and species. Edited March 30, 2008 by dteviot Link to comment Share on other sites More sharing options...
Shinzon Posted March 30, 2008 Report Share Posted March 30, 2008 (edited) Well, I guess then the ART dep will have to read the XNA updates and churn out accompanying art. I have a general idea of what needs to be done (Like all of those base facilities) but I bet that is not really "Needed" by the prog department at the moment. Possobly things like interface and menus, buttons, widgets and stuff along those lines is what the prog dep needs at the moment, I am not sure, please clarify... Work still to be done: 2x2 Units. -Complete a 2x2 Alien for use? Correctly size them, (Actually correctly scaling all units is probably needed, add a scale and size elements to combatant.xml)draw at correct position on battlescape. (Because they cover 4 cells.)Line of sight/fire. Actually, these two might not be such a problem. For rule engine purposes, assume combatant is at center of north west cell on terrain. Then add a displacement vector of (+0.5, 0, +0.5) to draw centre of combatant at intersection of cells.X-Caps/tanks on battlescapePathfindingCivilians on battlescape terror missions. (Also when aliens attack an X-Corp outpost?) -Get some CIV models done?Better (or more fun) AI logic for alien forces on battlescape.Experience for X-Corp soldiers -Approperiet menus?ReactionsBleeding out of wounded soldiers. -Art related Symbols for sodlier status?Medkit healing - Medkit "Healing Interface"?Recovery of stun damageExplosions - Explosion sprites?GrenadesRest of actions that items are capable of. Psi attacksPsi probeScanHitWaypoint (for BB launcher) - Waypoint "Marker"?Fire on battlescapeSmoke on battlescape - Smoke sprites? Line of sight effectsStun damageAbility for combatants to drop and pick up items on battlescape.Draw dropped items on the battlescape.Proximity minesNight missions. Rules engine: determine visibilityGraphics engine: how to render?Cydona missionAllow X-Corp player to select troops that will defend an X-Corp outpost from alien attack.Generating battlescape terrain (esp. for different types of missions.)Destructible terrain Just being able to destroy walls and floors.Major property damage when structural elements are destroyed. E.g. no "floating" building levels after the ground floor is destroyed.Improved line-of-sight calculations, to allow for posture, combatant height, and terrain obstacles in way?Re-equip soldiers after battlescape mission/before starting new mission. Note logic is already there in CombatantInventory.RestoreLoadout() and SnapshotLoadout(), just need to hook up and deal with case of insufficient supplies in outpost.Aesthetically pleasing UI.Aesthetically pleasing rendering of battlescape terrainRelated (maybe) only render part of scene that's in viewing fustrumAnimate the combatants on the battlescape.Draw items in hands of combatants on battlescape.Fog of war: No information to player on terrain that hasn't been seen yetSoundMinimap - How do you draw it? Do you take "status" or "type" of each tile and then give it a certain color, and the mini map just scans the tiles and draws the itself (During the loading screen persumably saving the "Complete" minimap into a temp file for that mission)? If so then little Art dep involvement is needed.. Edited March 30, 2008 by Shinzon Link to comment Share on other sites More sharing options...
[dteviot] Posted March 31, 2008 Author Report Share Posted March 31, 2008 Have the X-Caps and Silabrate already, so no urgent need for 2x2 models. (Other than in the form of models for all aliens)Civilian models. I've already got an idea for that. Use existing .md2 models.Should not need an interface for med kit, it's going to work just like a weapon. At least until post v1.0. Really, the big bit is terrain models, and until destructible is solved, I don't see much point in working on them, as it may require redoing them. In the mean time, alien and equipment models is probably the way to go.That said, it may pay to discuss standards for the alien models, so that the programming team can handle them.e.g. Scale of models, Location of origin and initial orientation.Standard animation sequences.Maximum number of bones per model.How to attach items to the model's hands.There's probably a whole bunch more stuff, that I don't even know about. Link to comment Share on other sites More sharing options...
Shinzon Posted March 31, 2008 Report Share Posted March 31, 2008 (edited) I belive the bones matter is going to be slightly complicated; as it is not simple as every alien sharing a humanoid set up... So the rigging of diffrent aliens is going to be really diffrent from one another... Unless I'm thinking of a compleatly other thing... Edited March 31, 2008 by Shinzon Link to comment Share on other sites More sharing options...
Darkhomb Posted March 31, 2008 Report Share Posted March 31, 2008 Shouldn't matter should it? as all animation is done in the model, and then the prog dept just needs to know play frames 20-30 for walking, 30-40 for firing, 40-50 for dying etc.. Link to comment Share on other sites More sharing options...
[dteviot] Posted March 31, 2008 Author Report Share Posted March 31, 2008 I believe the bones matter is going to be slightly complicated; as it is not simple as every alien sharing a humanoid set up... So the rigging of different aliens is going to be really different from one another... Unless I'm thinking of a completely other thing... I just said "number of bones", not position or rigging.The issue is, and I may be a bit wrong here, but assuming we're using skinned (or stitched) models, then Shader 1.0 means we can render a model with up to 20 bones in one pass. (IIRC, in theory it's up to 27 bones, but that leaves no registers for other things, like lighting.) If we go to Shader 2.0, then up to 96 bones is possible assuming we don't need to scale the models. If scaling is required, it drops to 64. Again, practical limit is less than that. And as Darkhomb said, we need a set of common animations, regardless of how the character moves: e.g.walk, turn, fire weapon, hit?, use item, die, etc.We need to figure out how prg can use common code to play the animation on all characters.Also, how to put items in character's hands. Standard method is put a bone with a known name at the attachment point. Link to comment Share on other sites More sharing options...
Darkhomb Posted March 31, 2008 Report Share Posted March 31, 2008 Since not every model is the same, some will require more animation to look smooth for certain parts. we either have a set range that every model should mimic IE the viper which is fully animated, so whatever frames it uses it what all models use. or we do some type of xml that states frame ranges for what movement for each model. Link to comment Share on other sites More sharing options...
[dteviot] Posted March 31, 2008 Author Report Share Posted March 31, 2008 before we get too far into the discussion of animation, we need to know what the engine supports. Are we do simple animation stored only in vertex keyframes al la quake, or more complex skeletal based animation? Also will the engine support multiple rigs or do we need to limit things to a single humanoid rig?An excellent question. The answer is; at the moment it doesn't support either.As regards supporting either. Quake is easy to do. I know of 2 libraries (including source) that can draw animated .md2 files in XNA, and one that does .md3. Unfortunately, they're not copyright compatible with Xenocide. But from what I've seen of the .md2 spec, it wouldn't be hard to write my own. (Especially with the other libraries as a guide for any ambiguities in the spec.) I'm not so familiar with skeletal animation. Truth is, I'm just learning it myself. That said, from what I've seen, that should not be too difficult, assuming Shader 2.0 is minimum spec. (And as I've posted before, I think I'd like to make shader 3.0 as minimum, as that may make destructible terrain a lot easier.)So, long story short, I'm willing to do either. In fact, I suspect we could do both. But that would add development time. Link to comment Share on other sites More sharing options...
Vaaish Posted March 31, 2008 Report Share Posted March 31, 2008 (edited) I'd prefer to go with skeletal animation since I think it'll be easier to work with in the long run and provide better results. Edited March 31, 2008 by dteviot Link to comment Share on other sites More sharing options...
[dteviot] Posted March 31, 2008 Author Report Share Posted March 31, 2008 before we get too far into the discussion of animation, we need to know what the engine supports. Are we do simple animation stored only in vertex keyframes al la quake, or more complex skeletal based animation? Also will the engine support multiple rigs or do we need to limit things to a single humanoid rig?I should add an additional comment, and display my appalling ignorance of animated modeling.My understanding is that if we're just going to play animations, then from the view of the game's rendering engine, the rigs are irrelevant. Provided the engine can be told the bone hierarchy and the bone values, it just walks the hierarchy, applies the bone matrix to the mesh, and renders. It's only if we want to have the game engine programmatically manipulate the model (e.g. IK or rag doll physics) that different rigs become an issue. Note, this says nothing about issues the ART department may have with trying to animate models with different, non-humanoid rigs. Link to comment Share on other sites More sharing options...
Shinzon Posted March 31, 2008 Report Share Posted March 31, 2008 Bones and Riggins aside for now; is there anything that the prog dep absolutley needs done? If not I will continue to work on the base facilities and dig through the Database; seeing if I can texture or re-model something Link to comment Share on other sites More sharing options...
[dteviot] Posted April 1, 2008 Author Report Share Posted April 1, 2008 Bones and Riggins aside for now; is there anything that the prog dep absolutley needs done? If not I will continue to work on the base facilities and dig through the Database; seeing if I can texture or re-model somethingThere's nothing that needs to be done urgently.I think the most useful thing at the moment would be magazines for the human weapons, so the equip soldier screen can have some nice graphics.I'd also refrain from doing base facilities for a little longer, until destructible terrain is resolved. Link to comment Share on other sites More sharing options...
Shinzon Posted April 1, 2008 Report Share Posted April 1, 2008 (edited) Understood... I forgot weapons need ammo to shoot What is the poly target per ammo clip? Edited April 1, 2008 by Shinzon Link to comment Share on other sites More sharing options...
Darkhomb Posted April 1, 2008 Report Share Posted April 1, 2008 (edited) Eamon is working on clips for the rifle already. Think we need a pistol clip modeled, and rocket launcher texture. I will update the art assets excel this week.Right now there isn't really a limit, the only time the model will be used is the x-net. rendered front side will be used for equip screen. Edited April 1, 2008 by Darkhomb Link to comment Share on other sites More sharing options...
[dteviot] Posted April 1, 2008 Author Report Share Posted April 1, 2008 Right now there isn't really a limit, the only time the model will be used is the x-net. rendered front side will be used for equip screen.That's not exactly true. The models will probably be used if the items are ever dropped on the battlescape, or held in someone's hand (which means they might also appear in a reload animation, if we can figure out how to do it for all combatants.) That said, poly count isn't a big issue. Keep it below 1000 and I don't think it will be a problem. Link to comment Share on other sites More sharing options...
[dteviot] Posted April 6, 2008 Author Report Share Posted April 6, 2008 The fracturing and destructability is doing procedurally, at least for big models (that is how it is done today) the artists just hints the engine where to "cut off" the elements. Or what an artist do is chop the model in parts if required (but that is something that you can do procedurally too on a Geometry build pass. That is why I say lets forget about it, and concentrate on that part. Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case). So it cannot handle properly (without too much work and many restrictions) models that change place. GreetingsRed KnightOK, we will proceed with the big models for terrain.Additional point, as we're going to use big models (with the cell framework underneath for the rules engine to move the combatants) we're going to need to agree on the size of the "cells", so that the rules engine doesn't try moving combatants through walls, or putting them above/below the floor.At the current time the cells are 1meter x 1meter by 2.5 meters high. And the floor can be 2.5 x 0.3333 m or 2.5 x 0.6666 m, or 0 meters high.Note, from the game engine's view using a different scale for the cells is trivial, but we need to know what it is. (Because it's going to make building the models easier.)Also, do we need to add some other rules about building the terrain models, Such as all ramps, doors etc must be 2 cells wide, so that 2x2 units can navigate the models? Link to comment Share on other sites More sharing options...
red knight Posted April 6, 2008 Report Share Posted April 6, 2008 One minor correction: In my post it sais:Using BSP though is counterproductive as the entire terrain because a polygon soup model (in the extreme case).Should have been read: Using BSP though is counterproductive as the entire terrain BECOMES a polygon soup model (in the extreme case).However, it shouldnt change the interpretation of not using BSPs. For the Cell you can create the Cells rule engine from the geometry pretty easily without human intervention (As long as you agree on the scale of the models). You load the terrain + objects and then for each valid cell position to check to see if there is a blocking polygon in it. Blocking polygons are those that have a certain angle non parallel to the floor or above a certain threadhold on cell covering (to be able to have hills and stairs). Probably it would be important to be able to use smaller cells (than the reference that the soldier/unit uses to be able to handle the stairs as a common case instead of an special case). GreetingsRed Knight Link to comment Share on other sites More sharing options...
Shinzon Posted April 11, 2008 Report Share Posted April 11, 2008 Sorry for the abrupt end of updates; but I entered my final month and the proffesors sure like to pile stuff up... I will be tied up for roughly a month... Link to comment Share on other sites More sharing options...
[dteviot] Posted April 11, 2008 Author Report Share Posted April 11, 2008 Sorry for the abrupt end of updates; but I entered my final month and the proffesors sure like to pile stuff up... I will be tied up for roughly a month... That's fine. I decided to celebrate the release of 0.4 by taking a week off Xenocide development, and instead play UFO:Afterlight. Which has been sitting unopened on my shelf for more than a year. Link to comment Share on other sites More sharing options...
Darkhomb Posted April 11, 2008 Report Share Posted April 11, 2008 Take more then that off, take as much time as you want. You have done an outstanding job. Relax and feel good and go do some others things you enjoy. Link to comment Share on other sites More sharing options...
Recommended Posts