[Dragon]

Would that be possible to add more triggers for submodel animations?
I think mostly about triggers based on speed and rotation of a ship, they would be very usefull for atmospheric mods that want to make use of flaps, airlerons and rudders, possibly also variable sweep wings. This may also come in handy for other mods, for example FoTG could used them on A-Wing's (two rings behind engines) and A-Wing's tail rudders. In WiH this may be usefull for throttles in Steve'o's ships.

[FreeSpaceFreak]

And a trigger that engages upon subspace drive activation, deactivates on arrival. Please

[Mongoose]

Woo, Voyager-style engine nacelles.

[Nuke]

iirc animations may be triggered with both script and sexp, though i wouldnt mind an upgrade to the system. i looked at the code couldnt really make heads or tails of it.

[headdie]

Woo, Voyager-style engine nacelles.

hanger doors

[pecenipicek]

Woo, Voyager-style engine nacelles.

hanger doors

rotation only, no translation unfortunately.

[headdie]

Woo, Voyager-style engine nacelles.

hanger doors

rotation only, no translation unfortunately.

no rotation if they slide

[Vasudan Admiral]

He means the engine currently does not support subobject translation. Only rotation, so to fake sliding you have to use annoying folder mechanisms and long animation scripts. :\

[Nuke]

translation can be faked using a couple techniques.

the first is to place the center of the object really far away from the actual geometry. this is used for the retractable missile pod on the chimera in nukemod.

the second is more complicated, you need to do something like this.



this was animated in max using only rotations, some tweaking may be required but it should work, the two arms could be made invisible as well so you would just see a sliding door. there was an idea posted awhile back for turrets, where the actual geometry would be stored in a different pof file and would allow for modular turrets. its a very good idea, since the way subobjects are handled in freespace is rather archaic.

[The E]

And that would work in FS how?

[chief1983]

It looks like a 4-deep heirarchy, with each object rotating around its parent.  You might actually be able to do that, if all subobjects follow the parent subobject when it rotates.

[Nuke]

It looks like a 4-deep heirarchy, with each object rotating around its parent.  You might actually be able to do that, if all subobjects follow the parent subobject when it rotates.

child subobjects inherit their parent's rotation. ive used this in the existing version of nukemod (see the hanger doors on the back end of the rumrunner). this has actually been possible for years. the only thing that might interfere with this working is the animation physics the subobject animation currently relies upon. im gonna convert the geometry in that animation to pof and see if it works.

[Aardwolf]

translation can be faked using a couple techniques.

the first is to place the center of the object really far away from the actual geometry. this is used for the retractable missile pod on the chimera in nukemod.

the second is more complicated, you need to do something like this.



this was animated in max using only rotations, some tweaking may be required but it should work, the two arms could be made invisible as well so you would just see a sliding door. there was an idea posted awhile back for turrets, where the actual geometry would be stored in a different pof file and would allow for modular turrets. its a very good idea, since the way subobjects are handled in freespace is rather archaic.

YES!!!

I've been trying to tell people this since I first heard about this limitation! Good work, Nuke.

[Tomo]

Putting the centre of rotation being miles away is a much cleaner solution, although it could make the bounding box calculation incorrect.

Relying on a sequence of piled-on rotated subobjects is computationally expensive, and more likely to have 'unexpected' effects if any part rotates more or less than intended.

[Nuke]

wow, it works. download, install as mod, run the mission.

