Build 31/01/2009

[BASys]

Hi Folks

Arno -
Cheers for latest, (31/01/2009).

Materials with transparency
Are occluding objects beyond.
e.g.
EH101 external model
rotor disc occludes some other parts.
Occurs on other models.
Following may provide a clue -
Try default Robinson external model.
Note the behaviour of the right door.

Texture loading
Majority are failing to load,
even though paths are correct.

Appears to be an intermittent issue.
Loading something else,
then returning to original model
sometimes loads some textures.
Never loads all.

Animations
Animation frame state persists across model loads.
When loading another model.
Can you ensure animation frame is reset to zero.

HTH
ATB
Paul

[arno]

Hi Paul,

Materials with transparency
Are occluding objects beyond.
e.g.
EH101 external model
rotor disc occludes some other parts.
Occurs on other models.
Following may provide a clue -
Try default Robinson external model.
Note the behaviour of the right door.

Yes, that is an issue with the preview. I will put it on the list, but some other more functional things have higher priority at the moment. It is only a visual thing, it does not affect the exporting.

Texture loading
Majority are failing to load,
even though paths are correct.

Appears to be an intermittent issue.
Loading something else,
then returning to original model
sometimes loads some textures.
Never loads all.

Does it depend on the texture type (DDS, BMP, etc)? I have not noticed this problem here. Any clues on how to reproduce it will help me finding the issue.

Animations
Animation frame state persists across model loads.
When loading another model.
Can you ensure animation frame is reset to zero.

Done, will be in this nights build.

[BASys]

Hi Folks

Arno -
Texture loading & transparency
were both working ok previously.

AFAIK both were ok in 25/01/2009 build.
but not working in 31/01/2009 build.

I'll wait till tonights build is released.

HTH
ATB
Paul

[arno]

Hi Paul,

Texture loading & transparency
were both working ok previously.

AFAIK both were ok in 25/01/2009 build.
but not working in 31/01/2009 build.

OK, I will compare with that old version later (won't be today). Hopefully I can reproduce things. For sure texture loading has no problems here, but transparency seems the same.

[Ayrsimming]

Hi Arno

I can confirm no texture loading problems with your latest at this end.

Iain

[arno]

Paul, do you still have texture loading problems or can I close this issue on my list?

[BASys]

Hi Folks

re: Materials with transparency
Arno & Iain -

Are you saying -
You've inspected the external models for -
- EH101
- B206
- R22

and
that you are seeing
no occlusion transparency issues
when viewing downwards through the rotors
on those models ?



Arno -
Just re-confirmed with 17/02/2009 build -

In game - my textures work fine.

In MDX - they display one sided, (as exp prev).



Also as previously raised,
my supplied SPT model
is still displaying this same issue.

Please use that as a test,
as you can't get much simpler a check.



Just realised
re: the rotor textures,
some of mine are DXT5,
defaults were 32bit (unassigned).

On the SPT,
they're all DXT3.



EDIT
Further clue
The static parts are occluded.
The animated parts are the only ones to remain visible.


HTH
ATB
Paul

[BASys]

Hi Folks

re: Texture Loading
Normal import, via Import/Open folder-dialog box,
works ok.



Traced reported Texture Loading failure
specifically to -
any import from MRU list, (excepting curr dir),
fails to load textures.
It's still occuring.



HTH
ATB
Paul

[BASys]

Hi Folks

re: Animations
Arno -
Animations are now reset to zero point,
on loading a new model.

Can you also please ensure they're stopped. :)


EH101 doors are still animating wrongly.

They're sliding on vertical axis,
rather than longitudunal.



HTH
ATB
Paul

[arno]

Hi Paul,

Animations are now reset to zero point,
on loading a new model.

Can you also please ensure they're stopped. :)

Done.

EH101 doors are still animating wrongly.

They're sliding on vertical axis,
rather than longitudunal.

Yes, I see that as well. But at the moment I don't understand why and it is the only object with such problems. So I have put this on my todo list, but I will address this issue after the release of version 1.0.

[arno]

Hi Paul,

Traced reported Texture Loading failure specifically to - any import from MRU list, (excepting curr dir), fails to load textures. It's still occuring.

Thanks for the clarification. I will see if I can figure out what is going on there, although I can't reproduce the problem here. My objects from the MRU list load fine.

[arno]

Hi Paul,

Are you saying -
You've inspected the external models for -
- EH101
- B206
- R22

and
that you are seeing
no occlusion transparency issues
when viewing downwards through the rotors
on those models ?

No, I am not saying that. I do see these problems on some objects as well. It is related to drawing order for transparent object. Currently the preview does not do anything special to prevent it. I will check if this can be easily solved, but if not I will delay this issue till after the version 1.0 release. It is mainly a cosmetic issue in the preview and I want to get the next version released soon as it contains a lot of improvements.

Just re-confirmed with 17/02/2009 build -
In game - my textures work fine.
In MDX - they display one sided, (as exp prev).

Also as previously raised,
my supplied SPT model
is still displaying this same issue.

Please use that as a test,
as you can't get much simpler a check.

OK, will try to find that one back. Double sided objects should be working OK.

[arno]

Hi Paul,

Please use that as a test,
as you can't get much simpler a check.

I found back the object. Just to be sure we are talking about the same: the double sided is working fine for this object. But from some angles there is a drawing order problem so that you do not see polygons behind a transparent one.

[BASys]

the double sided is working fine for this object.
But from some angles there is a drawing order problem
so that you do not see polygons behind a transparent one.
Correct. :)

