Recent development release stability

[arno]

Hi,

The problem does NOT occur when creating the effect, but only when the saved BGL file is reloaded after compiling and you try to edit an effect.

I tried to analyze the problem as closely as possible.

Action: Rotation around the red axis, 90
Result: rotation around the blue axis, -180

Action: rotation around the green axis, 90
Result: rotation around the green axis 90 AND rotation around the blue axis -90

Action: Rotation around the blue axis 90
Result: rotation around the red axis 90

You will understand that you are not exactly enthusiastic about this mess. But I think you will find the mistake.It is not hidden and reproducible.

I tried it, but when I edit an affect in an existing model I also can't reproduce this problem. The rotation just stays like I enter it. Also after exporting the model again.

I am wondering is there is some setting in your MCX that might affect this. Can you post a screenshot of how your ObjectModel3D settings look (especially the collapse settings)?

 

[arno]

Hi,

Yes, here too. In the appendix, the standard tornado. There the mistake is most easily provoked.
As soon as you turn the model after it is fully loaded, it "explodes" and the MCX freezes.
The second example is the standard C130 Herkules. There it appears only after you have doubled effects several times. But yes, also here.

I did find a bug in reading the FX textures that caused the Tornado model to hang on import. That will be fixed in the next development release.

When debugging I work from my IDE, but I just download the latest development release I see that I can reproduce the issue with the exploded model in there (it does not show from my IDE). Let me try to figure out what goes on.

 

[arno]

Hi,

I did find a bug in reading the FX textures that caused the Tornado model to hang on import. That will be fixed in the next development release.

When debugging I work from my IDE, but I just download the latest development release I see that I can reproduce the issue with the exploded model in there (it does not show from my IDE). Let me try to figure out what goes on.

I looks like fixed the freeze issue, which was related to loading FX textures, the falling apart is also gone. I can't reproduce it at this moment anymore. Could you try the new development release I have just uploaded?

 

[PilotOne]

Hi,



I looks like fixed the freeze issue, which was related to loading FX textures, the falling apart is also gone. I can't reproduce it at this moment anymore. Could you try the new development release I have just uploaded?

OK.Last version downloaded and activated.


1) Tornado.
Will be loaded completely and correctly.
Turning of the model works correctly.

Test - FX Editor:
Attempts to duplicate individual effects existing in the model.
Already after the 3rd duplication the model flashes up briefly with the "explosion variant", but it is still rendered correctly.
After duplicating the 6th effect the display collapses and the "explosion" is shown.

2) Hercules C130.
Is loaded completely and correctly.
The turning of the model works perfectly.

Test - FX Editor:
Like the tornado, after the 6th duplication, the model "explodes".
Difference: up to the 6th duplication no error is announced. The model is rendered and displayed correctly after each change (duplication).

As far as I can see, the error can be provoked via the FX-editor. And, I have done the test series several times.
Result: after the 6th duplication process is over.

 

[PilotOne]

Regarding the error message about the error file fx_2sjp.bmp:

After intensive search I found out that this is an error in an original PMDG effect file.

It is the effect fx_PMDG_beacon.fx.
Here is the reference to the non-existent texture. If you correct this entry, everything is ok.
Also the error message does not come anymore.

As a user you don't notice this error in normal operation, that this is only the beacon of the service vehicle, which actually - because most of them have GSX too - is NOT used. So you never see the error.

You will only notice it if you use your excellent tool MCX, because here all parts of the model are loaded, no matter if it is activated or not.

Congratulations, you are NOT to blame for this error

 

[PilotOne]

As you requested, my settings.



The problem of the rotation is not solved. I have tried - with the latest version. You can see the result in the screenshots.




Subject: Visibility of light particle effects

No matter which preset you choose, P3D4 or P3D4.4

The light particle effects are always visible.
The "Show particle effects" switch only affects all other effects.



Low light effects remain on unchanged.
This was not the case before (earlier versions). I'm sorry, I am a critical observer.


But now I have to go. It is 03:10 AM. All of Vienna is sleeping, but not me

 

[arno]

Hi,

May I ask why you have all optimise settings set to false? The default value for all of those is true. If you leave them at the default settings the issue of the object exploding does not happen anymore.