there are sometimes bounding box issues with putting the geometric center in a strange place and whatever way you use this will be a problem. the test model there has borked collision detection (maybe its because i used styxx's export plugin, since dae wasnt working and i really didnt want to spend all day on this) and the door submodel has a funky bounding box (these problems are always encountered when you try to exceed 3 levels of hierarchy with the max plugin). but the point was to show the proper animation and joint setup. the problems are purely with export. had i made the model in truespace it would have been perfect. hard to beleive after all theese years, we still cant use max to export sane models (and i bet anyone who claims they can have poorly smoothed models).

theese are reasons im all for the rendering engine overhaul. maybe they will upgrade geometry with 4x4 transform matrices, or do away with submodels all together and store them in seprate models. just a couple ways to really improve this feature. there were supposed to be more than one type of animation, such as linked animations, which are linked to some value in the game, such as desired roll rate or throttle position. for me i perfer dto do tha animations in scripting, as more stuff is powwible, catch is im not sure if this breaks collision detection are not. the advanced cockpit script im working on has an animation system for this kinda thing (only thing is i really only tested the animation system on is things in the cockpit, not on colideable geometry).

[attachment deleted by admin]

[pecenipicek]

can you just export the model itself in collada. dae importer should work with deeper levels of hierarchy i think.

[Nuke]

it should, but it wasnt working. pcs2 kept giving me errors when i tried to import the dae file, since it was a demo and not a production model, i didnt see there being much point in debugging it. its a modeling issue, ive used heirarchy at least 7 levels deep (on models converted from cob) in the past without borking collisions, which is exactly the kinda thing which breaks the old max plugin.

[Dragon]

Just recall how you did the Phoenix, it has a gargantuan hierarchy tree on it's switch wings.

[Vasudan Admiral]

There is a major limitation currently in the engine to do with hierarchy depth. It's actually limited to 5 levels. I ran head-long into this limit when I was making the HTL Aten, because I wanted to build in turret arm recoil via:

Hull->TurretBase->TurretArm->Folder1->Folder2->Barrel

What happened though was that if a ship with more than 5 levels of depth was in the mission at all, you get all kinds of weird things happening to the rendering of weapon shots (which turn flat and fake), particle effects (in which impact effects for example will only be visible if you look at them from a particular angle), and a few other weird things that I can't remember too well.

The limit is in 3dsetup.cpp: #define MAX_INSTANCE_DEPTH   5
The problem is I have no idea if simply bumping it is a good idea. I tried it and it DID solve the rendering problem, but for all I know it could have cut my ingame framerate in half and I wouldn't have noticed.

With the Aten in the end I chopped out the 2 folders in the guns, meaning the version in the MVPs sadly isn't *quite* ready for turret recoil unless translation comes along.

OH and one other thing - yes that method of translating does work well for hanger doors and other sliding objects, but be careful if for whatever reason the animation gets interrupted by the next animation, because that next animation will start from wherever the first one was up to. In practice this will mean that if your hanger door is opening and reaches halfway when the close door animation is triggered, it will start to close right there and because the close animation assumes it's fully open, in all likelyhood your hanger door will close and then reopen to halfway before the engine considers the animation done. I saw this with turret recoil tests where the next shot animation inturrupted the previous one's return, and the stupid barrel ended up more or less moving forward OR back randomly with each shot. :\

[Nuke]

Just recall how you did the Phoenix, it has a gargantuan hierarchy tree on it's switch wings.

the phoenix was modeled in truespace!

There is a major limitation currently in the engine to do with hierarchy depth. It's actually limited to 5 levels. I ran head-long into this limit when I was making the HTL Aten, because I wanted to build in turret arm recoil via:

Hull->TurretBase->TurretArm->Folder1->Folder2->Barrel

What happened though was that if a ship with more than 5 levels of depth was in the mission at all, you get all kinds of weird things happening to the rendering of weapon shots (which turn flat and fake), particle effects (in which impact effects for example will only be visible if you look at them from a particular angle), and a few other weird things that I can't remember too well.

The limit is in 3dsetup.cpp: #define MAX_INSTANCE_DEPTH   5
The problem is I have no idea if simply bumping it is a good idea. I tried it and it DID solve the rendering problem, but for all I know it could have cut my ingame framerate in half and I wouldn't have noticed.

With the Aten in the end I chopped out the 2 folders in the guns, meaning the version in the MVPs sadly isn't *quite* ready for turret recoil unless translation comes along.

OH and one other thing - yes that method of translating does work well for hanger doors and other sliding objects, but be careful if for whatever reason the animation gets interrupted by the next animation, because that next animation will start from wherever the first one was up to. In practice this will mean that if your hanger door is opening and reaches halfway when the close door animation is triggered, it will start to close right there and because the close animation assumes it's fully open, in all likelyhood your hanger door will close and then reopen to halfway before the engine considers the animation done. I saw this with turret recoil tests where the next shot animation inturrupted the previous one's return, and the stupid barrel ended up more or less moving forward OR back randomly with each shot. :\

i thought bob upped the MAX_INSTANCE_DEPTH ages ago. around the time he implemented the animation system. i remember using the phoenix as a torture test (i have a video somewhere of the wings working) of the system. thats not to say that somone dropped it back to 5. for doors this doesnt seem to be an issue though. i do plan to use my swing wing phoenix at some point in conjunction with my atmospherics engine.

as for animation timing, thats always a source of frustration. i kinda wish the lab would allow you to try different animation settings and then simulate them in real time, so you dont go through repreditive tweak -> run -> tweak -> run cycles. perhaps adding a +no interrupt: flag that will prevent any animation from starting if an animation is already in progress.

i think all subobjects should be able to be replaced with separate models. way to do this is to create another object derivative. it would have its own position and orientation in relation to the object its connected to, and of course these things can be moved and animated way better than subobjects could. there was a thread a while back about modular turrets that discussed this kinda thing.