<div dir="ltr">Hope that the main goal of the manual is to teach people how to, but not just to provide separated chunks of information.<br><br>Quick guidelines about MUST, SHOULD, MAY - according to RFC 2119, and how this could be applied in documentation<br><a href="https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#introduction-terminology">https://www.khronos.org/registry/vulkan/specs/1.0/xhtml/vkspec.html#introduction-terminology</a><br><br><br><br>IDEA: TOC improvement. Avoiding Sphinx toctree &amp; templates complexity.<br><br>Motivation:<br>Manual is not to hide information, but to make it easy and quickly searchable and accessible<br><br>Suggestion:<br>* Make all nodes in the table of contents (TOC) opened by default as the MUST, to provide ability for browser CTRL+F search when needed.<br>* Focus on the simplicity of the manual toctree.<br>* Make theme as simple as possible, avoid templates complexity<br>* Engage the linearity of the table of contents.<br><br><br><br>IDEA: Separate manual according to digital artist workflow<br><br>Motivation:<br>Divide And Conquer (DAC). Modeling, Animation, Rendering by themself&#39;s are so complex &amp; fundamental pipelines that it should be very hard or even impossible to fully describe them and make it easy to follow in single Reference Manual.<br><br>First Things First (FTF). What is needed to understand how to successfully work in blender? Interfaces &amp; Operations for 3D Space Navigation &amp; Object Modeling. All other workflows follows only after this first fundamental constraint is accomplished. When you see the 3rd subsection, it&#39;s already time to think that topic is complex enough to separate it aside. Than more sections &amp; subsections, then harder to follow...<br>Example: Editors&gt;3D&gt;3D View&gt;Navigating&gt;Navigation&gt;Rotating.<br><br>Terms and conditions (Prerequisites) always goes first, tools/operations follows, and the techniques finally connects all together and shows how to apply obtained knowledge.<br><br>Suggestion:<br>Separate reference manual according to digital artist workflow:<br>(Editors &amp; Interfaces|Modeling|Animation|Rendering)Manual {Glossary, Operations, Techniques, etc...}<br><br>* Editors &amp; Interfaces Manual MUST describe GUI of Editors &amp; Interfaces.<br>* Modeling Manual MUST describe 3D modeling Operations (Create/Remove object, Translate, Rotate, Scale, Create/Remove vertex, etc...) &amp; Techniques (Extrusion modeling, Digital sculpting, etc...)<br>* Animation Manual MUST describe animation Operations (Create/Remove keyframe, Create/Remove Action etc...) &amp; Techniques (Rigging, Skinning, etc...)<br>* Rendering Manual MUST describe rendering Operations (Change resolution, Change frame rate, etc...) &amp; Techniques (Ray casting, Ray tracing, Shading, Texture-mapping, Bump-mapping, etc...)<br><br><br><br>IDEA: Sortable Table for Blender Operations (Sphinx + JQeryTableSorterPlugin)<br><br>Motivation:<br>Operations in blender could be described as (Create, Remove, Select, Change, Copy, Insert, etc...). Objects &amp; entities to which they are applied are different, but the meaning of operations is still the same. Most operations have the same properties like Editor, Mode, Hotkey, etc... If you will need to quickly look which operations could be applied in particular mode or editor, you can do it easy with sortable table.<br><br>Suggestion:<br>* Make sortable table which will describe the operation itself &amp; all needed Requirements &amp; Constraints. (HTML + JQueryTableSorterPlugin)<br>Format could be like:<br>| Name | Description | Editor | Mode | Object/Entity of Application | Hotkey | etc...<br>* Mark operations using semaphore methodology, - (MUST - Red|SHOULD - Green|MAY - Blue) be learned!<br><br>Proof:<br><a href="https://youtu.be/Yu5VY0JTCIM">https://youtu.be/Yu5VY0JTCIM</a> Sphinx + JQeryTableSorterPlugin integration. Ready to attach code example if needed.<br><br><br><br>IDEA: Discipline &amp; Discipline Technique. Sections: Rigging, Skinning, Sculpting, Compositing<br><br>Motivation:<br>There are no strong division between what is: Discipline OR Technique OR Operation OR Term OR Interface, etc ... All is intermixed heavily ...<br><br>Computer Animation is a discipline and Rigging is it&#39;s technique, so &quot;Animation Manual {Techniques&gt; Rigging}&quot;. 3D Modeling is a discipline and Sculpting is it&#39;s technique, so &quot;Modeling Manual {Techniques&gt; Sculpting}&quot;. Computer-generated imagery (CGI) &amp; Video Editing is a discipline and Compositing is it&#39;s technique, so &quot;CGI &amp; Video Editing Manual {Techniques&gt; Compositing}&quot;. Now look at the 2.78 manual layout by the way, with a point in mind to visually find all sections described above ;)<br><a href="https://www.blender.org/manual/editors/index.html">https://www.blender.org/manual/editors/index.html</a><br><br>Rigging &amp; Skinning are major animation workflow steps and could be even classified as animation techniques, but it seems strange that Rigging section moved aside of the Animation section and the Skinning much worst is inside Rigging&gt;Armatures&gt;Skinning<br>According to animation workflow it must be, in worst case, at least something like this:<br>Animation Manual {Techniques&gt;Rigging|Skinning|Weight Painting|Posing|Keyframing}<br><br>Techniques sections (Rigging, Skinning, Sculpting, Compositing, etc...) MUST NOT describe Blender editors, interfaces, operations, etc... in details. They must point out to the concepts of the technique itself and provide links to the exact Operations which applied in this technique. Operations themselves are fundamental building blocks which user MUST know anyway to be able to apply them in Technique. So it&#39;s better to describe them before and separately example:<br>Modeling Manual {Operations&gt; Create / Remove Object | Select Object ... | Rotate | Transate | Scale | Join | Create/Remove Vertex | Create/Remove Edge | Create/Remove Face | etc ...}<br><br>Suggestion:<br>Describe technique fundamental concepts and principals with references to Glossary and Operations which required to apply while using this particular technique. &quot;Big picture&quot; video showing the result of this particular technique (All videos not longer than N minutes).<br><br><br><br>IDEA: Animation Constraints &amp; Physics Constraints/Kinematic pairs<br><br>Motivation:<br>Animation &amp; Physics, are in fact so complex topics that they deserve to be described separately and in details.<br>Somebody will never use pure physics constraints aka kinematic pairs for animation as the bullet physics engine itself at all.<br><br>If to speak about constraints, there are two types of constraints which MUST NOT be intermixed.<br>1) Classical mechanics, - Kinematic pair constraints, which are pure physics.<br><a href="https://en.wikipedia.org/wiki/Kinematic_pair">https://en.wikipedia.org/wiki/Kinematic_pair</a><br>2) Rigging constrains aka animation controllers<br><a href="https://en.wikipedia.org/wiki/Skeletal_animation#Technique">https://en.wikipedia.org/wiki/Skeletal_animation#Technique</a><br>1st type is partially applied to implement 2nd type but 1st type is the theoretical fundamentals, while second is applied extension of the 1st type, and logically, information must be provided separately to avoid constraints hell.<br>In fact, - there are several animation techniques, at least:<br>* Physically based animation. Pure Kinematic pair constraints, physical laws and forces simulations applied.<br><a href="https://en.wikipedia.org/wiki/Physically_based_animation">https://en.wikipedia.org/wiki/Physically_based_animation</a><br>* Skeletal Animation. Rigging constrains aka animation controllers applied.<br><a href="https://en.wikipedia.org/wiki/Skeletal_animation">https://en.wikipedia.org/wiki/Skeletal_animation</a><br>* Motion Capture Animation. Captured locomotion &amp; Rigging constrains aka animation controllers applied.<br><a href="https://en.wikipedia.org/wiki/Motion_capture">https://en.wikipedia.org/wiki/Motion_capture</a><br>* Intermixed Animation. Any combination of the above Techniques or all applied.<br>etc...<br><br>Suggestion:<br>* Describe Animation Constraints &amp; Physics Constraints separately to free users from reading and trying to understand things, that will be never applied by them.<br>Blender Animation Manual {Motion Control&gt;Constraints}<br>Blender Physics Manual {Motion Control&gt;Constraints}<br></div>