Spawning a new model in another models Frame?

[Mexicouger]

I was wondering if It is possible to take a Player model, And In a set of it's animations, Make it transform; Just in the frames. I need it because Our player model needs to turn into a Ball. It would seem more Logical to do it this way than Change the codes Modelindex(way to many Problems). SO is it possible To spawn a Ball in frames? I bet I would have to have the ball like Invisible and Hanging out or something(wasting polys).

[frag.machine]

The simplest way would be to add the ball mesh to the model, and set all vertexs coords of this mesh to (0,0,0) for every frame (in other words, reducing the ball to the size of a point hidden inside the main mesh), except for the ball animation frames, where all the other meshes have their vertexs coords forced to (0,0,0). All of this can be done in QME in 15 minutes (including 5 minutes to take a leak ). The main problems in this approach are the waste of memory space and the weird morphing when switching animations if your engine supports lerping.

[leileilol]

I bet I would have to have the ball like Invisible and Hanging out or something(wasting polys).

Now now, no need to see those in the CrouchTeabag() function.

[Mexicouger]

Hhahaha!! That made my day right there

Anyway, I have no slue about modeling, SO I will Leave that Up to our modeler. Redirect Him to this Topic. And this is the best way I can see to Add the morphball (It's Metroid)

[Wazat]

5 whole minutes to take a leak? That's either really slow for taking a wiz (how much beer did you drink?!), or really fast for passing a kidney stone.

Storing the orb inside the player is a good, easy way to do it. It has some costs, but avoids model swapping. As frag.machine says, those verts (and any texturing necessary) will be present in every animation the player has even when they're being made invisible. Likewise when the player is in orb mode, his player form will be present but invisible. So if your orb and/or player is complex/detailed (high poly/high resolution), your total player model will be costly when there are multiple players in a room. Even though you're against changing the player's model, you might consider it if the orb needs to be separate for memory etc reasons.

One argument in favor of the orb in the player model is then you can very smoothly animate the player turning into the orb (i.e. player curls up while orb expands to envelop him), and animate changing back again.

[Downsider]

You could do an animation where the character curls his legs up and whatnot and then spawn another entity that's a ball on top of it to be visible instead. No animation problems there.

Remember, he's on a PSP. The ball model will still be drawn all the time if you use your method, no matter where they're hidden in the model.

[Mexicouger]

Yea. Our Player model is 582 polys, And The ball is like 100 polys. So I think We can Tolerate it. And the reason I am forced to have the ball in the player model is because When you are the ball, the player model changes. And in Ad-hoc, It gets reeeally Messed up. And what I mean by messed up, Is like you become like someone else chasecam, but you control your own Body. Something of that Nature. It's really Annoying. And This seemed Reasonable. Plus The animation from player to ball would be nice.

So Let me get this straight: if I am just the player, Then The ball would be super small, And Inside the player model. But if you change to the ball, Then The ball gets larger and Larger? And what does the player Model do? Gets smaller and smaller and Goes into the Ball? I think That sounds reasonable(And pretty Cool). And that would fix some of the Glitches. And Besides, Kuroks player Model was like 1000 something polys. I Have some neat maps, And Framerate is clocked at 55-65 fps. And it's around 30 when I have 3 bots.Our player Is half that size, So The framerate will be good either way. Thanks for the tips.

[Wazat]

Yes, that's about how I imagined the transition animation. And it should be exceptionally easy to do that sort of animation because it mostly only involves scaling.

Have fun, man!

[Downsider]

Bots make the game CPU-bound, obviously.

You might want to write your own bots for this game; Frikbot doesn't cut it on the PSP. The PSP's hardware can't keep up with it.

[Mexicouger]

I can't Even Imagine Writing an AI code. I haven't studied Much AI code. Maybe I should learn about that. And that Will also Involve Learning Tracelines as well.

And Is there like a whole bunch of Code that is using up the psp memory or what? What's the cause of the Slow-down with Bots except Poly count?

[Arkage]

Theres not much learning with trace lines, its just a function call.

[Mexicouger]

Yea, I realize that Now. But I gotta get Familiar with the Function. I like to Get to know what Each Function does, Like each line of code and How it affects my goal. So I got to Experiment with Tracelines.

[Downsider]

I can't Even Imagine Writing an AI code. I haven't studied Much AI code. Maybe I should learn about that. And that Will also Involve Learning Tracelines as well.

And Is there like a whole bunch of Code that is using up the psp memory or what? What's the cause of the Slow-down with Bots except Poly count?

The player emulation that a Frikbot does is completely unnecessary for a Metroid game, and can be simplified a lot for a PSP title. When bots are making complex, calculated decisions, it's taxing on the CPU. When something's taxing on the CPU, your framerate drops.

[leileilol]

Frikbot doesn't cut it on the PSP.

Frikbot is one of the most cpu efficient bots i've ever played with. You can game with these on slow Pentiums. I don't think you can find a lighter bot than this that fakes client functions very well without being a monster.

The PSP just sucks at floating point

[Mexicouger]

Cool
I am gonna see what I can do for the Frikbots tonight. Delete some code, Simplify others. Thanks for the advice.