[scottb613]

Hi Rick,

I can't help much more with your signal issue - but - I have been using 3DC for a while - if you ever hit a roadblock and want to compare notes - just ping me with a PM and I'll be glad to try and help... Best of luck - sir...

Regards,
Scott

[rickloader]

James, thanks for your help. I think your analysis is correct. I have an animated theatre box signal with 17 sub objects, and because each part is a subobject in sigcfg, (head 1,2,3 etc )OR displays the signal corrrectly. ( a uk theatre box has mechanical numbers that rotate into the display aperture, showing the route signalled)
A solution may be to make my animated ancillary parts into sigcfg sub objects. I can easily modify the sigcfg in the OR folder. So there maybe no need to modify OR code, especially as I expect you are very busy on the OR V1 preparations.
I will try this and report back.
Scott, thanks for your kind offer: I do sometimes get stuck with 3dc.
Best wishes, rick

[James Ross]

I've got a test build based on X3708 which might fix this issue:

 Open Rails X3708 animated-signal-parts 1.zip (1.1MB)
Number of downloads: 648

[rickloader]

Thank you James for remembering this problem.
Your test build now displays the both the animated and extra non animated parts in the signal shape that were previously invisible in OR, but shown in msts. Thanks!
But the animated parts now shown still don`t move, although the signal arm (head1 etc) does of course. I can live with this.

Over on UKTS there is a thread about uk theatre and clack box signals - maybe relevant?

In running the x3708 test, I`ve just noticed the UK combined Home and Distant signals are now working correctly. This is very welcome, and I`m sure will be appreciated by uk modellers
Thanks again, rick

[Jovet]

rickloader, on 19 December 2016 - 04:31 PM, said:

Your test build now displays the both the animated and extra non animated parts in the signal shape that were previously invisible in OR, but shown in msts. Thanks!
But the animated parts now shown still don`t move, although the signal arm (head1 etc) does of course. I can live with this.
Over on UKTS there is a thread about uk theatre and clack box signals - maybe relevant?

This is interesting to me.... I've not had any issues with animation with my signals and switchstands. Both use a complex hierarchy of permanent and optional parts. But my shapes are created in Gmax...not sure if that makes a difference.

This is the hierarchy of one of my two-blade semaphore signals, for example:
http://msts.jovet.net/files/images/SemaphoreHeirarchy.png

The SignalSubObj entries are assigned to the ARM1 and ARM2 parts. All of the child parts animate correctly and display correctly. Hmmmmm.

[rickloader]

