PDA

View Full Version : Meshes loosing their position



ryanstrains
June 4th, 2015, 12:34 AM
I have many assets of mine where the object part of the mesh is either shifted or rotated randomly on objects that were fine in TS12. The really odd thing is the attachment points on the mesh file still maintain the correct placement.

http://hostthenpost.org/uploads/72fec01a9b6e9c77544ea9f9b4e89bed.jpg
http://hostthenpost.com/uploads/65b736a9a979c48b1efdad3d3441ec01.png
http://hostthenpost.com/uploads/4a02d124457a4ad7742677999db0a989.png

WindWalkr
June 4th, 2015, 07:59 AM
I have many assets of mine where the object part of the mesh is either shifted or rotated randomly on objects that were fine in TS12. The really odd thing is the attachment points on the mesh file still maintain the correct placement.

There will be something specific to the way that you're composing your mesh (complex relationships between bones, animation points, parent meshes, etc.)

If it's different than TS12, then it's inevitably a code bug of some kind, but we'll need to narrow down the exact trigger in order to resolve it.

The place to start here is typically by simplifying things- at some point you'll get to the simplest possible repro case for your problem, and that should give us the information we need to work out what's causing it.

chris

andi06
June 4th, 2015, 08:57 AM
Here's one I cooked earlier:

http://i1216.photobucket.com/albums/dd367/andi061/Capture22.jpg

Look at the rear wheels. This is a bogie drawn in max with its axle aligned along the Z axis. The attachment point on the bus is rotated 90 degrees in its Y axis which had the effect in TS12 of realigning the wheels to the correct relationship with the bus but preventing them from steering (this was back in the days before the permit-rotation tag existed)

What seems to be happening is that TANE isn't looking at the complete rotation matrix of attachments - its just considering the location of a.bog1 and not its three-dimensional orientation. So the wheels come off the bus.

Its no big deal to amend this asset for TANE but I have seen similar problems elsewhere.

Bus is kuid:122285:600, bogie is kuid:122285:609, there are notes on usage in the description of the bogie asset.

Is there any chance of allowing small direct picture attachments in this forum?

WindWalkr
June 4th, 2015, 09:06 AM
What seems to be happening is that TANE isn't looking at the complete rotation matrix of attachments - its just considering the location of a.bog1 and not its three-dimensional orientation. So the wheels come off the bus.

Quite likely for bogeys because they're being handled entirely differently now, what with the 'train motion' support and superelevation.

This shouldn't affect other (non-bogey) elements though, and yet the first picture in this thread doesn't seem to be a bogey issue.



Is there any chance of allowing small direct picture attachments in this forum?

I doubt it, but I'll ask.

chris

pcas1986
June 4th, 2015, 09:09 AM
Here's one I cooked earlier:

http://i1216.photobucket.com/albums/dd367/andi061/Capture22.jpg
...

:hehe: :hehe:

Sorry, that just cracked me up.

I just committed an asset made in Blender with animated attachment points and it looks ok in 76401.

andi06
June 4th, 2015, 09:22 AM
I just committed an asset made in Blender with animated attachment points and it looks ok in 76401.
I guess that when you animate you can't ignore the third dimension.

Pencil42
June 4th, 2015, 09:24 AM
Indeed - the wheels came off the bus.. literally ;-)
Like was mentioned above, the rotation value of attachment points used for bogeys appears to now be ignored. I have a couple of cars on the DLS with backwards couplers on one end (TANE only; TS12 works fine) that were exported out of Blender.

WindWalkr
June 4th, 2015, 09:39 AM
Indeed - the wheels came off the bus.. literally ;-)

That they did. A most excellent screenshot :)



Like was mentioned above, the rotation value of attachment points used for bogeys appears to now be ignored. I have a couple of cars on the DLS with backwards couplers on one end (TANE only; TS12 works fine) that were exported out of Blender.

Don't rework these, by the way- it's considered a probable bug and will be reviewed. Just because we know why it happens doesn't mean that we're happy with it.

chris

