Way to Dynamically Determine How Many Blend Layers? about ozz-animation

[guillaumeblanc]

Hi,

Glad to hear ozz is helping you. Hope to see what you did with it some day!

Back to your question: ozz::animation::BlendingJob is by design able to blend n layer, n being dynamic. samples uses hard coded number indeed, only to allocate layers though.

ozz::Range is generalising the concept of array using internally a begin and end pointer. It allows to pass BlendingJob an array of layers, without imposing a way to allocate the array. ozz::Range can be initialised from:

• a static c array like samples are using.
• a pointer and a size, to use when the array is allocated from new[] operator for example.
• a vector.
• ...

So there should be no problem providing a dynamic number of layers. I suspect the issue is in the way you setup ozz::Range. Can you double check that? There might be a bug also, in ozzRange or BlendingJob. So if you're stuck you can send me your BlendingJob setup and array allocation code.

Hope it helps.

Cheers,
Guillaume

[syonker]

Thank you so much for the quick response! Below is the code from the blend sample with a minor adjustment. When using the Dynamic Code block it cannot make it through blendingjob's validate function, when using the Sample Code block (the original code) everything runs perfectly. What code would you insert in the Dynamic Code block such that the variable layers can be created based on a dynamic value? Thank you, you're the best!

// Blends animations.
// Blends the local spaces transforms computed by sampling all animations
// (1st stage just above), and outputs the result to the local space
// transform buffer blended_locals_

//----Dynamic Code
	int dynamicNumLayers = kNumLayers;

	ozz::memory::Allocator* allocator = ozz::memory::default_allocator();

	ozz::Range<ozz::animation::BlendingJob::Layer> layers = allocator->AllocateRange<ozz::animation::BlendingJob::Layer>(dynamicNumLayers);
//----Dynamic Code


//----Sample Code
	ozz::animation::BlendingJob::Layer layers[kNumLayers];
//----Sample Code


for (int i = 0; i < kNumLayers; ++i) {
  layers[i].transform = samplers_[i].locals;
  layers[i].weight = samplers_[i].weight;
}

// Setups blending job.
ozz::animation::BlendingJob blend_job;
blend_job.threshold = threshold_;
blend_job.layers = layers;
blend_job.bind_pose = skeleton_.bind_pose();
blend_job.output = blended_locals_;

// Blends.
if (!blend_job.Run()) {
  return false;
}

[guillaumeblanc]

Hi,

just found the reason: AllocateRange is a C allocator. It works with POD structures, not objects that require their constructors to be called (like ozz::animation::BlendingJob::Layer which sets some default values).

I just realised also that ozz lacks a way to allocate that sort of arrays, like new[] would do. I'll try to provide that and detect non POD structures used with Allocate* functions.

In the meantime you should be able to fix it in you code, using new[], a vector...

That wasn't obvious! Thanks for reporting the issue.

Cheers,
Guillaume

[guillaumeblanc]

Hi,

I now understand that ozz::memory::Allocator API is error prone, because it exposes object-like allocation functions, but doesn't call constructors/destructors (neither warn about it). It must be fixed.

Have you managed to overcome your issue and blend n layers on your side?

Cheers,
Guillaume

[kylawl]

@syonker if you fully init your layers, you can work around the issue until it's fixed.

for (int i = 0; i < kNumLayers; ++i) {
  layers[i].transform = samplers_[i].locals;
  layers[i].weight = samplers_[i].weight;
  layers[i].joint_weights = ozz::Range<const ozz::math::SimdFloat4>();
}

[syonker]

I guess the issue with my work around at the moment is that I'm not declaring 'layers' correctly then. @kylawl how did you declare 'layers' just before that bit of code you sent in order for it to work in the blend sample and by based on a dynamic value? Thank you so much for the help

[guillaumeblanc]

Hi,

What @kylawl says (thanks BTW) works without changing your allocation strategy. Just add this line to the initialization loop:

for (int i = 0; i < kNumLayers; ++i) {
  layers[i].transform = samplers_[i].locals;
  layers[i].weight = samplers_[i].weight;
  layers[i].joint_weights = ozz::Range<const ozz::math::SimdFloat4>();  // <- Missing initialization workaround
}

BUT, it’s a workaround!