Thanks Joseph. That ancillary animated parts can work in ORTS is valuable info. I`m doing something wrong then.
Now, are you saying that the decorative animated child parts are also declared in the sigcfg as "SignalSubObj" ?
So your italicized eg cover1b is a signal subobject, and my operating rod should be also also? Certainly I can make them so: "decor" or similar

My sigcfg looks like this

SignalShape (
"SRStop.s"
"SR Stop"
SignalSubObjs ( 1
SignalSubObj ( 0
"HEAD1"
"Stop arm"
SigSubType ( SIGNAL_HEAD )
SignalFlags ( DEFAULT )
SigSubSType ( "SRStop" )
)
I think also your blue items having the animation keys is different to 3dc ,because in 3dc they are attached to the child group.
When I get a moment I will experiment
thanks, rick

[Jovet]

rickloader, on 20 December 2016 - 01:52 PM, said:

Now, are you saying that the decorative animated child parts are also declared in the sigcfg as "SignalSubObj" ?
So your italicized eg cover1b is a signal subobject, and my operating rod should be also also? Certainly I can make them so: "decor" or similar

The child parts should (and do) animate automatically. The optional ones are declared as DECOR SignalSubObjs so they can appear as needed and are hidden otherwise. (e.g. only one Blade should be turned on per arm at a time)

Here's what the standard SignalShape entry looks like for the above shape:

	SignalShape (
		"JJHsig1UQ02.s"
		"UQ Semaphore 2-Arm Home [2-Tier]"
		SignalSubObjs ( 18
			SignalSubObj ( 0
				"ARM1"
				"Signal Arm 1 (Red-Ambr-Grn)"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( DEFAULT )
				SigSubSType ( "JJHSemUQ3PosRAG1" )
			)
			SignalSubObj ( 1
				"BLADE1S"
				"Arm 1 - Yellow/Square Blade"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL DEFAULT )
			)
			SignalSubObj ( 2
				"BLADE1S2"
				"Arm 1 - Red/Square Blade"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 3
				"COVER1B"
				"Arm 1 - Cover Amber Lens"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 4
				"COVER1C"
				"Arm 1 - Cover Green Lens"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 5
				"ARM2"
				"Signal Arm 2 (Red-Ambr-Grn)"
				SigSubType ( SIGNAL_HEAD )
				SignalFlags ( OPTIONAL DEFAULT )
				SigSubSType ( "JJHSemUQ3PosRAG2" )
			)
			SignalSubObj ( 6
				"BLADE2S"
				"Arm 2 - Yellow/Square Blade"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL DEFAULT )
			)
			SignalSubObj ( 7
				"BLADE2S2"
				"Arm 2 - Red/Square Blade"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 8
				"COVER2B"
				"Arm 2 - Cover Amber Lens"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 9
				"COVER2C"
				"Arm 2 - Cover Green Lens"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 10
				"PLATFORM1"
				"Show Top Platform"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL DEFAULT )
			)
			SignalSubObj ( 11
				"PLATFORM2"
				"Show Lower Platform"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL DEFAULT )
			)
			SignalSubObj ( 12
				"LADDERG"
				"Show Inclined Ladder Only"
				SigSubType ( DECOR )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 13
				"NUMBER"
				"Show Number Plate"
				SigSubType ( NUMBER_PLATE )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 14
				"GRADIENT"
				"Show Grade Plate"
				SigSubType ( GRADIENT_PLATE )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 15
				"DUMMY"
				"Show Approach Medium (4th Aspect)"
				SigSubType ( USER1 )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 16
				"DUMMY"
				"Show Advance Approach Medium"
				SigSubType ( USER2 )
				SignalFlags ( OPTIONAL )
			)
			SignalSubObj ( 17
				"DUMMY"
				"Two-Armed Signal"
				SigSubType ( USER4 )
				SignalFlags ( DEFAULT )
			)
		)
	)

As you can see, SignalSubObj #0 assigns the SignalType for the topmost arm. It's assigned to the shape part ARM1. ARM1 itself does not have any animation, but its child part PIVOT1 does. All of the other parts are children of PIVOT1 so they are subject to the animation performed on PIVOT1.

You might also notice that the second arm, in its entirety, is marked as optional in my above hierarchy diagram and the signal shape code above. When it's turned on, then ARM2, PIVOT2, and BLADE2 all appear at the same time (as they are all the same matrix in the shape file). All of the child parts of BLADE2 are separate and need additional DECOR entries to appear.

rickloader, on 20 December 2016 - 01:52 PM, said:

I think also your blue items having the animation keys is different to 3dc ,because in 3dc they are attached to the child group.

I haven't played with 3DC in a long time, so I'm not quite sure how animation and shape matrices are setup in it. The effect might be the same, though, as all of the child parts (if you want to think of them as a group) are all subject to the animation of their parent parts. When exporting from Gmax, I can decide exactly which parts are what (for internal matrices) and which parts get combined together.

The bottom line is that animation should be applied to the named shape part which will then affect all of that part's child parts. This isn't something I've ever had trouble with in OR.

[James Ross]

Jovet, on 20 December 2016 - 09:23 AM, said:

This is interesting to me.... I've not had any issues with animation with my signals and switchstands. Both use a complex hierarchy of permanent and optional parts. But my shapes are created in Gmax...not sure if that makes a difference.

This is the hierarchy of one of my two-blade semaphore signals, for example:
http://msts.jovet.net/files/images/SemaphoreHeirarchy.png

The SignalSubObj entries are assigned to the ARM1 and ARM2 parts. All of the child parts animate correctly and display correctly. Hmmmmm.

The display difference is down to you declaring them as SignalSubObj, but rick not; MSTS seems to default to displaying unmatched SignalSubObj items so that's what I changed in the test build.

The animation in OR is done by applying it to the node specified for the SIGNAL_HEAD (e.g. ARM1) and all descendant nodes. I am not sure what MSTS does, but perhaps it animates all nodes except those inside other SIGNAL_HEAD nodes?

Jovet: I am slightly concerned that we might have broken that signal hierarchy in X3708, as we seem to now be requiring the SIGNAL_HEAD's node to have animation controllers.

[Jovet]

James Ross, on 21 December 2016 - 05:42 AM, said:

The display difference is down to you declaring them as SignalSubObj, but rick not; MSTS seems to default to displaying unmatched SignalSubObj items so that's what I changed in the test build.
The animation in OR is done by applying it to the node specified for the SIGNAL_HEAD (e.g. ARM1) and all descendant nodes. I am not sure what MSTS does, but perhaps it animates all nodes except those inside other SIGNAL_HEAD nodes?
Jovet: I am slightly concerned that we might have broken that signal hierarchy in X3708, as we seem to now be requiring the SIGNAL_HEAD's node to have animation controllers.

The animation in OR sounds identical to what MSTS does. Each part is animated in turn, like a domino effect, starting with the named part, and with the effects of animation of a parent part affecting its children in the same manner, before the children's own animation is performed. As I've said above, animation is one thing I've never had any trouble with in OR. It has always worked the same and correctly for me in OR as it does in MSTS.

I'm not sure what you mean by "unmatched SignalSubObj items." But I have now caught up properly on this thread and found rickloader's hierarchy screenshot. What rickloader's original and actual problem was is that his rods and other ancillary parts (BALANCEARM, ROD) are not children of HEAD1. Compare his screenshot to mine here. I also suggest that the mesh matrices don't appear to be right. For example, the meshes shown under HEAD1 should all have a "1" icon, but only the first two do. For BALANCEARM, only the first mesh shown has a "2". Whether this is the fault of the 3DC exporter or rickloader's setup of the shape hierarchy I don't know. The "4" mesh at the very end doesn't even have a name, which also seems very suspect. It's my understanding that one has to setup "fake animation" for all named parts that aren't animated that one wants to survive into the shape file when exporting from 3DC, but not having used it I can't advise for sure.

Note that all of the bright-orange box icons in Shape Viewer indicate a unique mesh matrix in the shape, but only the second through fifth have special icons with numbers (1-4). I have always suspected that Mr. Gausden elected not to make unique, numbered icons for the other 59 potential mesh matrices that a shape file could have.
;)

For his signal to display and animate correctly, BALANCEARM and/or ROD must be children of the SignalSubObj part HEAD1, either direct descendants or one a child of the other. They should also end up with the same "matrix numbers" in the Shape Viewer (e.g. "1" or "2" etc.) I don't see any reason why BALANCEARM and ROD would be made visible by MSTS. That's surprising and confusing. Named parts (and associated matrices that are not matrix #0) should not be visible unless they're invoked by a SignalSubObj.

I can confirm that my semaphore animation is now broken in X3710.

[Csantucci]

Hi Joseph,
pls. check whether following .exe patch to x3710 fixes your problem.

[Jovet]

Csantucci, on 21 December 2016 - 10:04 AM, said:

pls. check whether following .exe patch to x3710 fixes your problem.

It sure does, Carlo.

[Csantucci]

I've uploaded in x.3712 a fix.

[Jovet]

Jovet, on 21 December 2016 - 08:40 AM, said:

I don't see any reason why BALANCEARM and ROD would be made visible by MSTS. That's surprising and confusing. Named parts (and associated matrices that are not matrix #0) should not be visible unless they're invoked by a SignalSubObj.

I don't know how the 3DC exporter and hierarchy/LOD system works, but the Gmax exporter lets me differentiate between a "shape sub object" and a part. A shape sub-object seems to be called a matrix internally in the .s file format. Every mesh object within Gmax is a part. The exporter lets me specify which parts are children of which, and which parts should be combined into the same matrix in the .s file. For my signal hierarchy above, ARM1 has one child called PIVOT1, and PIVOT1 has one child called BLADE1. All three are part of matrix #0 (or, sub-object #0 in Gmax). Every .s file has a matrix #0 (most only that) and it is always visible according to its LOD configuration. The part BLADE1P is a child of BLADE1, but it has a different matrix ID so it has to be specifically told to show up with a SignalSubObj. Compare all of this to the second semaphore arm—ARM2 has a child part of PIVOT2 which has a child part of BLADE2. All three of these parts are still separate but they share the same matrix ID (sub-object number) which is not zero... so they are all optional and also appear at the same time. If that helps.

Also note that I have created a few "order board" semaphore signal shapes which have moving rods and such, and they also work fine in OR like they do in MSTS.

Csantucci, on 21 December 2016 - 01:02 PM, said:

I've uploaded in x.3712 a fix.

Thank you, Carlo.

[rickloader]

Thank you Joseph for your detailed explanation. I`ve learned a lot.
I have tried to follow your hierarchy, using 3dc and x3710 but I can`t yet get the parts to display or animate. (can`t find x3712 in James` site)
I may try to replicate the signal using TSM, to see if 3dc is incompatible with OR, but I will have to relearn TSM as I haven`t used it for years!
I hope I am not causing James and Carlo extra work by my lack of knowledge.
rick

