Manipulator与其对应动画在机模展示中的运用
Manipulator与其对应动画在机模展示中的运用
发布于：2021-07-23 23:50
==ENGLISH DOWN BELOW==
之前有几个老哥在问关于机模开发的那个manipulator
我试着在Discord上回复，但那个排版功能是真的劝退
但我用了一晚上还没解决博客这个英文换行问题...也就彼此彼此吧
后面再说，下次一定 :/
回归正题
假如你在X-Plane中做了一个能自由开合/点击开合的车门，该如何解决manipulator与模型的协调问题？
在我们深入主题前，需要先弄清楚manipulator到底是个什么东西
在我们深入主题前，需要先弄清楚manipulator到底是个什么东西
通俗来讲，manipulator-操纵器，是通过输出操纵命令来使得X-Plane与用户之间进行原始数据的处理和交换的。按铁定的规矩，一个机模只能有一个manipulator，但也确实可以通过使用Blender中的empty或类似的不可导出的元素将它们分组，以此来包含多个物品。
但有一点，因为我们的manipulator是要用做写入系统的，那目标Dataref也一定要支持写入。比如在sim/aircraft/controls下的那些，而不是被系统运行的固定系统。
参见下图。在这个项目中，“Clickable”是被钦定的manipulator组，这个父级物体的作用主要就是为了囊括所有子物体的数据，将其打包成一个 “数据包” 并写入obj8文件中。
参见下图。在这个项目中，“Clickable”是被钦定的manipulator组，这个父级物体的作用主要就是为了囊括所有子物体的数据，将其打包成一个 “数据包” 并写入obj8文件中。
Manipulator主要负责如下几个功能：
1. 在3D座舱环境下收集用户光标的位置与其输出值
2. 用Dataref事先在系统中占个位，方便以后快速变动
3. 检测 “高级操作” (像"Wheel Delta" 与 "Drag XY/Axis" 这种param)
4. 敦促系统在每次交互中改变所对应的Dataref
5. **跟着父级物体运动**
第五条有点乱，我来稍微捋一下
Manipulator是被标记为 "驾驶舱可点击区域 "的那种模型，就是那种可以显示绿框框的区域。系统把它当作普通的美工资源来读取，只是不去真正的在环境中绘制它，单纯是因为你在Blender的纹理面板中勾选了 "Draw Object"命令，给了它一个 "ATTR_draw_disable "命令。
顺着这理论往下看。如果manipulator可以被当作一个模型，那我们一定也可以做一些 “神操作”，比如加个动画之类的。你可以让manipulator这个实体模型自己动，也可以用一个轴来做它的父级——在大多数情况下，这样更保险（而且还可以复制父级物体给其他模型用）。但无论你怎么操作，一定记住，动画必须由一个铁打的float/int Dataref驱动，同时也不要忘记调整 [] 中的array number，否则Dataref将无法传递给模型。
可能有老哥能get到《星际穿越》里，那个关于爱的金句？
1. 在3D座舱环境下收集用户光标的位置与其输出值
2. 用Dataref事先在系统中占个位，方便以后快速变动
3. 检测 “高级操作” (像"Wheel Delta" 与 "Drag XY/Axis" 这种param)
4. 敦促系统在每次交互中改变所对应的Dataref
5. **跟着父级物体运动**
第五条有点乱，我来稍微捋一下
Manipulator是被标记为 "驾驶舱可点击区域 "的那种模型，就是那种可以显示绿框框的区域。系统把它当作普通的美工资源来读取，只是不去真正的在环境中绘制它，单纯是因为你在Blender的纹理面板中勾选了 "Draw Object"命令，给了它一个 "ATTR_draw_disable "命令。
顺着这理论往下看。如果manipulator可以被当作一个模型，那我们一定也可以做一些 “神操作”，比如加个动画之类的。你可以让manipulator这个实体模型自己动，也可以用一个轴来做它的父级——在大多数情况下，这样更保险（而且还可以复制父级物体给其他模型用）。但无论你怎么操作，一定记住，动画必须由一个铁打的float/int Dataref驱动，同时也不要忘记调整 [] 中的array number，否则Dataref将无法传递给模型。
可能有老哥能get到《星际穿越》里，那个关于爱的金句？
但在X-Plane里，能够穿越时空的不仅有来自Eric的爱，还有Dataref...
在回到车门那个例子上。如果我们把 sim/cockpit2/switches/door_open[0] 打到 1.0，那么相对应的，sim/flightmodel2/misc/door_open_ratio[0] 也会逐渐增加到1.0，但这一Dataref的变动与影响是全局性的，相当于 这个变化也会影响到manipulator的那个父级物体，带着manipulator这个子物体一起运动。从我们观察者的角度看来，如果车门（美工资源）和manipulator的父级物体绕同一圆心旋转，manipulator就是在贴合着模型运动。
注意下图中门把手（绿色区域）的运动始终贴合车门，同时与一个未协调的按钮的操作区域做比较
综上所述，通过Dataref给予manipulator与视觉模型相同的运动，就其在空间中的正确位移而言，它们（可点击区域，绿色区域）就能随着数据的变化而实时协调移动，实现真正意义上的零延迟操控。换句话说，美工资源和manipulator的父对象都因Dataref变化而移动，导致这两者在物理空间中的协调移动。
这可能是第一部关于PlaneMaker的干货文章，终于也能在这个领域有点话语权了。
这可能是第一部关于PlaneMaker的干货文章，终于也能在这个领域有点话语权了。
后面确实也会发更多的教程，一本关于机模初级开发的手册也将会在可预见的未来免费发布。
考虑到类似需求不是很高，文章先敲的英语。稍微有点翻译腔，见谅 
====English====
Few of you guys were asking about the manipulator and stuff in aircraft dev.
Was trying my best on Discord, but with the glitchy formatting and all that, it's just a meh.
Was trying my best on Discord, but with the glitchy formatting and all that, it's just a meh.
But after a night of coding on that auto link-break stuff and ended up with no luck, it feels shit.
Imma take a further look later, just not today :/
Back to the topic.
Imagine you wanna make a car door in X-Plane which could be open and closed by dragging or clicking on the handle object, how can you get it done with the collaboration between the visual model and its manipulator?
Before we dive too quickly, what is a manipulator?
Generally speaking, the manipulator is the one that manipulates the processing and exchanging of raw data between the user and X-Plane itself by outputting manipulative commands. Ruled by default setting, an aircraft shall only have one manipulator object, which however may contain multiple objects by grouping them together using an axis or similar non-exportable stuff in Blender.
However, as we're trying to export some sort of command to the system, the Dataref must be writeable, like the ones in sim/aircraft/controls but not those fixed data running solely by the system.
Referring to the graph below, the "Clickable" group in this particular project is the one with honor, who acting as a manipulator and collecting everything from the minions, ended up with a holistic "data pack" for X-Plane to read and process.
Back to the topic.
Imagine you wanna make a car door in X-Plane which could be open and closed by dragging or clicking on the handle object, how can you get it done with the collaboration between the visual model and its manipulator?
Before we dive too quickly, what is a manipulator?
Generally speaking, the manipulator is the one that manipulates the processing and exchanging of raw data between the user and X-Plane itself by outputting manipulative commands. Ruled by default setting, an aircraft shall only have one manipulator object, which however may contain multiple objects by grouping them together using an axis or similar non-exportable stuff in Blender.
However, as we're trying to export some sort of command to the system, the Dataref must be writeable, like the ones in sim/aircraft/controls but not those fixed data running solely by the system.
Referring to the graph below, the "Clickable" group in this particular project is the one with honor, who acting as a manipulator and collecting everything from the minions, ended up with a holistic "data pack" for X-Plane to read and process.
Manipulators do few things:
1. Collecting user mouse output from 3D cockpit view
2. Register a clickable spot by using Dataref
3. Identifying advanced movement (In cases like "Wheel Delta" and "Drag XY/Axis" param)
4. Deliver a command to the system urging for a change on each interaction
5. **Obey the change in parent object**
The number 5 is seemingly confusing, lemme explain a bit here.
Manipulators are model(s) which have been marked as "cockpit clickable region". The system read it as normal art assets, just hesitate to draw it simply because you have given it an "ATTR_draw_disable" command by ticking off the "Draw Object" command in the Texture Panel.
Along with this theory, the manipulator can be treated like a model, there's thus plenty of room for us to make some moves like animation and all that. You can either make the model animative on its own, or you can grab an axis to be its parent which is a more secure choice in most cases. But whatever you choose, remember that the animation has to be driven by a solid float/int Dataref. Yet, don't forget to adjust the array number in [] or it won't be shown correctly.
Some of you may remember the quote from the movie "Interstellar" about love...
1. Collecting user mouse output from 3D cockpit view
2. Register a clickable spot by using Dataref
3. Identifying advanced movement (In cases like "Wheel Delta" and "Drag XY/Axis" param)
4. Deliver a command to the system urging for a change on each interaction
5. **Obey the change in parent object**
The number 5 is seemingly confusing, lemme explain a bit here.
Manipulators are model(s) which have been marked as "cockpit clickable region". The system read it as normal art assets, just hesitate to draw it simply because you have given it an "ATTR_draw_disable" command by ticking off the "Draw Object" command in the Texture Panel.
Along with this theory, the manipulator can be treated like a model, there's thus plenty of room for us to make some moves like animation and all that. You can either make the model animative on its own, or you can grab an axis to be its parent which is a more secure choice in most cases. But whatever you choose, remember that the animation has to be driven by a solid float/int Dataref. Yet, don't forget to adjust the array number in [] or it won't be shown correctly.
Some of you may remember the quote from the movie "Interstellar" about love...
Well, the thing is, Dataref is another thing that transcends time and physical space in X-Plane.
Back to the door example above, if we toggle the sim/cockpit2/switches/door_open[0] to 1.0, the cor-responding sim/flightmodel2/misc/door_open_ratio[0] will rise. However, this global attribution also impacts the parent object of the manipulator, which resulted in a rotation on the manipulator (clickable region) and empowers it to be able to "follow" the track of the visual mode, given that they're using the same rotational pivot.
Notice how the door handle (green clickable region) moves with the door in the gif below, compare with a static button.
Back to the door example above, if we toggle the sim/cockpit2/switches/door_open[0] to 1.0, the cor-responding sim/flightmodel2/misc/door_open_ratio[0] will rise. However, this global attribution also impacts the parent object of the manipulator, which resulted in a rotation on the manipulator (clickable region) and empowers it to be able to "follow" the track of the visual mode, given that they're using the same rotational pivot.
Notice how the door handle (green clickable region) moves with the door in the gif below, compare with a static button.
By giving the manipulator the same treatment as a visual model, in terms of its correct displacement in space, they (the clickable area, the green region) will then be able to move along with the change on data in real-time, with zero delays. In other words, both the visual object and the manipulator's parent object have been affected by the change in Dataref, resulted in a coordinative move in these two.
Probably this is gonna be the first post on PlaneMaker rather than scenery dev, but I'll definitely do more in the future. And yes, a completed handbook regarding primary aircraft development is on the way.
Probably this is gonna be the first post on PlaneMaker rather than scenery dev, but I'll definitely do more in the future. And yes, a completed handbook regarding primary aircraft development is on the way.
2条评论，2人参与。