Expose model frame data to ZScript?

[AFADoomer]

Can parsed MODELDEF data and model lookup information be exposed to ZScript (I'm assuming in a read-only manner), so that model frame information can be retrieved by an actor?

At first glance, it looks like exposing the FSpriteModelFrame struct, the gl_FindModelFrame function, and the Models array (all as used in models.h/models.cpp), would be necessary do the job... But it's probably more complicated than that.

Specifically, I'd like to be able to retrieve an actor's models' current frame number, rotation, pitch, roll, scale, and offsets.

[Nash]

If we're going to have ZScript support for models, I'd also like commands to change the current model mesh and texture at runtime.

[Graf Zahl]

This is a great example of 'looks good on paper, but beware the consequences'. The main issue with the current data is that it's a very tight coupling of models with Doom's state structure.

What if skeletal animations get added? I'm not even sure that the data needed for those would even closely resemble what's there right now and may necessitate some extensive refactoring of the internal representation.
Even worse, what if the distinct states get replaced by a timed animation? The feature will be rendered useless or even worse, prohibit future expansion.
That being said, exposing the data to the script would at least be doable, if you were willing to accept this becoming a feature blocker. If someone got some constructive ideas, be my guest, but I'd prefer not to do it.

But actually changing it will open a completely different can of worms because what was previously static and encapsulated inside the renderer will now have to be preserved across savegames. Ugh...

[ZZYZX]

I already have my own MD3 parser, and it's trivial to add few more options to the result (it already knows how to scale and rotate).
I could even implement a simple MODELDEF parser over it but I see no point of doing so. I'd rather explicitly specify frames in my mod and it will never break because my MD3 loading and collision code will be separate from what engine does.
And either way I wouldnt use MODELDEF for collisions (I hope that wasn't your idea that you want this feature for) because colliding with animated models is a lot harder than static ones.

But, on the other side, I'm not sure why it should be a feature blocker if playsim code can retrieve the current state of the model that will be rendered at 0.0 of the current playsim frame.
Here, if skeletal or timed animation ever gets implemented, the model will still have some frame considered "current".
Not sure if it makes any sense to retrieve model frames other than the currently displayed one, and specifically that (being able to access non-current model data) can be a feature blocker.
It can even be a completely separate functionality that provides an abstract interface to return some data about the model, unrelated to how it got this data (might even copy vertices around in case modder wants to do a snapshot of a timed animation). The point here being that if you use an abstract interface, it's no more tied to the internal representation and as such does not really require you to keep the engine implementation unchanged in the future.

Also, another question: are you sure that you don't just want to be able to use MD3 tags (or tag-like entities in other model formats)?

But actually changing it will open a completely different can of worms because what was previously static and encapsulated inside the renderer will now have to be preserved across savegames. Ugh...

Note: engine-based skeletal animation would have to be preserved in savegames too, no? If users are given the ability to freely manipulate skeleton nodes (they should be)?

[Graf Zahl]

I already have my own MD3 parser, and it's trivial to add few more options to the result (it already knows how to scale and rotate).
I could even implement a simple MODELDEF parser over it but I see no point of doing so. I'd rather explicitly specify frames in my mod and it will never break because my MD3 loading and collision code will be separate from what engine does.
And either way I wouldnt use MODELDEF for collisions (I hope that wasn't your idea that you want this feature for) because colliding with animated models is a lot harder than static ones.

That's indeed missing. What's the use case here? Using a model frame's vertex data from inside ZScript will kill your performance for sure and it's still very questionable that it can even be done properly. Remember, the current collision code is among the most inefficient and most badly written code in the entire engine and doing full model collision would probably necessitate a full rewrite of how movement is performed. Nearly the entire algorithm depends on rectangular bounding boxes.

Note: engine-based skeletal animation would have to be preserved in savegames too, no? If users are given the ability to freely manipulate skeleton nodes (they should be)?

That depends on how it is done. I'd imagine that in most cases the actual animations will be statically defined in either DECORATE, ZSCRIPT or some extended MODELDEF. In such a scenario it should be enough to specify the exact position inside an animation to properly restore it but not the entire definition data.

Of course, if at some future time some more advanced model system gets implemented that may change but I have to wonder here, how much that is feasible in a Doom engine.

[Rachael]

Independent of the concerns expressed by ZZYZX and Graf, I do want to respond to one point Graf made:

I really MUCH rather the engine remain extensible. I won't go on a fangirl rage and say "skeletal animations NEEEEEED to happen" but it's one thing that's really missing in GZDoom right now. If there was a way to have both this and that, I would be a whole lot happier even if it means this feature has to wait, or even be denied.

[ZZYZX]

I already have my own MD3 parser, and it's trivial to add few more options to the result (it already knows how to scale and rotate).
I could even implement a simple MODELDEF parser over it but I see no point of doing so. I'd rather explicitly specify frames in my mod and it will never break because my MD3 loading and collision code will be separate from what engine does.
And either way I wouldnt use MODELDEF for collisions (I hope that wasn't your idea that you want this feature for) because colliding with animated models is a lot harder than static ones.

That's indeed missing. What's the use case here? Using a model frame's vertex data from inside ZScript will kill your performance for sure and it's still very questionable that it can even be done properly. Remember, the current collision code is among the most inefficient and most badly written code in the entire engine and doing full model collision would probably necessitate a full rewrite of how movement is performed. Nearly the entire algorithm depends on rectangular bounding boxes.

I was referring to this and it's already functional and not as buggy as you'd expect: https://www.youtube.com/watch?v=BMw1c7hcgUQ
It's buggy but its MY CODE that's buggy (because I don't understand the algorithms needed correctly), not that it's too slow or GZDoom can't support it. (also current state is a bit better than in the video)
And since before actually colliding it does rejection checks for various bounding boxes (blockmap, actor BB, model BB, triangle BBs) whole level can be comprised of models without significant performance impact (except monster AI which I'm not sure I want to implement here).
Also since it doesn't link to MODELDEF, it can use one model for rendering (high poly) and another for colliding (low poly).
But that's a bit unrelated to this feature request

[Major Cooke]

...I think it's stuff like that which could greatly optimize my mod I'm working on with 5244 sectors in it...

[Graf Zahl]

Ugh...

These are the moments when I wish I could turn back the clock to simpler times when Doom source ports were actually being used to make ... well ... Doom levels...

[Rachael]

Ugh...

These are the moments when I wish I could turn back the clock to simpler times when Doom source ports were actually being used to make ... well ... Doom levels...

I think it'd be an understatement to say that ship's already sailed.

[Graf Zahl]

I know... I know...

[kevansevans]

Ugh...

Can you for a moment admit that modding a game isn't about doing more of the same? If people wanted to make more Doom, that's what they do, that's what people have always done, and will continue to do if they feel inclined. However, this is not what you've done for us, and this is not what people are wanting to make. You've provided this community with a set of incredible tools that have prolonged a very beautiful and creative art form, and all anyone here sees you do is complain about no one using them right. It is not your call if a tool is being used correctly. GZDoom is more than just a source port now, it is a full blown game engine that is coherently documented and easy to use. If anything, I personally would be thrilled to see such creativity blossom if it was tools I had made. (Anecdotally, I have done my own community development on a different game, I can relate to what you do).

[Major Cooke]

To be fair, making the tools is greater, if not as much, a chore as making a mod.

This is also a hobby for Graf so money's not made here. Some things can only go so far... That's just the reality of the situation.

it is a full blown game engine that is coherently documented and easy to use.

In most regards. But there are still barrier issues -- none of the menu stuff is even documented still. I could document some things but my expertise around this area is still poor. I'd rather not enter in the wrong info, like what happened with the acceptable sound file formats when FMod was given the boot.

[kevansevans]

To be fair, making the tools is just as much, if not greater a chore, than making a mod.

This is also a hobby for Graf so money's not made here. Some things can only go so far... That's just the reality of the situation.

I will admit to this, but it's also the nature of the beast that people aren't ever going to really understand the effort it takes, even with knowledge of the source, all anyone sees is the end product. We do owe Graf a tremendous amount of thanks and praise for his efforts, but we don't owe him anything more than that. On the flip side, Graf doesn't owe us anything either, he's entirely obliged to do whatever he wants. This is something both sides need to come to terms with.

However, I must point out, if the negativity continues, one of these parties will break. Either Graf will pull a MaxED and abandon everything, or the community will give up on him. Neither of these are scenarios that should happen.

[Graf Zahl]

It's just - this stuff is so far outside my personal field of interest that sometimes I just disbelievingly look at what people actually do with the engine.