Just to be sure: you don't need to wait for a fix, ozz::animation::BlendingJob and ozz::memory::Allocator are working as expected/documented. The issue is that your allocating your array with a raw memory allocator (à la malloc). This means that ozz::animation::BlendingJob::Layer's are not properly initialized, beacuse their consructors aren't called (thus the workaround). In c++ new/new[] operators should be used to allocate objects/class; that’s one option. I pushed a modified sample to demonstrate it. Another option is using containers like vectors. There are many other options, it's up to you to choose depending on your allocation strategy.

Keep in mind that dynamically allocating is very costly though. It should be avoided during update (ozz does no allocation during update). So I'd recommend to pre-allocate this array, which doesn't prevent you from having dynamic number of layers. Nothing actually prevents you from using a dynamic number of layers...

Hope it helps,
Guillaume

[syonker]

Thank you both so much! That's exactly what I needed. By allocating in my init() function with the provided method by the time update() comes around I have a dynamic based number of layers to access and it works perfectly. Ozz is the best, I'm excited to keep working with it!

[kylawl]

I'm allocating layers using the same method as you with the Ozz allocator. However, I allocate a buffer of layers with the maximum number of layers any object can possibly have and reuse that single layer buffer for each object. In my case it's currently 16. I also init everything by hand because I just blindly assumed that everything in ozz WAS in fact all uninitialized pod types.

…

On Tue, Aug 7, 2018 at 4:26 AM Guillaume Blanc ***@***.***> wrote: Hi, What @kylawl <https://github.com/kylawl> says (thanks BTW) works without changing your allocation strategy. Just add this line to the initialization loop: for (int i = 0; i < kNumLayers; ++i) { layers[i].transform = samplers_[i].locals; layers[i].weight = samplers_[i].weight; layers[i].joint_weights = ozz::Range<const ozz::math::SimdFloat4>(); // <- Missing initialization workaround } BUT, it’s a workaround! Just to be sure: you don't need to wait for a fix, ozz::animation::BlendingJob and ozz::memory::Allocator are working as expected/documented. The issue is that your allocating your array with a raw memory allocator (à la malloc). This means that ozz::animation::BlendingJob::Layer's are not properly initialized, beacuse their consructors aren't called (thus the workaround). In c++ new/new[] operators should be used to allocate objects/class; that’s one option. I pushed a modified sample to demonstrate it <3aee0d2>. Another option is using containers like vectors. There are many other options, it's up to you to choose depending on your allocation strategy. Keep in mind that dynamically allocating is very costly though. It should be avoided during update (ozz does no allocation during update). So I'd recommend to pre-allocate this array, which doesn't prevent you from having dynamic number of layers. Nothing actually prevents you from using a dynamic number of layers... Hope it helps, Guillaume — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEuP1w_5_ygOdcFMuct0FxKGCnl0jyB-ks5uOXl0gaJpZM4VrOPz> .

[guillaumeblanc]

Good to hear it's working and that you're happy!

The mix of pod and non-pod types in ozz data structure is part of the confusion. That's also why I think ozz allocation function should handle constructor calls (when needed).

@kylawl, I am curious why you don't allocate the 16 layers on the stack, like ozz sample are doing? It doesn't consume that much stack, and is thread safe by nature.

Looking forward to see what you're doing with ozz.

Cheers,
Guillaume

[kylawl]

I'm using ozz to service a generalized animation system so while this game limits the max layers to 16, it is a configurable maximum within our editor, not necessarily a compile time constant. Hence the heap allocation.

[guillaumeblanc]

Sounds like an interesting project @kylawl, hope to see it some day!

Looking at ozz Allocator, I saw that typed arrays allocations (those supposed to call constructors) were actually never used by the library, only samples. I presume most users have their own allocator anyway (or use crt). So I removed them, and used vectors in the samples which are safer and easier to read. Here is the change.

[kylawl]

This is what we've been doing with Ozz. https://store.steampowered.com/app/791240/Lumote/

…

On Sat, Aug 11, 2018 at 1:42 PM Guillaume Blanc ***@***.***> wrote: Sounds like an interesting project @kylawl <https://github.com/kylawl>, hope to see it some day! Looking at ozz Allocator, I saw that typed arrays allocations <https://github.com/guillaumeblanc/ozz-animation/blob/master/include/ozz/base/memory/allocator.h#L86> (those supposed to call constructors) were actually never used by the library, only samples. I presume most users have their own allocator anyway (or use crt). So I removed them, and used vectors in the samples which are safer and easier to read. Here is the change <0c2466d> . — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#55 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEuP14ckAHWskR2k2mplsd9aPIl-BXQHks5uP0G5gaJpZM4VrOPz> .