Flags, Banners, Signs -- Cloth Animations

Hey Mike,

Are you initially exporting the animation to the origin (0x, 0y, 0z) of your track? [see the readMe file]

I seem to remember that was a MUST (as the first step).

It may be that the "way you did the flags" works for them, but not the enclosed objects (like tents). That is... maybe you 'got away with' a procedure different than the one in the readMe file... and while it works for planar animations, maybe it doesn't work on enclosures.

Or... maybe enclosed animations like these don't work for some reason(?).

The last time I actually used rF2 was Build 880 (so quite a while ago).

I'll update to a current rF2 version, and try exporting a tent to see what happens.

Not sure if I can get to it today, but I'll try.
 
Thanks for the quick reply. I will try again from a new fresh scene and see if that does it from 0,0,0
I will report back to you ok. :)

Edit:
Pretty much the same results. Tried a canopy with same thing. Maybe I am missing something?
 
@ECAR_Tracks You're welcome.

@mschreiner You're right, that is weird. So it's the file (me), not you.

Woke up with 1 idea, and now after doing the export on hex_tent_1 I've got a couple other ideas.

Did one of the flags first... no problems.

Then I tried hex_tent_1 and it when all Salvador Dali on me.

Anyhow... messing with it presently..
 
Hey mschreiner...

Took down the tent and canopy zip files until we can get these exports to stop "stretching" polys.

Spent the past 2 days working on trying to get some of these 'problem' animations to export properly... with the focus on changing things in Max prior to export. No luck, though.

Still seems odd that the animations work fine in Max, and some of them seem to export without issue. So.. starting to think that it is the exporter (or it's settings) causing the problems.

Still geting the 'tearing / stretching / missing polys'. This problem is mentioned in the old gMotor2Tools.chm help file... and they say it has something to do with the "max vert lists" entry in the old exporter. Unfortunately that exporter has different controls than the current one... so their 'fix' requires some controls that are no longer on the new exporter version.

This morning, I looked over the new "rF2_Track_CheatSheet.pdf" and noticed a couple things that they emphasize under the "Animation" heading:

1. They say that when exporting (creating) the .anm file, you should only select/export the bones (not the mesh). This differs from the old way that I read when writing the readMe file. The mesh is the root node, and is entered (by name) in the animation part of the exporter.

2. They also mention to make sure the bones are "weighted" at 0.01 (been a while since I wrote the script, so not sure what I have them at... but I'll check).

If you have a chance, could you ask whoever at ISI (that works on the exporter/animation code) precisely what the (below) quotes from the new 'cheat sheet' mean:

"Group skinned mesh and bones for distribution"
"Export ungrouped distributed meshes with Fix Bone Names"

Not sure if these pertain to our export issues.

Also... if you can ask the person who wrote/updated the exporter what the 'max vert lists' entry does (as they said it could be used to stop the stretching in the previous .chm help file), and what the "verts in" and "verts out" in the export / progress bar (exporting) dialog box mean.

Not sure what kind of access at ISI that being a "Tester" allows, but if you could get clarification of the meaning of the above 2 quotes... and also ask the developer of the animations exporter code precisely what the "Fix" was for "stretching polys" after export. [This last item was mentioned in the old exporter help doc "gMotor2Tools.chm"].

I'll work the problems from this end with the (limited) info we now have, and if you could get answers from ISI (thanks in advance).. it would be greatly appreciated.
 
Bink said:
"Group skinned mesh and bones for distribution"
Click to expand...

When you clone + move animated object to its final position, you need to take care that bones and skinned mesh stays together. You can group them or use some other method (even just selecting all bones and mesh) before moving them.

Bink said:
"Export ungrouped distributed meshes with Fix Bone Names"
Click to expand...

You should export ONLY skinned mesh (not bones) with "Fix Bones Names" ticked in exporter.


Bink said:
Also... if you can ask the person who wrote/updated the exporter what the 'max vert lists' entry does (as they said it could be used to stop the stretching in the previous .chm help file), and what the "verts in" and "verts out" in the export / progress bar (exporting) dialog box mean.
Click to expand...

"Max vert lists" defines what is maximum number of lists in single exported GMT. Maximum value is 65535, which I pretty much use all the time.

"Verts in" and "Verts out" is just information. Whe exporter reads the mesh from max, it tells you how many verts it founds in this dialog. After conversion to GMT, it tells how many verts are "put in" to GMT. Amount of verts differs many times in 3ds max meshes vs. exported GMT (at least on more complex objects). It doesn't matter and have no effect on end result (modder's point of view).

Cheers!
 
2. Weight, may no longer be a requirement. Anims can sometimes be a bit unexpected if you've missed something: it either works or something somewhere went wrong. Having a root bone (this is not the root node) at world zero when you set up the animation and giving all verts a 0.01 weight at least makes sure all verts HAVE a weight. Don't think it's an absolute requirement though.
 
Luc, when I've done animations, I've given the root bone 0.1 weight on one vertex, and it worked. If it doesn't have weight on anything, it doesn't seem to work.
 
Indeed, so it's probably just a good idea to assign this weight at the beginning to make sure that all vertices, and all bones, have 'a' weight somewhere, before you start rigging? Better safe than sorry ...
 
Many thanks to mschreiner, Luc Van Camp, and Jka for these insights into animation exports.

Although many of the posted flags (that work) do not have any vertex at 0,0,0... I'll give a try on the 'problem' objects with a root bone on a vertex at 0,0,0. Previously, I (obviously incorrectly) thought that the mesh object's center needed to be at the origin.

I'll give a try exporting today using this info... and thanks again, guys, for the help.
 
Last edited by a moderator:
I put everything the way it was described above, made new animations with root bone at origin, proper selections, etc.. and the exporter (or sim engine?) is still stretching polys in Dev Mode.

Kind of frustrating, as when I used to do did this sort of troubleshooting professionally, I always had all the hardware schematics, and source code for all the software & firmware involved... so there was never a problem for very long.

Oh well... at least we tried.

Thanks again for all the suggestions.
 
Last edited by a moderator:
Thanks Luc, I'll give that a try. There isn't really a bone hierarchy though, as none of the bones are connected to each other, and each bone only affects a single vertex 100% (no interaction with other bones). In such situations with 3dsMax, the first bone placed is then considered the "root".

But I will give it a try, as you have intimated that the root bone (origin) is the basis for the positioning of the remaining bones.

A few years ago, devMode would go 'blue screen of death' if you tried to do a track with more than about 8000 waypoints (30km - 50km track).

So, I wrote my own software to create working AIW files. It was possible to do this because AIW files are .txt docs, and with time, I was able to figure out what each variable represented, and how to create them.

If you could provide me with the file format for your .anm files, I could code something to view it's output for working versus non-working animations, and have a better basis to more precisely define a procedure for creating animations that don't crash in-game.

Without that, it's tough to know if the issue is with the 3dsMax animation, the exporter plug-in, or the sim engine... and we are left with, "it either works or something somewhere went wrong".

The majority of the .anm file has either got to be lists of vertex positions for each frame, or something like (non unit) vectors that give the delta for each moved vertex, per frame [...something like delta modulation in video data compression algorithms].

It's probably not rocket science... and I'm willing to provide free research that perhaps ISI could find beneficial.
 
Any tips on creating simple rotating objects instead of bones animations? I got my ferris wheel perfectly turning in 3ds Max but no way to make it working in game.
 
Does anyone know if we are allowed to use the objects from the 3rd Party Affiliated tracks on the download page as we are with the ISI created tracks?

Sent from my SM-G928I using Tapatalk
 
You must log in or register to reply here.
Back
Top