RPearson
June 4th, 2015, 02:51 PM
I posted this (http://forums.auran.com/trainz/showthread.php?107912-East-Broad-Top-RR-in-Trainz-a-WIP-(Large-Pics-Yes)&p=1401374#post1401374) in the screen shots forum on my EBT WIP thread.

Both the turntable and the railcar supported are working correctly TS12 build 61388. TANE screen shots were in build 76401 but I get the same in 76536.

Bob Pearson

Kevin16c
June 4th, 2015, 09:03 PM
Hello all. It would seem that I am experiencing a similar issue to some of you have been describing on a locomotive of mine. The locomotive uses a leading bogey and the leading bogey has two dummies. b.r.main and b.r.wheel0. The b.r.main is centered at the origin in 3dsmax and has the "armature/frame" mesh linked to the b.r.main. The bogey is linked to b.r.wheel0. b.r.wheel0 is subsequently linked to b.r.main. so the hierarchy essentially is as follows:

3ds Max Heirarchy and mesh:
http://i944.photobucket.com/albums/ad287/Adam1228/Untitled-1_zpsepcoe7bh.jpg

What happens is that wheel0 and b.r.wheel0 "loose" their mesh positions (presumably rotations as well) and are moved to position of b.r.main. However that said, the frame does not loose its position or rotation. I also have a similar error with another bogey that, based on some testing, seems to indicate that meshes retain their positions/rotations, but T:ANE seems to reset the positions of all of the b.r.xxxx dummies.

T:ANE result:
http://i944.photobucket.com/albums/ad287/Adam1228/2015-06-04%20214649_zps7c44wejp.jpg

A simple test that I did was to take a bogey that worked in ts12 and place it in T:ANE. Took some screenshots for comparison and noted the positions of all the meshes. Then I re-exported the mesh with the alteration of the b.r.xxx being placed at the origin and the mesh linked to it "offset" from the b.r.xxxx so that it was in its desired position. In T:ANE with the b.r.xxx positioned at the mesh origin and the mesh offset from the dummy/bone the placements held. Though the animation as you could imagine was extremely wonky ;) I would be more than happy to submit both bogeys and meshes to you chaps (via pm) for testing.


Couple notes:

Here are some pictures showing the mess. Note that the one "connecting" rod is in the correct position. This is the one that I performed the test on. Everything that is "wonky" is everthing that did not have a b.r.xxx dummy/bone centered at the origin. Also I always center b.r.main at the origin. Also that wheel you see is actually two wheels that are occupying the same space. They are in their proper positions in 3dsmax and TS12 but are now both positioned at the mesh origin/b.r.main dummy when in T:ANE.





http://i944.photobucket.com/albums/ad287/Adam1228/Untitled-1_zpssu8jceto.jpg You will see that two rods are positioned outside of the wheels. They were tests of the offset.

http://i944.photobucket.com/albums/ad287/Adam1228/Untitled-2_zpsea0ihzid.jpg Another Angle.

ryanstrains
June 4th, 2015, 11:48 PM
Chris, if you'd like copies of the assets and/or source files for the assets that are going crazy feel free to shoot me a message on Skype so we can get this worked out!

Kevin16c
June 5th, 2015, 05:55 PM
After pondering on the issue some more overnight. I would almost say that it would appear T:ANE is taking not just b.r.main and placing it at the attachment point, but the remaining b.r.xxx dummy/bones as well. This is just a hypothesis based on my own content though ;) Mainly just food for thought for the dev teams. :D

WindWalkr
June 5th, 2015, 07:55 PM
Thanks, all.

Kevin16c, are you able to separate out that portion that you showed in the Max screenshot and still repro the same issue? I assume you've already confirmed that this same approach is working in TS12? If so, can you please send the game assets (NOT the max files) through to trainzdev@auran.com and i'll take a look at what is going on; it's a nice and simple construct so should be relatively easy to debug.

chris

Kevin16c
June 5th, 2015, 08:18 PM
By separate out, do you mean removing the b.r.wheel dummy/bone and linking the wheel directly to the b.r.main? I am not in front of my trainz pc at the moment so I will have to send the file as soon as I get back. When i do get it sent, look for a subject along the lines of "Trainz Dev: Bogey Position Loss".

WindWalkr
June 5th, 2015, 08:30 PM
No worries :)

Mainly i mean keeping the pieces you showed in that screenshot, rather than including an entire bogey/loco with that being just one part. If I have 10+ bones to dig through, it's going to be a lot harder for me to determine what's going on than if i have 2-3 bones.

chris

Kevin16c
June 5th, 2015, 08:37 PM
Ah. Its still in the same shape. Just two bones the wheel and frame in the bogey.

narrowgauge
June 5th, 2015, 09:07 PM
I think my Garratt has the same sickness as Kevins
.582
Garratt G42 in TS12.
583
Same Garratt in T:ane