I'll still check why it happens with the settings all to false, but it is better to have them set to true, as that makes MCX create more efficient models and work better.

The weird issues with entering the rotations are also gone if you set the optimize values to their default values btw.

 

[PilotOne]

Hi,

May I ask why you have all optimise settings set to false? The default value for all of those is true. If you leave them at the default settings the issue of the object exploding does not happen anymore.

I'll still check why it happens with the settings all to false, but it is better to have them set to true, as that makes MCX create more efficient models and work better.

The weird issues with entering the rotations are also gone if you set the optimize values to their default values btw.

Hello, Arno,


you're right.
But you are addressing exactly one - for users - sore spot.

You have created a lot of setting options. That's a good thing. However, for someone who hasn't developed the program, the problem is that he has no idea what the actual basic settings were if he changed something once or several times.

Here it would be nice if there were a reset button for "dummies" that restores the default values. Or there is another way to start over with the default settings.

My problem is that e.g. the latest version simply took over the settings I had on other versions. But I have no idea from where. Registry, ini file or whatever, I have no idea. You do.
On top of that, the MCX was put into operation on a completely different drive.

So I was not able to work with the "default settings" at all, because I had no idea HOW the default settings actually are.


I have a few more questions for you:

Where are the settings stored, how can I reset them and how can I transfer "old" settings from one version to another?

When creating a new effect, is it possible to use the mouse for the first positioning or generally for a "rough" positioning?
Because it is very tedious to always start from point 0,0,0 and approach the final position.

But it may well be that I "overslept" a bit, I don't read every manual from the first to the last page - I have had relatively good experiences with "learning by doing".


Anyway, thank you very much for your help. i hope i didn't take up too much of your time.

PS: The particle effects of the lights (Nav- and position lights) and the afterburner of the tornado are always active, even if the button "Show particle effects" is NOT pressed. Only additional effects like smoke are visible when activated.


Thank you very much for your patience and best wishes from vienna!

 

[bredok]

Prepairing a new world scenery tecnology, also used Modelconverter. what do you think about this projext ?

 

[arno]

Hi,

You have created a lot of setting options. That's a good thing. However, for someone who hasn't developed the program, the problem is that he has no idea what the actual basic settings were if he changed something once or several times.