ATB
Paul

[arno]

It seems there is no easy way to fix this now. I have to read the alpha test values from the FSX material and use that while rendering I think. I have put it on my todo list, but that will be for version 2.0 as well.

[arno]

Hi Paul,

I had another look at the texture loading problem, but I can't reproduce it in any way. I loaded a bunch of objects from different folders and then flipped through them using the MRU list. But the textures always load fine here.

Could it be related to the trouble with the texture path settings you reported before? Did you extend the texture path with anything special?

[BASys]

Hi Folks

Arno -
Apologies for delay.
Parental visit ongoing. :D
Thermal BSOD caused loss of original post content,



re: alpha test
I'll need to check/confirm again in-game.

But if the SPT alpha-test is rendering OK in-game,
then MCX must behave similarly.

Otherwise
users will end up chasing their own tails,
trying to fix non-existent issues.



re: texture loading problem -
The issues I'd reported previously
have all occured whilst accessing
FSX default & Acceleration simobjects.
e.g.
B206 or EH101 models.



The Texture Search Path Editor -
were all valid entries as per -
..\Texture
..\..\..\..\Texture
..\..\..\..\Scenery\Global\Texture

i.e.
Load initial model - Textures display ok.
Load subsequent model - Textures fail to load.

i.e.
Relative texture-paths
are not being updated before new model is loaded.



PS
As reported prev,
in the MCX Texture Search Path Editor -
Editing these values,
still regularly drops the first entry,
(even though it is valid).
Will need to investigate further.

Requires up/down prioritisation-control arrow buttons.



Related -
Specular texture appears to have prioritised display over diffuse.



Outstanding / Unrelated -
VC/Cockpit Models -
Report texture load failures for any VC based $ textures.



Event Log -
Rather than save entire file,
then select & copy requiired single line,
please can we select & copy a single entry ?



Interface -

Status bar -
Minor issue.
Think of running MCX fullscreen on a hi-res monitor, ( => 1600x1200).

Bottom left indicates importing state.
Bottom right indicates percentage complete.

Once complete -
Bottom left is empty.
Bottom right indicates any Errors arising from import.

Can error warning be bottom left please ?



Options -
Currently accessed from tab mechanism
located alongside output related tabs for -
3D Preview & Event Log.

Can Options be made available from a logical button location -
i.e.
Alongside the Import, Export, Batch Convert, Special Tools, buttons.



Manual -
I use Firefox as my primary browser,
but retain IE as my default browser, (only for automatic-updates compatibility etc.).

Currently the MCX Manual/Help info launches in an interface-less/restricted function, user's 'default browser' window.

In MCX Options,
can you please add a user-browser select option,
so that MCX Help can be opened in a fully-functional user-selected browser ?



Initial Display Location -
Some models are not initially located central to view-window.
e.g EH101

i.e. Model origin to be displayed at window central position.



Mouse button behaviours -
Please make behaviour consistent with actions, (or user-option configurable)..

Should be -
Scroll Forward == Zoom in
Scroll Backwards == Zoom Out.



Many thanks.

HTH
ATB
Paul

[arno]

Hi Paul,

Apologies for delay.
Parental visit ongoing. :D
Thermal BSOD caused loss of original post content,

No problem, thanks for the detailed reply again. Those details will certainly make it easier for me to improve the tool. You can be sure that I will put all the issues in my bug tracker, so that I won't forget any.

But I don't think I will fix them all before the next public release. It is too long since the last release and the current beta version has enough improvements to have a next release.

But if the SPT alpha-test is rendering OK in-game, then MCX must behave similarly.

Otherwise users will end up chasing their own tails, trying to fix non-existent issues.

