<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>Hello Alex,<br>
</p>
1. Workflow<br>
<br>
The Manual is not primarily workflow based anymore it's a
specification (UI based).<br>
Workflow descriptions still exist separated under sub-headlines same
as examples.<br>
But isn't a specification in a pure technical sense with all the
formal demands (not following any RFC ####).<br>
<br>
The time effort of a workflow based manual is for various reasons
way to high.<br>
Time consuming to write and more important to maintain.<br>
It is out of scope. Even if step by step walktroughs is the industry
standard - that's a luxury especially in form of videos.<br>
(<a class="moz-txt-link-freetext" href="https://opensource.com/business/16/1/scale-14x-interview-bob-reselman">https://opensource.com/business/16/1/scale-14x-interview-bob-reselman</a>).<br>
Unfortunately that leads to "separated chunks of information".<br>
<br>
There are alternatives that fill that gab:<br>
Hundreds of videos/blog posts that explain the "basics"<br>
fitting the diverse background of user and what she wants to
achieve.<br>
<br>
<br>
2. Structure<br>
<br>
2.1. TOC<br>
<br>
There's a search function and links. The full toc has 735 KB -
average is 10 KB per index.<br>
What you propose would be <a class="moz-txt-link-freetext" href="http://getakka.net/docs/">http://getakka.net/docs/</a>?<br>
Don't know what you mean with templates:
<a class="moz-txt-link-freetext" href="http://jinja.pocoo.org/docs/dev/">http://jinja.pocoo.org/docs/dev/</a> ?.<br>
<br>
2.2. Sections<br>
<br>
Digital artist workflow = digital production pipeline?<br>
There simply isn't a single workflow/big picture there are a half a
dozen.<br>
It worked for years now, no problem showed up.<br>
Even if, planning such big changes take huge amount of time, not
even talking about applying changes.<br>
<br>
<br>
The non editor chapter are there for:<br>
A) Shared topics between editors (data system, animation, sculpting
& painting) (physics, rendering)<br>
B) To flatten the structure which would be else all in 3D View
(modeling).<br>
<br>
To give an orientation I added sections descriptions on
content.html.<br>
<br>
2.3 Semantics:<br>
<br>
Discipline or technique that's a semantic like discussion.
Practically it doesn't matter.<br>
Rigging = rigging in Blender.<br>
<br>
I disagree about constrains. I guess you based this on a wrong (or
inaccurate) definition of animation.<br>
(wikipedia is not in any way reliable).<br>
<br>
and TBH TL;DR<br>
<br>
<br>
The Plugin:<br>
<br>
What you propose is a html select menu that lets the user switch<br>
e.g. the Select Group menu versions for the different object types.<br>
<br>
While the content is in the table?<br>
It would be something for a separate website like a hotkey list.<br>
<br>
Indeed that's is a problem, but it's solved by hierarchies:<br>
<br>
Object mode > edit mode > mesh > curve > surface |
armature<br>
Timeline > graph editor > dope sheet > NLA<br>
<br>
The reader has to have the ability understand abstract concepts e.g.
replacing vertex with object origin.<br>
<br>
Regards,<br>
Tobias<br>
<br>
<div class="moz-cite-prefix">Am 25.01.2017 um 09:45 schrieb Alex
Cham:<br>
</div>
<blockquote
cite="mid:CACGVZ9xTozcujOpXLLZF2RriS85i6QmdtF8KKnFFRfeBmQ4UwA@mail.gmail.com"
type="cite">
<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 moz-do-not-send="true"
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 & 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's are so complex & 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 & Operations for 3D
Space Navigation & Object Modeling. All other workflows
follows only after this first fundamental constraint is
accomplished. When you see the 3rd subsection, it's already time
to think that topic is complex enough to separate it aside. Than
more sections & subsections, then harder to follow...<br>
Example: Editors>3D>3D
View>Navigating>Navigation>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 & Interfaces|Modeling|Animation|Rendering)Manual
{Glossary, Operations, Techniques, etc...}<br>
<br>
* Editors & Interfaces Manual MUST describe GUI of Editors
& Interfaces.<br>
* Modeling Manual MUST describe 3D modeling Operations
(Create/Remove object, Translate, Rotate, Scale, Create/Remove
vertex, etc...) & Techniques (Extrusion modeling, Digital
sculpting, etc...)<br>
* Animation Manual MUST describe animation Operations
(Create/Remove keyframe, Create/Remove Action etc...) &
Techniques (Rigging, Skinning, etc...)<br>
* Rendering Manual MUST describe rendering Operations (Change
resolution, Change frame rate, etc...) & 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 & 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
& all needed Requirements & 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 moz-do-not-send="true" 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 & 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's
technique, so "Animation Manual {Techniques> Rigging}". 3D
Modeling is a discipline and Sculpting is it's technique, so
"Modeling Manual {Techniques> Sculpting}". Computer-generated
imagery (CGI) & Video Editing is a discipline and
Compositing is it's technique, so "CGI & Video Editing
Manual {Techniques> Compositing}". 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 moz-do-not-send="true"
href="https://www.blender.org/manual/editors/index.html">https://www.blender.org/manual/editors/index.html</a><br>
<br>
Rigging & 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>Armatures>Skinning<br>
According to animation workflow it must be, in worst case, at
least something like this:<br>
Animation Manual {Techniques>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's better to
describe them before and separately example:<br>
Modeling Manual {Operations> 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. "Big picture" video
showing the result of this particular technique (All videos not
longer than N minutes).<br>
<br>
<br>
<br>
IDEA: Animation Constraints & Physics Constraints/Kinematic
pairs<br>
<br>
Motivation:<br>
Animation & 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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="https://en.wikipedia.org/wiki/Skeletal_animation">https://en.wikipedia.org/wiki/Skeletal_animation</a><br>
* Motion Capture Animation. Captured locomotion & Rigging
constrains aka animation controllers applied.<br>
<a moz-do-not-send="true"
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 & 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>Constraints}<br>
Blender Physics Manual {Motion Control>Constraints}<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Bf-docboard mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Bf-docboard@blender.org">Bf-docboard@blender.org</a>
<a class="moz-txt-link-freetext" href="https://lists.blender.org/mailman/listinfo/bf-docboard">https://lists.blender.org/mailman/listinfo/bf-docboard</a>
</pre>
</blockquote>
<br>
</body>
</html>