Yes, you are right about that. On one hand all the options give flexibility, but they might also confuse users. For the new stable release there will be an update to date manual included (I'm writing it now), so that should help.

Here it would be nice if there were a reset button for "dummies" that restores the default values. Or there is another way to start over with the default settings.

In an older version MCX there was such a button. I think I removed it, because it didn't work correct anymore. But I agree that it would be an idea to add such a button back.

Where are the settings stored, how can I reset them and how can I transfer "old" settings from one version to another?

Good that you mention this, I should include this information in the new manual as well. I use a default .NET framework functionality to save the settings. The settings are saved in the folder below. You find a subfolder there for ModelConverterX and in there the actual settings.

C:\Users\{username}\AppData\Local\SceneryDesign.org

The logic was always that for each folder where an application was installed a seperate set of settings was used. So if you installed MCX in a different folder you would get the default settings, while if you installed it in the same folder you kept the old settings. But I have the impression that this logic changed recently and that now the settings are kept over different installation folders as well.

Edit: I just check some .NET documentation and since I signed the MCX files a while ago the settings are indeed no longer depending on the installation folder. So they are shared between different installations of MCX.

When creating a new effect, is it possible to use the mouse for the first positioning or generally for a "rough" positioning?
Because it is very tedious to always start from point 0,0,0 and approach the final position.

Such a feature is on the wishlist, but at the moment not supported. It would be hard to get a good position though, as the pixel you click is actually a line of possible positions in 3D.

PS: The particle effects of the lights (Nav- and position lights) and the afterburner of the tornado are always active, even if the button "Show particle effects" is NOT pressed. Only additional effects like smoke are visible when activated.

Interesting, let me check, that is not what should happen. It might be they are actually spot lights, which have their own button to display. I think the afterburner is actual geometry.

 

[PilotOne]

Good that you mention this, I should include this information in the new manual as well. I use a default .NET framework functionality to save the settings. The settings are saved in the folder below. You find a subfolder there for ModelConverterX and in there the actual settings.

C:\Users\{username}\AppData\Local\SceneryDesign.org

Thanks for the information. I have already found the folder, but i was not sure if it is the "anchored" configuration file.

Edit: I just check some .NET documentation and since I signed the MCX files a while ago the settings are indeed no longer depending on the installation folder. So they are shared between different installations of MCX.

For your information, it might help:
The version DEV 09.01.2020 does not yet access this "new" configuration file.

Such a feature is on the wishlist, but at the moment not supported. It would be hard to get a good position though, as the pixel you click is actually a line of possible positions in 3D.

I don't know how difficult it is to readout a mouse point (mouse click).
Theoretically you should be able to readout this point and transfer it as a starting point. But of course I don't know if and how this can be implemented. You are the expert.

Alternatively, it would make sense to offer the starting point at 0,0,0 and make it editable. So the user could select e.g. 0.00, 0.00, 1.00. From there, make the point "tangible" so that it can be dragged to the desired position with the mouse.
But as I said, you are the expert.

Interesting, let me check, that is not what should happen. It might be they are actually spot lights, which have their own button to display. I think the afterburner is actual geometry.

It's definitely the effects. I tested it on my model, the ILS antenna.

 

[tgibson]

One suggestion for mouse movement is that you would only move in the X and Y view directions of the perpendicular "plane" facing you - you would never move in the Z (forward/back) direction. Thus the "line of possible points in 3D" would never be an issue, since you are only moving in one plane (the current view plane the point is already in). If you wanted to move in the Z plane you would shift the view so that becomes the X or Y view axis.

While this would be most useful using the current default view (rotate the view with the mouse, which would shift the X/Y plane), if this is too difficult it could be used only in the fixed view modes (X, Y, or Z axis view) so the perpendicular view planes would be fixed in each view.

 

[PilotOne]

Hello, Arno,

I'm using your latest version now.

But it seems there is a bug in your "optimizations" in the ObjectModel settings.


If I set all optimizations to "false", the model (in this case the PMDG 737 NGXu) is loaded correctly, all effects are in the right place and the coordinates are correct.
But a correct rotation of the effects is NOT possible.
The model is exported without errors.

If I set all optimizations to "true", the model (in this case the PMDG 737 NGXu) is not loaded correctly, the placement of some effects is wrong.
The coordinates change!

For example, the position values for the green and blue axis change and also the rotation value for the X-axis changes.
However, correct rotation of the effects is possible.
The model is NOT exported without errors, parts are missing.


Basically it is noticeable with complex models that are not self-created (like a payware airplane).
But the same problem also exists with self-created models.
If you switch off the "optimizations", the effects cannot be rotated correctly. Every time you enter one value, another one changes.

But we have already discussed this. Only, to leave all optimizations switched on is not possible with the complex models, because otherwise parts are merged, which should not be so. Therefore these parts are missing after the conversion.


Can you tell me why it is that the coordinate system is obviously changing? I do not think that this is intended. It's just, this "bug" has been around for a long time...

For a better evaluation I will insert these two pictures.
In both variants the model was ONLY loaded and NOTHING(!) was changed.

 

[arno]

Hi,

I know there is a bug that affects changing the rotation. So in general I advice to have to optimizations enabled.

The fact that coordinates are different with the optimization doesn't have to be a bug. It might be that another local origin is used, but the effect still has the same location. Or do you think the location also changed?

What is missing when you export with the optimization on? That might be a bug. But I don't have the payware addon you mention, so I would need a few to reproduce it.

 

[PilotOne]

Hi,

first of all, I think i owe an explanation why I am using this particular model.

PMDG does not use any effects for its lights but only surfaces.
But I want to have light effects, just like with other airplane models.
A change of this state is only possible by an intervention in the model itself. That is exactly what I have done - with good success.

To answer your questions, I will tell you the exact difference. I have also attached pictures.

Variant 1, all optimizations switched on.

In the MCX:

1) the position of the selected effect - in this case "navred" - is displayed incorrectly in the MCX
2) error messages are displayed during conversion.
3) when loading the converted model, it is displayed completely, NO part is missing.

In P3D (version 4.5):

