Specifying 3D models per frame

[ravenshining]

Looking through the MML documentation, I only see how to specify 3D models on a per-sequence basis, and even that I don't understand fully. Specifying 3D models on a sequence-level works fine for items, and M1 scenery, because they're just static images that don't change. But, what about:

• M2 scenery items, which display a random, often completely differrent frame. For example, the Alien corpses sewage scenery item would require at least two models, a head and a torso, but preferably 4 models for the x-flips.

• Mapping multiple 3D models to frames of an animation, if your models don't have animation.

• Mapping different 3D models to different view angles, for applying perspective and bump effects to 2D sprites, or, this being Marathon, perhaps 5-dimensional objects.

Surely for those cases you'd have to map models to frames, or frames to animation frames in a 3D model? But, I don't see how to do this.

[Ku-rin]

It seems like the animated models have their own sequences mapped directly to shapes sequences. I've never worked with dim3, so I know nothing more about this other than what's on the label. This avoids a separate model for each frame by using skeletons and transforms scripted in whatever way they've got that set up. I'd love to play with that, learn it, etc. but a cursory search has failed to deliver any downloads. Like the website for the thing is basically just a messageboard (most recent posts in 2018) and the link to the latest version hits a 404. Dim3 is basically dead by all appearances.

Found this: https://jemmet.home.xs4all.nl/spnkrghol ... mated.html

Sadly, this is quite old. I'll look into it more closely, but I'm not entirely hopeful. I now recall messing with some of this stuff back when it was just old, and I don't think I got far.

Mapping models to frames would be great, as you point out, with random-frame scenery. I did some stuff with decal puddles that looked awesome a long time ago, but because I can only get one skin per sequence there, I either sacrifice more scenery objects or just always have the same puddle.

This is just an MPDX thing, but having the ability to have one scenery object with multiple frames assigned for different static models would be a big deal. Ultimately you'd need some kind of hook-in with Lua or something to swap the item's appearance and it gets very hacky, but I get thoughts about items with collision cylinders and my brain explodes. In a more general sense of use, you could get more scenery out of the limited sequences and hard-coded definitions than is otherwise available.

[Ku-rin]

Found sources for dim3. Nobody's touched these since 2014 at the latest, though.

https://code.google.com/archive/p/dim3/ ... ult/source

https://github.com/prophile/dim3

EDIT:

Well, dim3 is basically dead, has been for a while it seems. Without that, there are no animated 3d models in A1.

There is no way to assign static models to frames, and no practical method of animating scenery models aside from rotation and transform of the entire scenery object with Lua. This, I know for a fact does work (at least for things like doors.)

In terms of "animating" the skin (or even the mesh geometry) of a 3d model in A1, you're looking at swapping scenery objects in place of frames (an idea that quickly becomes restrictive due to limited slots, at least) or using a monster and swapping its sequences in place of frames by way of manipulation in Lua.

3d monsters work more or less fine. Mind you, I've already made a few. However, even in their intended purpose, those have their own drawbacks, namely the fact that monsters do not interpolate their facing as they turn, which looks downright weird. I've had minor success in overcoming this with Lua, but it's hardly trivial, and has glaring side effects (suddenly "popping" up walls) that I have yet to sort out. Thus, the monsters that I do have so far are all more or less radially symmetrical!



Since stationary monsters don't necessarily have the same problem with randomly deciding whether or not to suddenly climb up a neighboring polygon several WU in a single tick while under Lua duress, the monster-as-scenery kludge could be practical, but it's a stretch. And, you're not going to get too many "frames" to work with there either. Frame-wise animation of mesh geometry is pretty much hopeless. If you just wanted to change the skin though, maybe for some "blinkenlights", it would be vaguely applicable.

As far as I can tell, that's about it though.

[ravenshining]

Thanks for looking into this, Kurin! With my limited knowledge of 3D- I only make the occasional Sketchup model - I really wasn't sure what the deal was. From what you're saying, it sounds like animation is very difficult and per-frame substitution is impossible, preventing the development of plugins for even stock sprite 3d replacements.

It seems clear we need to make a feature request to our poor devs, and soon since it'll probably be years before there's an A1 1.4 and Hopper has already claimed he wants to depreciate opengl for that hypothetical version.