I agree on the long run. I will certainly try to fix this, but as it involves quite some changes I will do it after the next release. I will add in the manual a note about transparency not being correct in the preview.

The issues I'd reported previously have all occured whilst accessing FSX default & Acceleration simobjects.
e.g. B206 or EH101 models.

I also used default objects to test, let me try again to see if I can reproduce it. It indeed indicates some trouble with the path of the current object if relative paths do not work OK.

in the MCX Texture Search Path Editor - Editing these values, still regularly drops the first entry, (even though it is valid).
Will need to investigate further.

Requires up/down prioritisation-control arrow buttons.

I'll try to reproduce it again as well.

Specular texture appears to have prioritised display over diffuse.

Is this a problem in the preview or after exporting the objects to FS? I do not think the specular texture is used at all in the preview currently, but I'll check.

VC/Cockpit Models -
Report texture load failures for any VC based $ textures.

I assume you expect no message for them? They are the way to assign a gauge to a VC, but of course ModelConverterX can/will not read gauge files.

Event Log -
Rather than save entire file,
then select & copy requiired single line,
please can we select & copy a single entry ?

I'll put it on the wishlist.

Status bar -
Minor issue.

Think of running MCX fullscreen on a hi-res monitor, ( => 1600x1200).

Bottom left indicates importing state.
Bottom right indicates percentage complete.

Once complete -
Bottom left is empty.
Bottom right indicates any Errors arising from import.

Can error warning be bottom left please ?

I guess from human factors point of view that would make sense :).

Options -
Currently accessed from tab mechanism
located alongside output related tabs for -
3D Preview & Event Log.

Can Options be made available from a logical button location -
i.e.
Alongside the Import, Export, Batch Convert, Special Tools, buttons.

Let me think about it. At the moment the tab is the way to control what is displayed on the main area of the form. With the menu and buttons only additional forms and functions are loaded. It would require some change to put the options in there. What might work is putting it in a menu besides the tab.

Currently the MCX Manual/Help info launches in an interface-less/restricted function, user's 'default browser' window.

No, it's not. It is used the .NET web browser control. So it does not depend on any user setting. It was my choice now to not use the default browser and have a manual inside the tool.

Some models are not initially located central to view-window.
e.g EH101

i.e. Model origin to be displayed at window central position.

I have noticed this as well. I will check the bounding box calculation as that seems wrong for those models.

Mouse button behaviours -
Please make behaviour consistent with actions, (or user-option configurable)..

Should be -
Scroll Forward == Zoom in
Scroll Backwards == Zoom Out.

It is indeed the reverse from GMax or Google Earth at the moment. I think it must be similar to some tool I use at work or so as it made sense to me :). I'll think I'll reverse it.

[arno]

Hi,

Coming back to the texture loading and texture path editing problems. I tried again to reproduce both and failed on both. I have a feeling that the issues might be related (for example because the search path is corrupted or so the loading also fails sometimes).

Internally the texture path is stored as one big string, the semicolon is used as a separator for the different entries. By accident you did not use it in one of the paths as well?

[BASys]

Hi Folks

Arno -
The above texture paths,
were copied & pasted directly from within MCX.

When I initially load up the B206 model in MCX, (first model),
it should display the default white Bell_206B_T.dds texture.

MCX loads up a grey/green textured B206, (see screenie).
which I'd assumed was the specular bell_206b_t_spec.dds texture.

I know MCX is initialy reading the correct folder,
as I'd included a dummy purple decal_nnumber.dds texture
which displays in the MCX preview.

Tried the save preview image,
and it just turned out as black.



Just looked at the MCX material editor,
and it contains the following entries for Bell_206B_T.dds -
ambient = 70, 68, 63
diffuse = 70, 68, 63
emissive = 0, 0, 0
specular = 163, 163, 161

AFAIK I've never changed any of these settings.



If I then load up the EH101
it displays ok.

If I then reload the B206 from the MRU list,
it then fails to load any textures.

NOTE
If I then go to save the event log,
it's still pointing at the EH101 folder.

So it looks like MCX
isn't updating the texture relative path
when accessing a MRU listed item.



Where in the registry are you storing the MCX settings please ?



EDIT
Here's the MRU accessed B206 event log's content -
22:23 MDLXReader Information Starting reading of file G:\Program Files\Microsoft Games\Microsoft Flight Simulator X\SimObjects\Rotorcraft\Bell206B\Model\Bell_206B.m dl
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Warning Unsupported RIFF section: XAPS
22:23 MDLXReader Information Finished reading objects
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_X_C.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_6.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_2.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_3.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_4.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_5.DDS
22:23 Renderer Warning Failed to load texture: PROP_BELL_206_6.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS
22:23 Renderer Warning Failed to load texture: BELL_PILOT.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS
22:23 Renderer Warning Failed to load texture: DECAL_NNUMBER.DDS
22:23 Renderer Warning Failed to load texture: BELL_206B_T.DDS



