FSXA FS2004 aircraft propeller states

#21
I am trying to merge the prop with a prop0_still visibility condition and the propdisk (twice) once as prop0_slow and once as prop0_blurred back into the main model (not the one I reassigned the variables to display the prop disk). I've reassigned the animation tags successfully from engine0 to prop0_xxxxx, where "xxxx" equals either prop0_still, prop0_slow, and prop0_blurred.


I have, sitting in the aircraft folder's "model" folder the modified prop disk model with two SceneGraphNode entries, each with a different vis condition and animation tag (either prop0_blurred or prop0_slow). Both conditions have textures assigned. When I import that model, and just that model, the textures display and the animations work. To perform the merge I first press the "Merge objects" key. A window opens that wants me to either load or select and object. There is nothing to select, so I hit load and browse to the aircraft folder and select the aircraft.mdl file. I then select the "Merge" button at the bottom of the window and MCX does it's thing and says "finished loading, but I don't see the model anywhere.
...
I don't get "Merge"???

Randy
Dumb question but - when you are using the merge tool are you setting the LOD correctly? It defaults to LOD = 100 but I notice in your screen shot of the biplane that the LOD is 185. I remember when I first started messing around with this that used to catch me all the time.

Gavin
 
#22
Gavin, you, sir, are a genius in my opinion. I am actually using a different model since I was having trouble with the Albatross apparently originally being an FS2002 model. I switched to a Fokker D VII. After I made sure the LODs matched on the two models being merged...SUCCESS.



The blur is more dark than I want, but that is now a texture problem and I can deal with that. The key thing in this screenshot is that autogen, trees and clouds now show visibly through the prop blur.

I need to do a little "tweaking" though besides just the texture for the prop blur. The wheels no longer spin during taxi though they did on the original and the actual prop object can be seen during the "blur stage and I would rather that disappear, but again, probably a much simpler fix than the blur itself was.

Progressing by leaps and bounds thanks to the help and advice of all. I take no credit. I am just walking in the footsteps of others...and enjoying it, but after a very arduous week of staring at MCX, RADItor, GIMP, DXTBMP, and various Forums it's time to...GO FLY.

I'll be back. ;)

Randy
 

=rk=

Resource contributor
#23
For your wheels, you want to check the animation tag and I am pretty sure it is just like engine0_still vs. Prop0_still and you want to use "l_tire_still_key" and "r_tire_still_key" or the FSX compiler will fix, as in solidify, the animations since it doesn't recognize them.
 
#24
Hello Rick,

You have been such a great help in all this. Once I learned what I was doing wrong on the merge issue your post detailing the process worked perfectly.

The "l_tire_still_key" and "r_tire_still_key" parameters worked great. Wheels now rotate and show speed changes perfectly. Thank you so much. Prop blur looks so much better as well now that I have lightened the texture bitmap and reworked the alpha.

The prop object appearing when the blurred prop disk is "active"...for lack of a better word...I'm not having any luck on. When in the virtual cockpit looking forward toward the prop everything works fine. Engine off, prop visible. Turn engine hand crank on the panel (similar to starting an old model T Ford) in the vc and the prop turns slowly, but as soon as the engine fires it "goes away" and all you see is blur...from the virtual cockpit.

Watch this process from outside in external view and when you press CTRL+E the propeller begins to turn, just as in the vc, but once the engine fires and the prop blur becomes visible the actual prop object remains visible as well, rotating at the same speed as the blur.

In MCX I isolated the prop from the main model and gave it a visibility condition of prop0_still. I also changed the animation from engine0 to prop0_still. Then I exported it as prop_still.mdl for later merge. Then I isolated the prop disk and changed it's visibility condition and animation tag to prop0_slow and exported it as prop_disk_slow. I then changed the vis condition and animation tag to prop0_blurred without exporting as a model. Then I merged it with the prop_disk_slow.mdl (giving me two sub-SceneGraphNodes under one higher SceneGrapNode - one for prop blurred and one for prop slow). The result of that merge I exported as prop_disk.mdl for later merge back to the main model. I then imported the main model, found the ScenegraphNode for the prop and removed it. Then I did two merges.

The first was the main model with the prop_still.mdl and the second to the "merged" main model (now showing the prop object) with the prop_disk.mdl, giving me a SceneGrapNode with three prop conditions; still, slow, and blurred. All three have a corresponding visibility condition; still, slow, and blurred and all three have the respective animation tags of still, slow, and blurred. i tried giving the prop a vis condition of none thinking the animation would show it slowly turning during start (which I want to see) and then disappearing once the slow and blur kicks in. That made sense to me...but didn't work. I still see the prop object at full throttle revolving along with the blurred image. it looks extremely unrealistic and I consider it my last hurdle and the model will be done and ready to fly over Flander's Field in formation with some Virtual Airline friends on Nov 11, 2018 as tribute to the 100th Anniversary of the end of WWI.