Thes shots are the taken of the same 3.5 build file in TS12 and then in T:ane. This is not the original type of 3 separate unit Garratt assembly, steam units are now bogies of the Boiler unit using the later bogie tags. Note the shiny top and bottom crosshead guides, normally there are only two in side view, in the T:ane screenshot the loco seems to have grown a few more. Note also that the front water tank has gone missing in the T:ane shot. Note that the wheels are now sunk below the track.

Peter

WindWalkr
June 5th, 2015, 10:27 PM
Looks like attachments still aren't working, so you might need to post them elsewhere or email them in.

chris

narrowgauge
June 5th, 2015, 10:32 PM
Chris

Who are you replying to?

Peter

WindWalkr
June 5th, 2015, 10:34 PM
You :)

chris

narrowgauge
June 5th, 2015, 10:44 PM
OK
Thanks
Peter

narrowgauge
June 6th, 2015, 01:48 AM
http://users.on.net/peterpar/pics/garratt_in_ts12.jpg
In TS12
http://users.on.net/peterpar/pics/garratt_in_tane.jpg
In T:ane
These shots are the taken of the same 3.5 build file in TS12 and then in T:ane. This is not the original type of 3 separate unit Garratt assembly, steam units are now bogies of the Boiler unit using the later bogie tags. Note the shiny top and bottom crosshead guides, normally there are only two in side view, in the T:ane screenshot the loco seems to have grown a few more. Note also that the front water tank has gone missing in the T:ane shot. Note that the wheels are now sunk below the track.

Peter

WindWalkr
June 6th, 2015, 05:11 AM
Thanks. A lot more going on there visually than in Kevin's example, so I'll wait till I see what I can get from his and then we'll see if yours is still playing up.

chris

Kevin16c
June 6th, 2015, 09:04 PM
Just got back to my main pc. I should have the cdp submitted within an hour :)

Kevin16c
June 6th, 2015, 09:57 PM
Thanks. A lot more going on there visually than in Kevin's example, so I'll wait till I see what I can get from his and then we'll see if yours is still playing up.

chris

I have just sent off the cdp to the the email you provided on the previous page with the same subject I mentioned earlier. The bogey is still in the same state as my pictures on the previous page. The cdp includes the cdp and the "locomotive" needed to place it on the tracks. The loco is just a simple debugging asset that consists of attachment points and a sole mesh object. No scripting, no extra effects. Just the bare essentials needed to placed in driver. :D

WindWalkr
June 6th, 2015, 10:31 PM
Thanks, I appreciate the effort. Will get back to you when I know more.

chris

narrowgauge
June 7th, 2015, 01:55 AM
Chris

I think you have a more general problem that may shed some light on the problem that Kevin and I have. In CM select any rolling stock item, preview it, looks good? Has all its bogies? Good. Now list dependencies, select the bogie itself and preview it. If you see what I see, you will see the frames and just one wheel set. If CM fails in this way with a simple bogie design, then it could be the reason why my Garratt bogies fall to pieces. and perhaps Kevin's problem.

Peter

Peter

Kevin16c
June 7th, 2015, 02:14 AM
Chris

I think you have a more general problem that may shed some light on the problem that Kevin and I have. In CM select any rolling stock item, preview it, looks good? Has all its bogies? Good. Now list dependencies, select the bogie itself and preview it. If you see what I see, you will see the frames and just one wheel set. If CM fails in this way with a simple bogie design, then it could be the reason why my Garratt bogies fall to pieces. and perhaps Kevin's problem.

Peter

Peter

Just to be clear are you saying that when you choose to preview a locomotive or piece of stock that the bogeys display correctly but not when you preview the bogey itself? If so, then your issue may be different then mine. My bogey displays exactly like screenshot on the previous page in this thread weather I view it in game, preview the Locomotive, or preview the bogey itself. It would make me think that I have mucked something up in 3dsMax if it were not for the fact that it works in TS09 through TS12 without any trouble.:o Of course knowing me, I very well could have as I tend to make plenty of mistakes. :hehe:

narrowgauge
June 7th, 2015, 03:30 AM
Kevin

Have you looked at other bogies? I'm not suggesting that this is the cause of your problem, just that it may indicate an underlying problem. Every bogie I previewed showed up with one only wheel set, on what appeared to be the XYZ zero point.

Just had a thought, there are two ways of positioning a bogie one the strange 'Auran' way or the logical way with the wheel treads on the X axis, I wonder if this difference has been allowed for in CM.

Peter

WindWalkr
June 7th, 2015, 06:04 AM
I think you have a more general problem that may shed some light on the problem that Kevin and I have. In CM select any rolling stock item, preview it, looks good? Has all its bogies? Good. Now list dependencies, select the bogie itself and preview it. If you see what I see, you will see the frames and just one wheel set. If CM fails in this way with a simple bogie design, then it could be the reason why my Garratt bogies fall to pieces. and perhaps Kevin's problem.

