Editing Modelling guidelines

== Before you get started ==
* keep in mind that someone else might already be working on the unit you were planning to remodel, so check [https://docs.google.com/spreadsheets/d/11UyxUYvkbwck0F2cEVEdHvxxtllXzOBDkXnOtb-4fK8/edit#gid=126218909 the remodel tracker]. We also accept "loose" models (i.e. not remodels of existing units) but by default these will just join a sort of unused model pool for use by modders or experiments.
* be aware that devs are handling other stuff and are not artists at heart so your model may get "difficult" feedback and it may take a while to implement it. Don't get discouraged!
* be aware that implementing a model into the game takes some knowledge of the game engine, so realistically you will require help at some point. Don't be afraid to ask!

== Preparation ==
Here's a bunch of things to think about and take into account when laying the foundations for your model.

* let people know you're starting work to get initial feedback (#modelling channel on ZK Discord).
* if you're doing a remodel, the existing model is your authoritative source of concept art. Identify what makes it unique and replicate it. An ideal remodel is merely a strict quality upgrade.
* a thing to watch out is whether the unit can fire "over itself", i.e. another unit of the same type. If the original unit blocks itself from firing then this should carry over to a remodel.
* the model should generally not have any bits sticking out too much since they will clip into adjacent things. A good model can fit "neatly" inside a sphere or a box.
* the model should be split into separate pieces, which double as the 'bones' of the model (skinning is supported with up to 4 pieces/bones per vertex though). More technical info at [[Blender_To_Zero-K|the more technical modelling guide for Blender]].
* use the existing model as a reference for the order of magnitude when it comes to polygons, perhaps check some similar units from the same unit class (there's [https://github.com/ZeroK-RTS/Zero-K/issues/5214 a ticket aiming to produce a full listing], maybe it will contain something interesting by the time you read it). As a ballpark you can get into thousands unless the unit is particularly spammable (say Flea).
* keep the texture on the smaller side (say 512 or 1024 unless it's a rare unit), again check the ticket above or look at similar units. If you plan to remodel a handful of similar units it is an excellent idea to use a shared texture (atlas) between them, which gives benefits in visual consistency and rendering performance and is a good reason to make the texture much larger.

== During work; initial feedback ==
This is the stage where the basic model shape is done and you want to move onto the details.

* double-check that there is a materials texture (second texture whcih defines shininess etc) and also a normals texture (FIXME normals may currently be broken)
* feedback, and eventually model approval, comes from GoogleFrog. Show him (and perhaps the general modelling community at #modelling) some screenshots or a video, the earlier you do so the more chance of finding potential problems. GoogleFrog is the lead dev/designer and is quite busy with other stuff so it may take him a while to give feedback.
* if GF initially has negative feedback you can talk to Niarteloc for a quicker response.

== Model has taken up shape ==
* at this point, getting feedback involves a proof-of-concept implementation of the model ingame that GoogleFrog could test.
* salient places on the model (e.g. tip of the barrel where projectiles will appear) will need an empty piece with no geometry and just the "origin" set to their location.
* the model needs a basic animation at this point but unfortunately this involves Lua code. Look at existing scripts to get a basic idea. Otherwise it should largely be a matter of placing files in the directory structure correctly.
* if you're willing to do this on your own, check out these: (FIXME add links some example accepted PRs, maybe a scripting guide or something)
* eye candy (special effects, fancy animations etc) are optional at this point (but of course if you manage to implement them that's great).
* talk to Niarteloc or Sprung if you struggle with this step.

== After the base model is done ==
* check with GoogleFrog again to make sure it's really ready.
* there needs to be a wreck model. It is a mangled version of the base mesh, and there's a standard texture for wrecks so you don't need to provide one (but are welcome to if it makes the wreck look much better, just keep the color tone the same as default).
* remaining salient places, e.g. eye candy particle spawners (tips of aircraft wings for blinking lights, underside of tank treads for dust kickup etc) need an empty piece as well, if you haven't added them in earlier stages.
* playtesting the model would be great. Play a game vs bots using the model (FIXME link a basic modding guide here)