HTH
ATB
Paul

[arno]

Hi Paul,

When I initially load up the B206 model in MCX, (first model),
it should display the default white Bell_206B_T.dds texture.

MCX loads up a grey/green textured B206, (see screenie).
which I'd assumed was the specular bell_206b_t_spec.dds texture.

I think it is still the normal diffuse texture, but it probably appears darker because of a problem with the lighting in the preview and/or mixing the color and the texture.

If I then load up the EH101
it displays ok.

If I then reload the B206 from the MRU list,
it then fails to load any textures.

I did exactly what you describe, but I can not reproduce the problem here. All textures load fine. I would suggest that you remove the configuration files as a test and start with all default settings.

Where in the registry are you storing the MCX settings please ?

They are not in the registry, but stored in the following folder:

Documents and Settings\{user}\Local Settings\SceneryDesign.org

You find multiple subfolders there for the tool. It is how the .NET frameworks saves the settings, I still have to figure out how all the files relate to each other.

[BASys]

Hi Folks

Arno -
Cheers for interface changes.

I've since removed all previous components and user.config,
and installed tonights build, (ModelConverterX.exe 24/02/2009).



Still having same MRU accessed texture loading failures.

Further confirmed
MCX is still pointing at last imported aircraft folder location.

I've attached the latest user.config as - BASys_user.xml

Running on XP Pro SP3.



Settings / Paths
I guess this might need an installer to accomplish -

Rather than writing incorrect values,
how about reading the user's reg entries
for FSX and the FSX SDK ?

FSX reg entry -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\flight simulator\10.0
SetupPath=WHATEVER
FSX SDK reg entry -
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft Games\Flight Simulator X SDK
SdkRootdir=WHATEVER



Both the following entries also contain spelling errors -
c:\program files\microsoft games\microsoft flight simulator x sdk\sdk\environmet kit\modelling sdk\FSX_GmaxGamePack\plugins\xtomdl.exe
c:\program files\microsoft games\microsoft flight simulator x sdk\sdk\environmet kit\modelling sdk\bin\modeldef.xml
Should contain -
An n in environment
Single l in modeling.
i.e.
Environment Kit\Modeling SDK\





HTH
ATB
Paul

[arno]

Hi Paul,

Further confirmed MCX is still pointing at last imported aircraft folder location.

I've attached the latest user.config as - BASys_user.xml

You mean from the user.config file you can confirm that it is not being updated? I check the source code and the value should really be updated before the actual reading starts. I'll double check again.

Settings / Paths
I guess this might need an installer to accomplish -

Rather than writing incorrect values,
how about reading the user's reg entries
for FSX and the FSX SDK ?

If possible I will not use an installer. Reading the registry is a good idea, I'll do that.

Both the following entries also contain spelling errors -
c:\program files\microsoft games\microsoft flight simulator x sdk\sdk\environmet kit\modelling sdk\FSX_GmaxGamePack\plugins\xtomdl.exe
c:\program files\microsoft games\microsoft flight simulator x sdk\sdk\environmet kit\modelling sdk\bin\modeldef.xml
Should contain -
An n in environment
Single l in modeling.
i.e.
Environment Kit\Modeling SDK\

I'll also fix those, in case a user has some registry problems there should still be sensible default values. I don't have the SDK installed in the default location on my PC, that's why I never noticed.

[BASys]

Hi Folks

Arno -
No, the user.config is being updated. :D

Further info -
Opening an MCX session,
then reading any model from the MRU list,
all items load their textures correctly.

However -
Now Import a model.
Loads ok.

Now try to access a model from the MRU list.
All fail to load the appropriate textures,
EXCEPT that last model you'd imported.

Looks like MCX is not re-reading the relative path
AFTER the MRU is selected, (before attempting to render it).

HTH
ATB
Paul

[gsnde]

Paul,

I have replicated your steps several times with several objects, but it never failed to work for me. :confused: Do you have the chance to test the same on another computer?

Arno,
while testing Pauls steps I noticed that the Arrestor object has stopped to work and causes a real error with dialog box.

I attach it here.

This is the error message:

An error occured during importing the selected file

Message:
Der Objektverweis wurde nicht auf eine Objektinstanz festgelegt.