Randy
 

=rk=

Resource contributor
#25
ModelParts with the prop_still animation tag will only be visible during the prop_still condition, so if there are ModelParts visible from the prop_still animation during the prop_slow, or prop_blurred condition, the suspicion is that you have duplicate prop_still ModelParts that have been tagged for a different condition. If all these parts are visible in the MCX window, you can click various nodes in the Hierarchy Editor until the culprit is highlighted. If it remains invisible, try deleting the prop_still parts and see if their inappropriately tagged duplicates remain.
Also remember that virtual cockpit and exterior are distinct models in FSX. Anything visible of the outside model from the VC is part of the VC model and vice versa. If there are differences in the propeller animations, you need to decide which sequence is adequate, delete the other and copy the good animation sequence to the other model.
If you get any good screenshots of your success, they might encourage others to learn this skill also..
 
#26
Randy, what are you giving the visibility condition? the "SceneGraphNode" or the "ModelPart" beneath it? You have to give the visibility condition to the ModelPart not SceneGraphNode.

Yet another area where I spent hours hitting myself over the head before figuring it out.

Gavin
 
#27
Hello to both Gavin and Rick,

Sorry this post is so long in coming, but for some reason I couldn't access FSDeveloper's today until just a few minutes ago. ???

Gavin,

Yes, I looked at a lot of different Hierarchy Tables for a lot of different aircraft and quickly realized the part gets the vis_con, not the SceneGrahNode.

Rick,

I think I have it all sorted out and screenshots follow. Turned out the prop object that I "thought" I gave a vis_condition of prop0_still to was showing prop0_slow. The animation tag was prop0_still though, so not sure where or how the mixup happened. As I said, though, I think I have it sorted out now...

I took the download for the FS2004 Fokker D VII and placed it as is (after unzipping it) into the aircraft folder and gave the aircraft new titles so they would conflict with the Titles for the Fokker "modded".

Here is the FS2004 model straight out of the "box", no work with MCX done. This is the VC before start up...


And the FSX MCX version...


As you can see...no difference.

Now the FS2004 model from the VC after starting the engine...notice the grey building to the left of the wing struts. Completely visible through the prop blur, but the view from the VC never was the issue with prop blur.


And the FSX MCX version after start from the VC...other than a different prop blur texture, again, no real difference...


Now we move outside and here is where you can see the issue and the result from working the model with MCX...
FS2004 model with prop blur, notice the building has "disappeared" when looking through the blur...


And with the FSX MCX corrected blur...building and clouds visible through the blur...


Final two, one from the FS2004 aircraft looking through the blur at the aircraft. Notice the hal-moon section of the aircraft missing...


And FSX MCX looking at the aircraft through the blur...and the prop part is hardly visible unless you look very closely...


I call that success! Took me the better part of a day to get to this point because for some reason on some of the model export compiles I tried when experimenting with the prop blur animations and conditions the ailerons, elevator, and rudder would all snap to the model centerpoint and become "unanimated, although they worked fine in MCX. Think it was aradius issue...not sure. I remember reading about someone else's experience with that, but then FSDeveloper site quit working for me and I couldn't find it. I finally got it all sorted out though.

Thanks again...I know I have said that a lot here, but I truly mean it...to all who have helped, suggested, prodded, and encouraged...

Randy
 
#28
Well,

As you can see above I have a functional FS2004 model working in FSX without the prop blur masking autogen and objects and clouds. I am happy with the results, but in the process of reaching this point I came to realize that I neglected to add/correct modelpart animations to a few prop spin related parts like the propeller hub and flange and the cup anemometer on the wing strut.

So, being somewhat overconfident having reached this point, I decided to try and fix my oversight. I first copied and saved the model folder under a new name so as to not lose the progress I have made. and all associated parts and then opened first the original FS2004 model virtual cockpit with MCX and isolated the cup anemometer model parts. I corrected the animation tag (engine0 to prop0_still) and visibility condition and exported it as cup_still.mdl. Then I corrected the model in MCX twice more, exporting after each edit with correct animation tags and visibility conditions prop0_slow and prop0_blurred) as cup_slow.mdl and cup_blurred.mdl.