[Jovet]

rickloader, on 22 December 2016 - 05:14 PM, said:

Thank you Joseph for your detailed explanation. I`ve learned a lot.
I have tried to follow your hierarchy, using 3dc and x3710 but I can`t yet get the parts to display or animate. (can`t find x3712 in James` site)
I may try to replicate the signal using TSM, to see if 3dc is incompatible with OR, but I will have to relearn TSM as I haven`t used it for years!
I hope I am not causing James and Carlo extra work by my lack of knowledge.

I wouldn't bother with TSM at this point in time, 3DC should be able to do anything it can, and perhaps more. I'm sure we can get it figured out. X3712+ have shown up on James's site now, so that's another roadblock taken care of.

One other thing I'd like to point out is that there is a common "error" in animated signal shapes' SignalType configurations. The SemaphorePos value tells a SignalDrawState which animation pose (frame) to be in for that DrawState (aspect). This value should be zero-based, e.g. the first frame is frame #0. MSTS will silently assume the first frame is #1 if no SignalDrawState specifying #0 is utilized. Open Rails does not forgive this, though, so be sure you're assigning your SemaphorePos values correctly or the wrong frames may be used. (This is one of the few ways in which I believe OR correctly breaks existing MSTS signaling and should require existing-file correction, because the first frame should be specified as #0 anyways.)