This sounds like it could possibly be being displayed without any animation applied at all. I'll check into this, but if so then it's probably just an artefact of the bogey being displayed in isolation (whereas in-game it is assumed that it will always be attached to an operational train car.)

chris

WindWalkr
June 7th, 2015, 08:39 AM
I have just sent off the cdp to the the email you provided on the previous page with the same subject I mentioned earlier. The bogey is still in the same state as my pictures on the previous page.

Okay, I have some preliminary results from this. The short version is that the .im file and .kin file don't actually match. The mesh has "r.main" and "r.wheel01", whereas the animation file has "r.main" and "r.wheel0".

While I can't completely rule out the possibility of a code bug somewhere, the most likely explanation would be that you exported the IM and KIN files from two different Max scenes (or at least in two separate export processes involving separate objects in the scene.)

Assuming that is the case, the only real question that remains is why the behaviour is different in TS12. I would ask you to double-check what you're seeing there (since if a mistake was made in one step, it's feasible that a similar mistake was made elsewhere.) Assuming it's still behaving differently, my guess would be that the behaviour of TS12 when faced with mismatched or missing animation data is slightly different to the behaviour in T:ANE. This is something that i'll review further.

chris

Kevin16c
June 7th, 2015, 11:55 AM
It would appear that you are indeed correct.:eek: I guess I got ahead of myself forgot to re-export the anim file back when I made it the Christmas before last. Knowing that, I just went back and did some preliminary testing on another model of mine that has the same issue, although substantially more complex, and the issue is still there. (the other bogey in my post on page 1) I don't have time to fully test it right now nor is a probably good base-case candidate as its using andi06's bogey swapping. Perhaps some of the bogey handling changes are producing some unexpected results with his scripting.... I'll test this on my end asap...:D If this turns out to be true would it would probably be better to discuss under a new thread.

andi06
June 7th, 2015, 12:22 PM
nor is a probably good base-case candidate as its using andi06's bogey swapping. Perhaps some of the bogey handling changes are producing some unexpected results with his scripting.... .

I'm not seeing any problems with scripted bogies on my own assets (the bus bogie posted about earlier isn't scripted).

Kevin16c
June 7th, 2015, 08:58 PM
I'm not seeing any problems with scripted bogies on my own assets (the bus bogie posted about earlier isn't scripted).

The reason I suggested that it could remotely be something to do with the script is because if memory serves, when I remove the scripting the bogey returns to normal. (Again if memory serves) When I get home tonight I have some checking/testing to do with the model to make sure that the im and kin files are from the same export and not mismatched like the other asset that I was having issues with that Chris took a look at.

Lots of checking/testing to do though as I want to thoroughly double check the other asset as well. I honestly doubt that it has anything to do with the script though. ;)

Kevin16c
June 8th, 2015, 12:07 AM
Ok so after doing some re-exporting the animations and meshes several times and scratching my head I started checking the config file to see if there was something was amiss. It turns out that on my super-scripted bogey on the first page of this thread (the 0-4-0) explicitly telling trainz where the kin file was fixed the problem. Everything displays and works as it should. Correct me if I am wrong but isnt trainz supposed to automatically load an anim.kin file if present in the folder?

Asset heirarchy:



main folder

config file
thumnail
invisible mesh.im
invisible mesh.jpg
bogey 1 folder

bogey1.im
bogey1.kin
bogey1 texture files


bogey 2 folder

bogey2.im
bogey2.kin
bogey2 texture files






In other words, if I tell trainz that the bogey mesh is in the folder for bogey1 should trainz not also pull in the associated kin file provided that they are in the same folder and are either named anim.kin or share the mesh name? I ask this as TS12 seems to follow this logic. Has something intentionally changed so that content creators now have to explicitly state for each animated mesh where the anim.kin file is or is this a bug?

Snippet of the afflicted asset's mesh table:


default
{
mesh "main.im"
auto-create 1
}

frame-0
{
mesh "main.im"
att "a.frame"
att-parent "default"
auto-create 1
}

axle0-0
{
mesh "bogey2/bogey.im"
anim "bogey2/anim.kim" //Including this line seems to fix the issues with the bogey not displaying/working correctly
att "a.frame"
att-parent "default"
auto-create 1
}


Perhaps adding this to some of the other content (if they are animated) will correct their problems?