StackTrace:
bei ModelConverterX.SCASMReader.ReadSCASMFile(String filename)
bei ModelConverterX.SCASMReader.Read(String filename)
bei ModelConverterX.ObjectReader.read(String fileName)
bei ModelConverterX.MainWindow.bwImporter_DoWork(Objec t sender, DoWorkEventArgs e)

[BASys]

Hi Folks

Martin -
Error occurs when loading
FSX default aircraft .mdl files,
from their native locations.

HTH
ATB
Paul

[gsnde]

Paul,

I only tested APIs in addition because it does not make necessarily sense that such an error would occur only with model files.

1. Populate the MRU:

start ModelConverterX
load the B737_800 directly
load the b747_400 directly
load the beech_baron_58 directly
exit ModelConverterX (all textures loaded fine)

2. Test your scenario

start ModelConverterX
load the beech_baron_58 from the MRU
load the beech_King_Air_350 directly
load the b747_400 from the MRU
load the B737_800 from the MRU
exit ModelConverterX (all textures loaded fine)

Does this reflect what you are doing?

[arno]

Hi Martin,

I found the bug with your API, has been fixed now. The error dialog is because I build the release candidate in Release and not in Debug mode. Then I have this dialog to catch any error.

[arno]

Hi Paul,

I double checked the code again, but the same function is used for loading any object. If you select it from the file dialog or from the MRU list. In any case the last accessed file is updated in the settings before starting to load it. This setting is then used in the preview when loading the textures.

[gsnde]

Hi Martin,

I found the bug with your API, has been fixed now. The error dialog is because I build the release candidate in Release and not in Debug mode. Then I have this dialog to catch any error.

Thank you :)

[BASys]

Hi Folks

Martin -
Your scenario matches what I'm doing.
Still fails for me as I'd previously described.

I'll try to test on another machine this weekend.



Arno -
I'm surprised I'm seeing MCX respond differently to yourself & Martin.

My system is fully uptodate with all patches.

It may be the same underlying code,
but accessing via the Import file dialog,
forces a CD to chosen location.

When accessing via the MRU list,
is MCX explicitly CD'ing to the specific folder
before attempting to load the model,
or is it reading a relative path ?

Seen similar behaviour when working with paths in batch files.



One thing to note.

Previous builds -
On accessing an MRU item,
then clicking on the import button
dialog displayed the folder of the previously loaded item.

Latest Build -
On accessing an MRU item,
then clicking on the import button
dialog now displays the folder of the current loaded item.
Still doesn't load the textures for me. :D



Wiki Doc -
FSX MDL reader -
Needs list of unsupported RIFF sections.
e.g. XAPC, XAPS, etc.

Also a link to the MDL file format (FSX) page,
again to include lising of the unsupported RIFF sections.



HTH
ATB
Paul

[gsnde]

The setup here is like:

Vista32 patched to the teeth :rolleyes:
ModelConverterX located on C: (C:\MSFS\FS Design Tools\ModelConverterX)
FSX located on Z: (Z:\Microsoft Games\Flight Simulator X)

[BASys]

Hi Folks

Cheers Martin.

Arno -
Are you on Vista also ?

ATB
Paul

[arno]

Hi Paul,

Arno -
I'm surprised I'm seeing MCX respond differently to yourself & Martin.

Me too, but I am convinced we'll figure out in the end why.

When accessing via the MRU list,
is MCX explicitly CD'ing to the specific folder
before attempting to load the model,
or is it reading a relative path ?

No CD is issued in any case. The config stores the last used file. Using the paths stored in the preferences there is a function that tries to find a given texture file by looking in all paths. What is returned in the end is a full path to the file (if found) that is used for loading.

It can only go wrong if the config file is not updated correctly, but I explicitly did that before starting to load the object itself. After that loading the preview is updated, where the textures are loaded.

Latest Build -
On accessing an MRU item,
then clicking on the import button
dialog now displays the folder of the current loaded item.
Still doesn't load the textures for me. :D

That's what it should do, as it is the last loaded object. Did you try the version 1.0 I just released already?

Wiki Doc -
FSX MDL reader -
Needs list of unsupported RIFF sections.
e.g. XAPC, XAPS, etc.

I don't agree. The whole documentation talks about functions that are supported. Any function not listed is not supported. I also don't have a list of the unsupported SCASM commands there. For most users that would make 0% sense anyway.

[arno]

Oh, and yes I am also using Vista. I can try later at work where I have a WinXP machine. But I did not notice problems there until now.

[arno]

Maybe some other user, who uses WinXP, can see if he can reproduce Paul's problem on his machine? That might help to see if it is a XP vs. Vista problem or something else.