Specifying models on a per-frame basis would solve all four problematic use cases, while perhaps being resource-intensive for point #2. I don't know what a good animated model format would be to suggest supporting if dim3 is truly dead.

[Ku-rin]

Thanks for looking into this, Kurin! With my limited knowledge of 3D- I only make the occasional Sketchup model - I really wasn't sure what the deal was. From what you're saying, it sounds like animation is very difficult and per-frame substitution is impossible, preventing the development of plugins for even stock sprite 3d replacements.

It seems clear we need to make a feature request to our poor devs, and soon since it'll probably be years before there's an A1 1.4 and Hopper has already claimed he wants to depreciate opengl for that hypothetical version.

Specifying models on a per-frame basis would solve all four problematic use cases, while perhaps being resource-intensive for point #2. I don't know what a good animated model format would be to suggest supporting if dim3 is truly dead.

No problem. I've been messing about these lines with MPDX all along, so I've got skin in this as well.

I now recall earlier you mentioning an interest in persuing 3d sprites, and I should also point out that I'm not certain that dim3 would work so well for that in the first place. I suspect the animation just works on the mesh geometry itself, moving vertices around to follow a skeleton that you define keyframes for in the animator application.

Your idea would rely more on a fixed mesh with an animated skin, something I also desperately want for scenery objects and other applications. Some kind of a per-frame static model allocation is therefore something I would definitely get behind.

(Not to mention maybe some kind of a Lua hook to manipulate animations in scenery objects. Or a way to add extra types of scenery objects via MML?)

As far as replacing dim3, that's something out of my depth, but definitely something somebody should look into. Rather than just ditching animated models, it would be super-nice to actually make them work.

Haha, I just had a disgusting/funny thought. Right now there is at least one way... make a zoetrope of sorts. Just copy each "frame" of your object into one big object, aligning them in a ring. Obscure all but one "frame" with some other geometry somehow, and rotate the object with Lua at the proper moments. You can get 3d animated scenery with that. Hahaha. Horribly impractical, but maybe possible, assuming it would even render properly. I don't think I can beat that without frame-wise model allocation.

[ravenshining]

I now recall earlier you mentioning an interest in persuing 3d sprites, and I should also point out that I'm not certain that dim3 would work so well for that in the first place. I suspect the animation just works on the mesh geometry itself, moving vertices around to follow a skeleton that you define keyframes for in the animator application.

Your idea would rely more on a fixed mesh with an animated skin, something I also desperately want for scenery objects and other applications. Some kind of a per-frame static model allocation is therefore something I would definitely get behind.

Yes, my idea is basically to have a simple, vertical rectangle, whose skin is the sprite, in various orientations so each view nominally but not necessarily directly faces the beholder. Then, as you move about the object, you'll see the "sprite" deform before switching views, and especially when looking up or down at it. With that in place, bump maps could be applied to the sprite for added depth without having to create a whole 3D model of the object; whereas a bump map wouldn't benefit a 2D sprite as 2D sprites always face the beholder.

How well that would work, I don't know, but I'd love to experiment, and release plugins if it works, as it could be quickly developed without expertise in 3D modelling :-)

(Not to mention maybe some kind of a Lua hook to manipulate animations in scenery objects. Or a way to add extra types of scenery objects via MML?)

I'm sure the former could have all sorts of fun applications. For the latter, both editors and the lua hook would have to be extended to use the new scenery objects.

As far as replacing dim3, that's something out of my depth, but definitely something somebody should look into. Rather than just ditching animated models, it would be super-nice to actually make them work.

The way I envision it, animated models need not be ditched. I imagine A1 could replace a whole sequence with a potentially animated model if you use the optional "seq" attribute or "<seq map>" element, preserving compatibility with any existing model replacements; or replace just one frame with a model if you use an optional "frame" attribute instead of "seq" or "<seq map>."

[Ku-rin]

Yes, my idea is basically to have a simple, vertical rectangle, whose skin is the sprite, in various orientations so each view nominally but not necessarily directly faces the beholder. Then, as you move about the object, you'll see the "sprite" deform before switching views, and especially when looking up or down at it. With that in place, bump maps could be applied to the sprite for added depth without having to create a whole 3D model of the object; whereas a bump map wouldn't benefit a 2D sprite as 2D sprites always face the beholder.