Andi by any chance have you viewed your bus bogey in Assetx? I was taking a look at it an asset x displays the bogey rotated at 90* just like in your screenshot.


EDIT: I just tested my theory with ryanstrains' RR crossing models (crossings in the first post of this thread) specifically kuid:321936:101444. When the anim tag is added, the model displays correctly in T:ANE



anim "1220.kin"


It would seem that the root of this issue is caused by not including the anim tag.
Working Solution: Add the tag.

ryanstrains
June 18th, 2015, 07:45 PM
Ok so after doing some re-exporting the animations and meshes several times and scratching my head I started checking the config file to see if there was something was amiss. It turns out that on my super-scripted bogey on the first page of this thread (the 0-4-0) explicitly telling trainz where the kin file was fixed the problem. Everything displays and works as it should. Correct me if I am wrong but isnt trainz supposed to automatically load an anim.kin file if present in the folder?

Asset heirarchy:



main folder

config file
thumnail
invisible mesh.im
invisible mesh.jpg
bogey 1 folder

bogey1.im
bogey1.kin
bogey1 texture files


bogey 2 folder

bogey2.im
bogey2.kin
bogey2 texture files






In other words, if I tell trainz that the bogey mesh is in the folder for bogey1 should trainz not also pull in the associated kin file provided that they are in the same folder and are either named anim.kin or share the mesh name? I ask this as TS12 seems to follow this logic. Has something intentionally changed so that content creators now have to explicitly state for each animated mesh where the anim.kin file is or is this a bug?

Snippet of the afflicted asset's mesh table:


default
{
mesh "main.im"
auto-create 1
}

frame-0
{
mesh "main.im"
att "a.frame"
att-parent "default"
auto-create 1
}

axle0-0
{
mesh "bogey2/bogey.im"
anim "bogey2/anim.kim" //Including this line seems to fix the issues with the bogey not displaying/working correctly
att "a.frame"
att-parent "default"
auto-create 1
}


Perhaps adding this to some of the other content (if they are animated) will correct their problems?


Andi by any chance have you viewed your bus bogey in Assetx? I was taking a look at it an asset x displays the bogey rotated at 90* just like in your screenshot.


EDIT: I just tested my theory with ryanstrains' RR crossing models (crossings in the first post of this thread) specifically kuid:321936:101444. When the anim tag is added, the model displays correctly in T:ANE



anim "1220.kin"


It would seem that the root of this issue is caused by not including the anim tag.
Working Solution: Add the tag.

Im confused why it would need the animation .kin if the crossings with the issue have no animated parts on them.

Kevin16c
June 21st, 2015, 02:05 PM
All I did was edit the config files for each crossing to include an anim tag pointing to a xxxx.kin file that has the same name as the xxxx.im file and it just works :o. Don't ask me why its the case because I am confused as well.
I took the RR Crossing 12x24NG ST <kuid:321936:101604> and changed the default tag to look like so and it just works in game....


default
{
mesh-asset <kuid:321936:102110>
auto-create 1
mesh "1224ng.im"
anim "1224ng.kin" <---Only edit made.

WindWalkr
June 21st, 2015, 06:28 PM
It turns out that on my super-scripted bogey on the first page of this thread (the 0-4-0) explicitly telling trainz where the kin file was fixed the problem. Everything displays and works as it should. Correct me if I am wrong but isnt trainz supposed to automatically load an anim.kin file if present in the folder?

Bogeys are weird. There is a bunch of legacy support for animations. I believe it will try to automatically load "anim.kin" from the asset's top-level folder (NOT from next to the .im file) if you have a non-zero "animdist" setting. This is loaded onto the first mesh in your mesh-table, and configured as looping. This is the same in TS12 and T:ANE.

If you're seeing a difference when using the layout you describe, then it would seem that the difference is in how TS12 loads an animated mesh with no KIN file vs how TANE loads the same animated mesh with no KIN file. It may be that the "default" bone positions (which would be overwritten by the data from the KIN file) are different between the builds.

It may be simpler to test this on a simple scenery asset rather than a bogey, as the bogey has a lot of weird compatibility stuff going on that may confuse your testing. The scenery object will basically just do what you say in the mesh table, so your tests should be a lot more predictable.

chris

narrowgauge
June 21st, 2015, 10:00 PM
Chris

Re-opened in thread "Strange Bogie Behavior'

Peter

WindWalkr
June 21st, 2015, 11:59 PM
It does not appear to be a a bogey problem. I am lost, where do I go from here?

Your best bet is probably to start a new thread for this issue, and then give me a testcase asset.

chris