Art-Centric workflow
conceiving AA correctly
--------
This core philosophy regards art in the sense of design, technicality and functionality, not "graphics" and certainly not "graphics over gameplay", as that all actually becomes somewhat an abstract with this fully scalable approach. Graphics become outdated and obsolete, but art does not, and this has cascading implications. It actually makes things a little more difficult for artists, but aims only to synchronise content creation and gameplay programming by laying almost all optimisation and polish obligations at the feet of artists, while also arming them with the tools and techniques to accomplish literally anything graphically, placing design as a fundamental concern and the common pursuit.
Without fully utilising LOD and portalisation, modern 3D games typically suffer from pop-in, performance problems and low framerates, requiring heavy-handed blanket optimisations and therefore being difficult or impossible to make portable, with the cross-generation releases demonstrating this more severely with each passing era. A huge problem arises from the common practice of automatic UV unwrapping on ever-increasing model complexities, resulting in many more arbitrarily orientated UV islands than is absolutely necessary, and which are directly at odds with the following automatic LOD generation methods. It results in lower LOD stages that are very too few (worth using) and those few not being closely presentable and thus locked to, which is massive for optimisation potential and porting. With combinations of UVs and LOD in futile opposition, rebaking of textures and harsh LOD transitions and/or LOD-throttling, it not only causes undesirable visual artifacts and limits potential, but throws resource management out of balance by underutilising the vertex buffer and simply throwing more textures at the solution, both resources better used elsewhere. There are reasons for this sticky situation.
Intermediate UV skills are a lost art, being that it falls between texture artists and 3D modellers, often in dispute, and polycounts have increased to fairly unmanageable densities and complexities, a predictable calamity for non-parametric modelling, especially when there are so many hands in the cookie jar. The solution is patch-mesh mapping and spline-cage modelling which is fundamentally parametric in nature in several different ways, but that's already discussed by now (below) and a giant aspect of that involves UV texture coordinates done manually and correctly. The broader technical explanation involves unbalanced resource management, off-kilter GPU memory, a drastically underutilised vertex-buffer, and modern approach to texturing by streaming from flash storage, which is great, but not to lean on so, so heavily, a typical practice that needs to change. Low framerates from a bad approach, not because the hardware doesn't have plenty of meat on the bone, but because from the moment a project begins it steps into this conundrum, one foot after another. This philosophy counters this core conundrum, as raster pixel-art is to non-parametric modelling as vector-graphics is to spline-cages, beyond the constraints of exactly how it's rendered in many different aspects, and is fully adaptable and scalable.
This also counters the common issue of programmers bearing the brunt of the majority of optimisation fixes, with render-distance and lighting and shadows usually suffering as first casualties. Sweeping reductions in overall material complexity is usually also enforced, as these are blanket "light-switch" tweaks that can be done without needing to refactor any art content. Optimisation is a team effort, and with programmers having enough of their own optimisation to do on their own code, it's vital to have a base full of scalable assets that can be tweaked using programmable parametrics, scripted right from the command-line and handled exclusively by the artists themselves. This all does have a particular side-effect of pushing mappers to the forefront as primary designers, because they become the primary optimisers and as they are already the masters of all metrics, metrics that are derived from a common consensus between mappers and metrics that directly inform gameplay mechanics, and because so much can already be achieved with modern engines. Potentially even a full game.
It's this consensus and provision that actually frees and enables the programmers to focus on core gameplay mechanics, and only that. Tight and stable, fun and interesting, reliable and efficient, realising the "three pillars of game development", even if the code is complicated and somewhat systems-based in itself. So much optimisation on one side of the team provides allowances for others. Mappers provide simplified physics, among other optimisations, allowing fine-tuning and polish to be handed over to animation and physics, and tables and arrays in scripts, which are all relegated to the domain of the artists en masse. It promotes a systems-based core programming approach, negating busy-work and allowing concern for stability not only for the engine and its performance, but for the team and its workflow. Modern game engines such as Unreal already provide many systems-based frameworks and in conjunction with blueprint-style gameplay-design, things like basic combat encounters and physics puzzles can already flesh-out vast amounts of player experience, which is common even in the development of modern major flagship titles.
This philosophy goes further beyond even all of that, however, as data-management is governing asset scalability, automating spline-cages, patch-meshes, material-complexity, physics and effects, among uncountable other tweaks that manage optimisation, resource management, workflow and asset deployment, right up to the finish line. All content actually becomes untethered from any engine, from 'OGRE' for the sake of legacy function, to 'Mental Ray' for the sake of grand vision, to 'Unreal' for the sake of a playable release, or indeed any other engine the team should wish to target. This freedom relieves programmers of babysitting duties, allowing them to focus on making gameplay fun, interesting and bug-free, with each artist standing independent and capable, interfacing directly with the base and its deployment, cultivating a team-effort, design by consensus and mappers becoming the primary nexus-points of development, as they should. This negates the risk of content having a shelf-life, and a project is as artwork unto itself, to publicly present itself as a project, and as both artistically beautiful and technically scalable, thus the name. At the end of the day, the truth is that isolated artists stand better chance of the essential snowball effect required to launch an ambitious modern game development endeavour than isolated programmers are, thus the philosophy.
https://www.violationentertainment.com/wiki/tiki-index.php?page=Splinecage-Synopsis
https://www.violationentertainment.com/wiki/tiki-index.php?page=Spline-cages
https://www.violationentertainment.com/wiki/tiki-index.php?page=Buttertub
https://www.violationentertainment.com/wiki/tiki-index.php?page=Spline-cages(advanced
https://www.violationentertainment.com/wiki/tiki-index.php?page=Splinecage-phase(solutions)
https://www.violationentertainment.com/wiki/tiki-index.php?page=UVmesh-to-Splinecage(recipe)
.
.
.
;){kind=link}