1) the position of the effect (navred) is displayed CORRECT.
2) the horizontal stabilizer is completely missing, the rudder is displayed correctly.
3) ALL effects are displayed active (pre-activated) at the same time, although they are NOT manually activated! They can also NOT be controlled.

For better understanding I have added the EventLog.




Variant 2, all optimizations switched off.

In the MCX:
1) the position of the selected effect - in this case "navred" - is displayed correctly in the MCX.
2) NO error messages are displayed during conversion.
3) when loading the converted model, it is displayed completely, NO part is missing.

In P3D (version 4.5):

1) the position of the effect (navred) is displayed CORRECT.
2) the horizontal stabilizer - inclusive rudder - is completely present.
3) NO effects are displayed, they are NOT pre-activated. They can fully controlled.




As for your last mention, I would have no problem giving you the model.
But I think it is a legal problem, as it would be a violation of the PMDG license.

I hope you can still make sense of the description of the error and the pictures.

 

[PilotOne]

There is, in sum, a series of errors which, in the end, are intertwined and totally falsify the result. That seems to be where we are now.


I believe that a basic bug fix only works in the "raw" mode, i.e. WITHOUT the optimizations. They only falsify the result.
I would think these 3 basic problems in the raw mode have to be solved once:

1) The problem with the rotation.
It is interesting to observe that when creating an effect, the rotation can be adjusted perfectly. However, once the model is converted, it no longer works.
2) The problem with the "exploding model", i.e. only the graphical representation on the user interface crashes. This must work correctly WITHOUT the "optimizations".
3) The problem of attaching an effect to a part of the model that is in close proximity to the effect, completely changing the position of the effect.

Next I would consider whether all these "optimizations" also make sense.
I don't think it is the job of your excellent tool to correct mistakes that users have made when creating a model.

The "flipside" of the coin becomes apparent when, as in my model, the hierarchy is deliberately set up that way and the separation of the individual parts of the model is also deliberately done that way.

In this case, the "optimization" has exactly the opposite effect to what is desired. Parts that should remain separate are joined together. The result is that attachments are then tilted because the selected part for the attachment is then no longer available.

Similarly, parts or nodes that appear superfluous but are actually necessary are removed during optimization.
This manifests itself in the result that parts are missing after the conversion.
Just like I showed you in the last post.

And, if you look at it closely, the whole hierarchy is tilted by the "optimization".
This is exactly why I leave these optimizations out.

I also think that the problems with the "attached" effects, i.e. the position shift, the change of the coordinates after the conversion including the complete change of the original hierarchy is the result of these "optimizations".
Certainly an optimization is not a problem with simple models, but there it does not have such a blatant effect. the inconvenience only begins with more complex models.

But since your excellent tool is to be used here as well, there will probably be no other choice but to return to the root of the "evil". In view of this basic problem, the errors are becoming more and more unmanageable.

I am currently very deeply immersed in the matter and if you like, I can demonstrate to you with an example - in pictures - exactly what happens. As I said, if you like.

I know my words may sound a bit harsh, but it is only the truth. I love this tool, but at the moment it still has some basic bugs. I would like to help you improve it. I also have no problem trying different things and experimenting with the tool.


I have two suggestions for improving your excellent hierarchy editor. This is a result of my work with the tool and all the problems with the model.

I think it's good that you can search and find certain areas. The disadvantage is that they are presented completely out of context.

1) Example: I am looking for the navigation lights. These are also, logically, displayed. But I also need those parts to which these effects are "attached". You need this for example with flex-wings.
these parts are not shown, because they do NOT have the name "navigation" in their name. Therefore they are not found.

But if I leave the navigation light highlighted and delete the search term, I can find the context in the hierarchy tree.

As a "solution" or "improvement", instead of listing the affected parts separately and hiding the rest, it would make sense to mark these parts, in which the search term is contained, only in the existing hierarchy tree - no matter in which color. And, as long as the search term is in the search field, these (multiple) markings must not be deletable.
Then you can see and check the connections - which effect is attached where - in an excellent way.


2) In complex models, the hierarchy tree is very long. It is currently almost impossible to append a newly added effect to an existing part. But that is exactly what you should be able to do with the tool. Which basically works perfectly.