Yeah, sounds about right. I don't know if effect facing is normal to the impact surface by way of the engine as is, but I do know you can make it so with Lua. What's more, in the example of say, a bullet ricochet, you could even take advantage of the 3d geometry to have little tiny sparks fly off at angles just by adding more planes. Lots of glow will also help sell it, especially at very acute angles. I recommend getting into Blender, it's not too awful, learning curve wise, and you can do all of this stuff in there quite well. It even has physics, for flames and smoke, which is how I did this: http://simplici7y.com/items/very-pretty-flames

The way I envision it, animated models need not be ditched. I imagine A1 could replace a whole sequence with a potentially animated model if you use the optional "seq" attribute or "<seq map>" element, preserving compatibility with any existing model replacements; or replace just one frame with a model if you use an optional "frame" attribute instead of "seq" or "<seq map>."

Something like that makes sense, or at least, I'm sure that I have no idea how the current code does what it does, but I feel like there ought to be a way. Hopefully there is a way.

[ravenshining]

Yeah, sounds about right. I don't know if effect facing is normal to the impact surface by way of the engine as is, but I do know you can make it so with Lua. What's more, in the example of say, a bullet ricochet, you could even take advantage of the 3d geometry to have little tiny sparks fly off at angles just by adding more planes. Lots of glow will also help sell it, especially at very acute angles. I recommend getting into Blender, it's not too awful, learning curve wise, and you can do all of this stuff in there quite well. It even has physics, for flames and smoke, which is how I did this: http://simplici7y.com/items/very-pretty-flames

I know you can set effect facing, but have you actually tried this? I've said it before, but it seems to me that would change what view is displayed, not the plane onto which is is rendered.

Actually, it wasn't effects that I was thinking of for my rectanglular-sprite model - it's monsters! Although, now that I examine some screenshots more carefully, it looks like there already is some distortion applied, but I suspect this is an effect of them not being centred in my view.

[Ku-rin]

Yeah, you can do it with sprites, but it only does anything if you have multiple views per sequence. If you have 3D objects, like even just a plane, you're projecting onto that plane, and from there onto the viewport.

The only benefit of putting a monster sprite onto a 3D object plane (rectangle) is that you get 360 x whatever views instead of just 8. And, again, even with a fully 3D monster object, the AI doesn't smoothly turn, so you end up with a monster that just jerks around when it turns.

EDIT:

If you want to play with some pre-rolled 3D stuff, I've uploaded some 3D monsters and the MML for them to my MPDX Github. (https://github.com/vacuum-forest/MPDX) You'll probsibly also want the shapes and physics to get it to work as well, so I tossed them in as well though they're very developmental.

EDIT2:

You'll need to modify the MML, naturally, for filepaths. I suggest shoving this stuff into a plugin, and making a simple map if you want to play with it. The turrets are all BoBs and the vacuums are ticks, for reference. If you want the original Blender files let me know, I can also offer those, although I cannot say that how I do things would make a good tutorial!

[ravenshining]

The only benefit of putting a monster sprite onto a 3D object plane (rectangle) is that you get 360 x whatever views instead of just 8. And, again, even with a fully 3D monster object, the AI doesn't smoothly turn, so you end up with a monster that just jerks around when it turns.

That's all I'm going for :-) Yeah, the AI will turn jerkily, but you'll see a better indication of what direction they're facing, and you might see a slightly smoother rotation as you move around them.

If you want to play with some pre-rolled 3D stuff, I've uploaded some 3D monsters and the MML for them to my MPDX Github. (https://github.com/vacuum-forest/MPDX) You'll probsibly also want the shapes and physics to get it to work as well, so I tossed them in as well though they're very developmental.

EDIT2:

You'll need to modify the MML, naturally, for filepaths. I suggest shoving this stuff into a plugin, and making a simple map if you want to play with it. The turrets are all BoBs and the vacuums are ticks, for reference. If you want the original Blender files let me know, I can also offer those, although I cannot say that how I do things would make a good tutorial!

Thanks!

[Ku-rin]

That's all I'm going for :-) Yeah, the AI will turn jerkily, but you'll see a better indication of what direction they're facing, and you might see a slightly smoother rotation as you move around them.

Haha, you'll see. You've done some stuff with monsters/AI if I recall, but you'll see how weird it gets with 3D monsters. Wait to thank me until you've really gotten into this mess.