Sorry your browser is not supported!

Recently I have had problems exporting from blender to .x and as I was using the built in exporter communicated with the author of the exporter on a thread here on the forums.

When I have animated an object in blender it is exported and the directx viewer (ie double click the exported file) shows the object to be correctly animating. When I load it into my darkBasicPro level the object has two errors. The first is that the door, in this case, as it opens is scaling the animated vertices to a different scale size as is in the exported object. So my door doubles in size as it opens...The second is that the objects collision object is not functional, or is moved into a different location to the graphics shown, despite the object being resetup every sync frame as should be....

So between the author of the .x export script and I we think that it may be a darkBasicPro error as the standard directx viewer shows these objects animating correctly.

The link to this thread where I have posted an example program showing a comparison to an unanimated version of the object in which the demo character can interact with and walk up stairs etc and then shows that the animated version has scaling and collision errors is:-



http://forum.thegamecreators.com/?m=forum_view&b=3&t=166987&p=4

My post was 4th March and is on page 5 of the thread

Was going to repost it here, but that would be a repeat upload

Thanks

Ok, found half a solution in that just exporting only the keyframes in blender makes the object animate just as in blender when in my darkBasicPro level...

But it`s collision object is still not in the right place as regards the visible faces, so can`t detect collision against it...

?

How are you setting up collision?
Are you scaling the object after setting collision?

The symptoms sound a bit like a misaligned or not properly referenced frame. The standard direct x viewer isn't a good gauge (in my opinion) as it seems to be a bit forgiving - probably with lots of error checks to help process the x file. So if a semi-colon or a template name is missed here or there, it may still process the x file.

Applications, such as DBPro and others, may have custom code that adheres strictly to how an x file should be formatted and laid out and it won't behave properly if there are any discrepancies. If you could rig up a simple object with simple animation that fails in dbpro (with collision and scaling) and post it, it may be possible to determine the problem by looking at the x file.

I read mention of AnimTicksPerSecond. This template may not be supported and depending on the application may alter your animation or cause an error. DBPro allows the speed of the animation to be controlled with commands so AnimTicksPerSecond may not be necessary and in fact may cause problems. It's easy enough to test, just try removing the template in you x file. Run it and see if there is any difference.

Ok, thanks for the suggestions regarding animticks I`ll definately try without if they`re redundant on the modeller side.

Also I am happy to say that I cured both errors by reassociating the textures with the model inside Ultimate Unwrap 3 and now the scale problem and collision problem don`t occur, resulting in an object that animates smoothly, can be multi textured as was in blender and walked on by a character

I did paste a program illustrating the problem in the link in the first post above and the collision is standard as in the Sparkys` Sliding Collision examples. The objects used in it are exported straight from blender, before I realised that porting the objects through UltimateUnwrap cured both problems.

At the end of the day, if it works, it works. glad you found a solution.

However, sparky's does work fine with exports directly from blender when everything is done correctly. Random faces with a flipped normal can cause problems, and aren't always apparent in blender depending on the view you are using and I don't believe that sparky's will collide with a backface. Most of those unwrapper packages perform some renormalizing which would fix such errors and could be why porting it through that works. If it turns out that this is the underlying problem, it could be done in blender before you export and save a step.



which one is it exactly? These are fairly different issues. does it just not collide or do you get a collision against it somewhere else where there is nothing apparent to collide against?

You may be correct about the normals causing the issue in blender as the object in question is half complete, has open faces, complex ie stairs etc, although there is a keystroke in blender that recalculates all the normals `Edit `Ctrl n``, which has been applied. Guess I should try with two perfect cubes at no scale to really test blender, then we`d be assured there to be no bad geometry from the outset, but yes `if it works, it works`.

On your second point, the object has indeed had its collision moved to a different location. If you run the program above it will show you the room in question firstly directly exported from blender as a single unaminated mesh with it`s collision working. Then you can walk out of a doorway, along a walkway that leads to the second version of the room exported straight from blender, animated. As you try to step onto it from the walkway, you`ll fall through onto the grey plane where you`ll find the invisible collision object of the room, which will probably hamper your finding your way to the ramp that leads back to the first room....

If you`d like to see the working version just say, as generally problem solved

This would happen in UDK often too. It would usually be due to the bones not facing the same direction or normals not facing the right direction.. Resetting the normals and making sure all bone normals are facing the same way would be the only way to fix it for UDK.
It was a pain to find that out and I would still get random problems in UDK, but I think that is more of their way to try to force you to use 3DS...