Then I imported my perfectly working and displaying (in FSX) internal model for the virtual cockpit. To that model I merged the cup_still, cup_slow, and cup_blurred models. I checked the animations and visibility conditions in MCX and jotted down the bounding box values to use with RADItor and exported that merged model as "INT_Fokker_DVII_test.mdl" to avoid overwriting the working "INT_Fokker_DVII.mdl" file. I corrected the model.cfg to read the new interior model name, correcting the values of the bounding box with RADItor, and started FSX. Since the hub and flange are not visible from the virtual cockpit I did not need to add them and wanted to check my results before working on the external model where all three parts will have to be merged.

Looking at the model in the FSX Aircraft preview screen all looked "normal" so I loaded the aircraft. Imagine my surprise when I saw the aircraft elevators, aircraft rudder, and aircraft ailerons "sitting" in the middle of the virtual cockpit and no longer animated or attached where they should be. I assure you this does not happen with the original FSX working internal model. In the exterior view, despite what I see in the vc (I know, two separate models, but I had to look) all appears and animates normally.

In all my searching, researching, and looking I remember reading about this "situation", but I cannot refind the article or forum where I read it...hoping a fix is there.

Randy
 

=rk=

Resource contributor
#29
Ok so the FS2004 animations can be stacked with a tick18 at the top and if so and you break this chain, the animations all get jumbled into the middle of the model. The previous sentence is kind of guesswork, but it was derived from empirical observation. There are tow effective work arounds when your animation challenges the model animation hierarchy. One solution is to parent your added part to one that is already in the hierarchy. Now this is "easy" with FSDesign Studio, to add an aileron or animated wing anemometer, you'd make the wing the parent, or the fuselage, etc. Presumably you could also accomplish this with MCX, through careful adjustment of position on the Hierarchy Editor tree.
Another solution is to add your compiled model to the new animated component, instead of the reverse, as would seem natural, or intuitive. Doing so seems to break the tick18 dependency situation.
 
#30
Once again, Rick, I bow to your wisdom. I didn't understand most of what you said in your first paragraph, but understood the second paragraph perfectly, so I tried the "reverse intuitive" solution and, of course, it worked.

Thank you sir. If I could find you and Gavin, and be able to, I would take you both out for dinner and drinks on me.

Randy
 
#32
Ok so the FS2004 animations can be stacked with a tick18 at the top and if so and you break this chain, the animations all get jumbled into the middle of the model. The previous sentence is kind of guesswork, but it was derived from empirical observation. There are tow effective work arounds when your animation challenges the model animation hierarchy. One solution is to parent your added part to one that is already in the hierarchy. Now this is "easy" with FSDesign Studio, to add an aileron or animated wing anemometer, you'd make the wing the parent, or the fuselage, etc. Presumably you could also accomplish this with MCX, through careful adjustment of position on the Hierarchy Editor tree.
Another solution is to add your compiled model to the new animated component, instead of the reverse, as would seem natural, or intuitive. Doing so seems to break the tick18 dependency situation.
Thanks for this insight Rick,
I have seen the "animations jumbled" scenario a number of times. Quite often I see it if I add visibility conditions to a model and then go back and change animations, textures etc. Also see it if I add lights before fixing all the animations and visibility conditions.

I hadn't connected it to the tick18 issue (separately I have asked Arno if he can see about adding an enhancement to import the tick18 animations) but in retrospect it is consistent with what I have seen.

Gavin
 
#33
Randy - glad to help. Looks like you have the makings of a nice looking model there.
In my experience the only way to avoid the "aircraft elevators, aircraft rudder, and aircraft ailerons "sitting" in the middle of the virtual cockpit and no longer animated or attached where they should be." problem is to work in very small stages. When you export the isolated part don't give it a visibility condition, just export it as a part (with an animation if it something like a prop) . Now re-import the main model and import the parts you are adding to the model and export it again. Then re-import it and add visibility conditions. Now export again and see if that helps.

Or try adding the main model to your prop model like Rick suggests. Let me know if that works as I have never tried it.

If you are adding a part that needs a visibility condition (say wheel chocks). You can isolate the part on the FS9 model using hierarchy viewer and export it as a discrete model. Import the model back into MCX and change the material colour to something different than the main model (this prevents MCX welding it to the main model when you export). Now you should be able to import the part into your model, export the model, then re-import it to add the visibility condition without getting the dreaded animations breaking issue.

Don't forget to keep copies of each stage of your work so you don't have to go back to the beginning each time.

Gavin
 
Top