Connection ErrorBad RequestThis page went staleSession ExpiredSign in requiredForbiddenNot FoundToo Many RequestsServer ErrorBad GatewayService UnavailableGateway TimeoutHTTP Version Not Supported
Session Expired
Your session has expired. Please log in to continue.
Sign in required
You need an account to do that. Sign in or create one — it only takes a minute.
This page went stale
Your security token was rejected, usually because the page sat open too long or you signed in elsewhere. Nothing was saved. Reload the page and try again.
Request Failed
We encountered an issue while processing your request.
Please check your internet connection and try again.
Error Details:
Share Link
Posts from Exporting models and animations from the game for use in Unreal Engine.
To stop the movement animation, simply delete the animation keys along the "Y" axis for the root bone that connects to the model's coccyx – Attachment 75777
Yes, it’s indeed a great method, and no intermediate conversions are needed; thank you!
However, I noticed that in some models, several bones move forward along the Y-axis (I suspect this happens when the model consists of multiple meshes). In general, you can quickly identify these bones by exporting the animation to SMD and then running a script that tracks which bone numbers move forward along the Y-axis during the move animation. After that, you can remove the animation keys for these bones in 3ds Max.
Although, I just tried using this method to fix the move animation for the swordsman, and in his case, this method didn't work. Four bones are moving: 1 - Sword_joint, 2 - Shield_joint, 3 - SpeedLineSword, and 9 - Hip. They ultimately move the same distance, but their frame-by-frame shifts don't match. If you try to simply eliminate the forward movement for these bones, the sword and shield will not move along the Y-axis, and as a result, in some frames, the sword and shield start falling out of the swordsman's hands.
Yes, it’s a really great method, and no intermediate conversions are needed, thank you!
However, I noticed that in some models, several bones move forward along the Y-axis (I suspect this happens when the model consists of several meshes). In general, you can quickly identify these bones by exporting the animation to SMD and then running a script that tracks which bone numbers move forward along the Y-axis during the move animation. After that, you can remove the animation keys for these bones in 3ds Max.
Although, I recently tried to fix the move animation for a swordsman this way, and in his case, this method didn’t work. Four bones move: 1 - Sword_joint, 2 - Shield_joint, 3 - SpeedLineSword, and 9 - Hip. They ultimately move the same distance, but their frame-by-frame shifts don’t match. If you try to simply remove the forward movement for these bones, the sword and shield won’t move along the Y-axis, and because of this, in some frames, the sword and shield start to fall out of the swordsman’s hands.
Lol, yes, this happens in Heroes. For example, with the Knight, the rider, horse, spear, and shield will move as independent objects.
If you have the ability to create a separate death model, I would do it this way: Use a regular model for the death animation. For combat, make the sword and shield attached to the hands.
Added 7 minutes later Perhaps initially, the weapon and armor were two different models; they were combined into a “global” group, and when loaded, they merged into what we have.
There is no direct evidence yet, but there may be soon.
But there is indirect evidence – in the Knight, many bones have complex names like Global|Hip|Chest. This is an import bug that occurs when the skeleton has bones with non-unique names. For example, the horse has a Hip bone, and the rider also has a Hip bone – the names of the previous bones are added to them until the name becomes unique
Lol, yeah, that happens in Heroes, like with the Knight's rider, the horse, spear, and shield will all move as independent objects
If you have the option to make a separate death model, I'd do it this way For death I'd use the regular model For battle I'd have the sword and shield attached to the hands
Yeah, we've thought about that too sometimes, because on some animations there are defects where the weapon slightly slips out of the unit's hands. Initially we didn't understand why the devs made the weapon separate from the rest of the skeleton — it seemed more logical for the weapon bone to be linked to the hand bone — but then we realized it's most likely about the death animations, where in most cases the model drops its weapon.
Overall, move animations for units like Footmen can still be fixed with a script that smoothly removes the Y offset from moving bones. Our script finds bones that move forward on Y, then calculates how far each bone moves over the entire animation, then divides that distance by the number of frames in the animation, and for the moving bones it proportionally subtracts the Y position for each frame. Roughly speaking, if an animation lasts 15 frames and the bone's offset was, say, 15 meters, then 1 meter is subtracted from the Y position on the first frame, 2 meters for the second frame, 3 for the third, and so on. If you fix it this way, the shield and sword don't slip out of the Footman's hands, but there are still frames where you can see the shield sliding slightly on the arm. But that might already be an issue with how the GR2 plugin for 3ds Max 2008 reads GR2 animations. GrannyExporter does it better, but unfortunately on the last frames of a Move animation it tries to return the model to its original position, and we can't run our script on such an animation. Also, some models, like the Blood Fury, have a very inconsistent speed during the move animation — that is, the Blood Fury runs in bursts. And if you run such a script that tries to smooth all animation frames proportionally, the resulting move animation will play "in place," but you'll see the Blood Fury being tossed slightly forward and then slightly back. In other words, the Blood Fury's run-in-place animation will look jerky. But after I imported this animation into Unreal Engine and started playing it not just in place, but by giving the Blood Fury character forward movement at the right speed (for that you need to check the value inside the <MovementSpeed> tag in the xdb file with the move animation), the jerking becomes invisible, and the Blood Fury starts running in bursts similar to the original.
Has anyone encountered a problem when working with Archangel, where loading a mesh results in the following error: Calculating normals didn't go too well for submesh
I encountered this when loading a model from the Inferno town screen. I can't close the error; it keeps appearing endlessly. Instead of Archangel, I tried converting this model using mesh2wrl, but the resulting WRL file seems to have UV problems because, when applying the material, the mesh simply turns black. I haven't used mesh2wrl before; perhaps there are additional steps needed for correct UV mapping?
Has anyone encountered a problem when working with Archangel, where loading the mesh results in the following error: Calculating normals didn't go too well for submesh
I encountered this when loading a model from the Inferno city screen; I can't close the error; it keeps appearing endlessly. Instead of Archangel, I tried converting this model using mesh2wrl, but the resulting WRL file seems to have UV problems because when applying a material, the mesh simply turns black. I haven't used mesh2wrl before; perhaps there are additional steps needed for correct UV mapping?
That's exactly what's happening. If you add the Unwrap UVW modifier, you can see that the texture coordinates are likely arranged according to world coordinates, and the model doesn't have a properly configured texture map, hence the problems. To solve them, you need to assign a material to the model and configure the texture map to match the original texture.
some file from this building is corrupted... I opened it in Arkhangelsk as well - the same error, okay, I ran it through another program, got a .vrl file, opened it in Blender - it's messed up... opened another file from the same folder, "geom", also .vrl, Blender - the model is normal... but from the first file - the model is VERY small, it doesn't scale, and in the viewport, it's not visible completely, but only in some incomprehensible parts... I don't know...
Added 9 minutes later ah, no, I redid the .vrl file again, and it opened normally... and what texture should it have?
I thought the same thing at first, I fixed them, but nothing changed. And when I tried to apply a texture for UV testing, the model simply turned red. It seems that the UV coordinates are 0.0 for every vertex.
vova2112
That's exactly what's happening. If you add the Unwrap UVW modifier, you can see that the texture coordinates are likely based on world coordinates, and the model doesn't have a properly configured texture grid, which is causing the problems. To solve this, you need to assign a material to the model and configure the texture grid to match the original texture.
Thank you, I'll try to adjust the UVs in Blender or 3ds Max.
Pavlinho
I managed to fix the UVs in Blender. I started by simply converting the WRL file to OBJ, and when importing into Blender, the UVs already looked better; it was clear that the texture was being applied, although not entirely correctly. In the end, I only needed to mirror the UVs along the Y-axis, and the texture was applied as it should be.
I managed to fix the UVs in Blender. I started by simply converting the WRL file to OBJ, and when importing into Blender, the UVs already looked better. It was clear that the texture was being applied, although not entirely correctly. In the end, I only needed to mirror the UVs along the Y-axis, and the texture was applied as it should be.
Thanks to everyone!
There's a plugin in Blender that can directly import WRL files... well, it's too late now, the problem is solved. But yesterday, when I was looking at the WRL file for the second time, the UV mapping seemed normal. That's why I asked for the texture (so I wouldn't have to search through folders) to see how it would look. Oh well.
There's a plugin in Blender that can directly import WRL files... well, it's too late, the task is solved = good, but yesterday when I was looking at the WRL file for the second time, the UV mapping seemed normal, that's why I asked for the texture (so I wouldn't have to search through folders), to see how it would look ))) oh well )))
Yes, maybe I should have tried the Blender plugin right away. Importing WRL into 3ds Max probably didn't read the UVs correctly.
vova2112