A wish would be an improvement for the text wrap. I.e. if you pull the display field into the width, new columns will be opened. But i don't know if that works.

I have helped myself differently in the meantime.
i have opened 2(!) instances of the editor and placed them side by side.
On the left I placed the hierarchy with the desired part and on the right the search field with the results of the searched effects. Then I dragged the desired effect to the left, into the 2nd instance of the editor, and placed it at the desired part. And, oh wonder, it worked great.


Well, dear Arno, your tool works fine for the most part. It's just that there are some minor flaws that have crept in and which will of course only become noticeable when the software is further developed.
Or if there are such "annoying" users like me.

Please don't take my above statements as a criticism but as a constructive contribution to the improvement of your software. I think this is exactly what you wanted. Otherwise you wouldn't have had to publish your developer versions, nor open this thread here in this forum.

Thank you very much for your effort and your excellent work.

Best regards from vienna.

 

[arno]

Hi,

I don't agree with all your conclusions. MCX can read many different formats and while reading them the resulting scenegraph is not always efficient, just due to the way the various models are set up. Even when reading a MDL object the resulting scenegraph might be different from what is in the MDL, because MCX has to reconstruct it from different bits of information inside the MDL file. So the optimizations are needed to ensure that a consistent object results. Therefore the general advice is to always have all optimizations on. Only in very specific situations you can disable some optimizations (for example when you import from a format that has mulitple parts with the same material and don't want them merged).

If you have parts missing with the optimizations on, it would be interesting to see why that happens. Are they also missing in MCX for example or only in the sim? In the last case it might be good to see if a visibility condition was messed up. There is probably a bug somewhere, but with just some screenshots where a part is missing in sim I can't really reproduce the issue here. So for that I would either need to have a test model to reproduce the issue or some more information on what has changed to the part during export. You might be able to see this in the hierarchy editor.

I have the issue with the rotations on my bug list, but as I explained above working with optimizations on is the default mode. And since it works in that case it does not have very high priority for me to solve it. The exploding object is also gone then, So I think it would be better to solve the missing parts after export with optimizations on.

For the searching, it is a design choice to only show the match nodes, because if they are just highlighted it would still be quite hard to find a node in a complex model. If you clear the search filter they remain highlighted so you can see the context.

I don't think spreading the hierarchy tree in columns would make it easier to read, especially since it is a tree. I assume you want to drag a new effect to a specific parent node? Maybe a kind of copy/cut and paste context menu would be easier for that than dragging it in the tree like it is now.

I'm surprised you can drag nodes between two instances of the tool, I never tried that myself

 

[arno]

Hi,

I had a look at the rotation issue, but it is caused by the attached effect having two transformation matrices. That's a left over from not optimising as well.

I have come to the conclusion that I will remove most of the optimise options, as having does more harm than good. Many of them just have to be mandatory for MCX to work.

 

[PilotOne]

"For the searching, it is a design choice to only show the match nodes, because if they are just highlighted it would still be quite hard to find a node in a complex model. If you clear the search filter they remain highlighted so you can see the context."


In principle it is the same function. It makes no difference whether I leave the part selected, delete the search field and then search for the selection in the hierarchy tree or just highlight the search results in the hierarchy tree.
The result is the same - I see the selection in the hierarchy tree.
But you can surely make "one out of 2 worlds".
Here a search routine, as used by windows, would be a good choice.
Search, find, result list and after marking a result, you can jump directly to this part or attachment in the hierarchy tree after opening a context menu.
It could not be more comfortable, it would be absolutely optimal!

Concerning the "pulling" of nodes, your suggestion to use a context menu here is the best solution. You only have to implement it.

A big praise also to the implementation of the "reset" option in the settings.

Concerning the "optimizations". As far as I remember, these have been there for a long time, but were NOT "pre-activated".
I would not remove them but leave them as option - "inactive". There would also be, as with the added "reset" option, the option to offer a general selection " with improvements" and "without improvements" via 2 buttons in this submenu.

This way, I think, your tool will remain as flexible as possible. Exactly what it already is.

 

[arno]

Hi,

The optimise options have a default value of true for around 10 years already. Since setting them to false only gives problems, it's better to get rid of them.