Attachment model question

[verybad]

I could just animate an attachement model using minimal geometry, import that into SS, make it non rendering/invisible and use it as a skeleton in SS correct?

This would, I assume, reduce the ammount of memory involved in a multipart model, as the higher res real object would change only in world space, not local space. (if there is such a concept in SS) It seems then I would only need one copy of the main model as opposed to the numerous copies used for standard animation.

If I animate an attachment triangle (eg scaling it) will this carry over into an animation of the subobject? This would be useful for a number of effects, eg breathing, etc.

[LanThief]

Wow... your going to have question to my answers ... I can feel it! *But fire away as you see fit......

"I could just animate an attachment model"
Yes, this is how SS animates their weapons. *Likewise, Seriously Warped Deathmatch weapons followed this same rule. *

======================
One thing to note, each attachment can set a default animation to one of the animations that exist in the attachment model.

Another thing that you can keep in mind, every model that is animated, has an indexed list assigned to each animation. *That index (starting with 0..1..2.) can be called on in code to activate each as they are needed, regardless of how they were assigned when used as an attachment by another model. *In code, a programmer makes a call to the model file and then can pick which index number to play. *.... may not be clear, but you can e-mail me if you get to that point.
=================

"It seems then I would only need one copy of the main model.." *This is true, only if you do not intend to change the geometry for the main model and to just move its translation. * You can do a combination of both:
For example: *You could have an attachment that animates pulling a gun up from the hip of Sam to be ready to fire. *At the same time you could call an animation for the gun to load a clip (another attachment) and then .. and then...
[ if you never change the geometry, then each would be attachments that move via their animated attachments. *Otherwise, some of the animation could be geometry changes as well as attachment changes.

"Reduce the amount of memory" -- I'll let someone else answer that, BUT... *You could think of it this way:
Each attachment can hold its own MIP levels and therefore some attachments could MIP out while other just are Decimated, reducing poly count as you travel further from the attached models.... but different results will be produced with each as they acting on their own MIP definition. *

"... attachment triangle (eg scaling it) will this carry over" * Well... never tried it, but I would guess not! *The triangles are there for connivance of translation point. *The triangle itself is not even needed. *You are really acting on three points - anywhere - in the model. *As you can see it would be better to place a triangle where you can easily find it, rather then searching all over you model to find the best place to click! *wooow that would be a trip. * (You can do it either way i guess, if you like)

"eg breathing" well I think you will be stuck with changing geometry on that one. *Unless you have many many pieces to attach........na *

Over all it sounds like you have your head in the right place and well on your way to understanding Modeling with Serious * * * * *Good Luck :-)

[Admir Elezovic]

Looks like LanTief beat me on this one :)
On attachments.. you can build fake skeleton with triangles only, animate them and attach various parts to it (like head, torso, arms...) this would decrease memory usage dramatically but could give some problems. First i could think of is making organic models (humanoids...), if you use attachment, model would be segmented (no geometry flexing on joints like elbows, shoulders...), another one is you mentioned is breathing. We used attachments on weapons for player and weapons for monsters since they dont have any animation (except ones in code). Note that you cant change attachments animations in game, if they arent programmed, without intervention in code.
Scaling triangles wont scale attachment, its only guide with position and rotation only.

Admir

[verybad]

Thank you both for the info. The Skeleton thing I mentioned is intended for animating articulated models like the mech I posted. Now I can animated a skeleton in maya and export it as a series of objs rather than dealing with potentially much larger files. The first thing I would like some enterprising mathematician/programmer to do is to add ffds to the engine so we can have true skeletal rather than vertex based deformation. Since the "skeleton" code is already in, it doesn't seem like too much of a stretch (no pun intended) to get deformation lattices in. There was an article re that in a recent issue of Game Developers Magazine. I'd try, but my programming skills are anemic at best.

I can build a custom fake skeleton simply enough by snapping points to the rotattors on my base groups. Tried some imports today but had issues with textures, so I registered my copy of 3d Explorer (which had expired). Once they get arround to emailing me my password I can try converting files to *.LWOs and importing those instead of *.OBJs

[Admir Elezovic]

We had discussion about Skeletal animation system some time ago on old SeriousEngine forum. On first glance it doesnt look hard to implement, we are working on it, but with todays hardware some serious performance issues arise. No matter how fast cpus are or how cool graphic card is, it does have big impact on performance (but reduces memory used) . I think we found solution to this problem, skeletal animation system should be included in one of patches (dont ask me to say when, couse i dont know). If you still have problems with importing send object over, we can take a look and find potential problems.

Admir

[rico]

COOOOOOL! a skeletal deformation patch would rock with Maya set up the way it is. It is so quick and easy to set up and rig an IK skeleton in Maya that it would save loads of time in the post-export proces!!! :biggrin:

[Admir Elezovic]

Its not just maya, since we are licencing our Engine and Tools, we must support Lightwave, Max, SI among others. It will be pain in a*s to get right exporters for all those apps but we expect help from community :)

Admir

[rico]

yeah I know its not just Maya, but I can always hope that one of these forum guys can actually script in MEL, and will do an export script. THAT would rock!! :o :o :biggrin: