提供spine可被自定义顶点数据格式的方法 #18511
提供spine可被自定义顶点数据格式的方法 #18511
Conversation
Code Size Check Report
Interface Check Report! WARNING this pull request has changed these public interfaces:
@@ -70480,8 +70480,9 @@
model: _cocos_spine_skeleton_cache__SpineModel;
boneInfos: _cocos_spine_skeleton_cache__FrameBoneInfo[];
}
export class _cocos_spine_skeleton_cache__AnimationCache {
+ static customVfmts(customizedOneColorVfmt: gfx.Attribute[], customizedTwoColorVfmt: gfx.Attribute[]): void;
protected _instance: sp.spine.SkeletonInstance | null;
protected _state: sp.spine.AnimationState;
protected _skeletonData: sp.spine.SkeletonData;
protected _skeleton: sp.spine.Skeleton;
|
cocos/spine/assembler/simple.ts
Outdated
| public static customVfmts (customizedOneColorVfmt: Attribute[], customizedTwoColorVfmt: Attribute[]): void { | ||
| vfmtOneColor = customizedOneColorVfmt; | ||
| vfmtTwoColor = customizedTwoColorVfmt; | ||
| _byteStrideOneColorCustomized = getAttributeStride(vfmtOneColor); |
There was a problem hiding this comment.
Does it need to recalculate _byteStrideOneColor?
There was a problem hiding this comment.
Yes, when the number of bit stride in the custom vertex format is different, it needs to be recalculated
There was a problem hiding this comment.
It's not recalculate here.
| @@ -95,8 +93,6 @@ class Simple implements IAssembler { | |||
| public static customVfmts (customizedOneColorVfmt: Attribute[], customizedTwoColorVfmt: Attribute[]): void { | |||
| vfmtOneColor = customizedOneColorVfmt; | |||
| vfmtTwoColor = customizedTwoColorVfmt; | |||
There was a problem hiding this comment.
As colorVfmt is customized, _byteStrideOneColor & _byteStrideTwoColor can not be delcared as const.
And its value must be recalculated here
There was a problem hiding this comment.
The _byteStrideOneColor & _byteStrideTwoColor in the realTimeTraverse function is always used because The vertex data format obtained in spine.wasmUtel.wasm.heap8 is fixed. The custom vertex format byteStripe can be obtained from the renderData's allocator without the need for recalculation
| @@ -28,12 +28,15 @@ import { vfmtPosUvColor4B, vfmtPosUvTwoColor4B, getAttributeStride } from '../2d | |||
| import spine from './lib/spine-core'; | |||
| import { SkeletonData } from './skeleton-data'; | |||
| import { warn } from '../core/platform/debug'; | |||
| import { Attribute } from '../gfx'; | |||
|
|
|||
| const MaxCacheTime = 30; | |||
| const FrameTime = 1 / 60; | |||
| const _useTint = true; | |||
| const _byteStrideOneColor = getAttributeStride(vfmtPosUvColor4B); | |||
| const _byteStrideTwoColor = getAttributeStride(vfmtPosUvTwoColor4B); | |||
There was a problem hiding this comment.
_byteStrideOneColor may be changed after call customVfmts();
There was a problem hiding this comment.
The _byteStrideOneColor in skeleton-cache.ts will always be used because the vertex data format obtained in spine.wasmUtel.wasm.heapu8 in updateRenderData is fixed. And the customized 'byteRideOneColorCustomized' only needs to be calculated in customVfmts
No description provided.