Where do you keep your textures?

[arno]

Let's be honest, the texture path in ModelConverterX is a bit of a PITA. Adding new entries to it is quite hard and it is always annoying when your textures can not be found.

So I want to see if I can improve this part of the tool a bit. But for that I need to get an impression how you are working with textures while developing. So where do you keep your textures while developing your objects?

When loading a BGL the default entries on the texture path should be enough to find the textures of that BGL. They are either in ..\texture or in the main texture folder. This are two entries that are on the search path by default.

Loading a DAE file should also be fine, since the default location for their textures is a folder with the same name as the model. This folder is on the search path by default as well.

So I guess it are the other cases, like loading a SCASM API or loading a MDL that you are still working on that causes most needs to add entries to the texture path.

Personally I use a structure like this for my projects:

project
- scenery
- source
--- gmax
--- mdl
--- texture
--- xml
- texture

This is working fine since I have ..\..\texture on the default search path as well.

Anyway, long story, my two questions are:

1. Do you often need to add entries to the texture search path? If so, why the default entries not cover your needs?
2. Where do you prefer to keep your texture files while developing?

 

[arno]

Oh, and forgot to mention, looking for textures in the same folder as the object is also something that is done by default already.

 

[mmann]

Hi Arno,

In answer to your questions:

1. I have never had to add entries to the texture search path.

2. When I need to use ModelConverterX my textures are in the same folder as the object.

Regards, Mike Mann

 

[GaryGB]

Hi Arno:

My apologies if I missed seeing a way posted on how to do this somewhere in a prior post or wiki.


I'd like to have some way to save my existing (added) path entries for textures in ModelConverterX (aka "MCX") from one development version so it can be either automatically or manually imported into another newer development version.


Along that same line of thinking (and with perhaps even more importance by virtue of the sheer number of things that one might be forced to otherwise re-set with every MCX development version install), I'd also like to be able to save all the preferred "user settings" for the various options in MCX in some way, so that they also can be automatically or manually imported into another newer development version without having to "do it all over again".


Many thanks for your consideration of this option, and for your wonderfully helpful FS utilities, which just keep getting better with every update and new release !


Regards,

GaryGB

 

[arno]

Hi Gary,

Maybe slightly off-topic from this thread, but let's discuss it here anyway.

The settings should be kept between different development releases. Some time ago I looked how the .NET settings work. They should be kept under two conditions:

• The new application has the same version number
• The new version should be installed in the same folder

Condition 1 is true, since I only update the version with major releases. So it is 1.3 for all development releases now. Condition 2 depends on the user, but if you always install the development release of MCX in the same folder it should be fine.

 

[tgibson]

I don't see anything about aircraft MDL files being loaded; these have textures in a folder as specified by the aircraft.cfg texture= line. I think you already look there? But I don't really remember.

I always keep the textures either in the same folder as the model file (GMAX, etc.) or in a folder with the same name as the object (DAE file). So I have always had textures loaded in the recent versions of MCX.

Hope this helps,

 

[GaryGB]

Thanks, Arno.

I guess I should have responded more specifically to threads main topic first.


Originally with "simple" projects, I kept all original and converted textures in the same folder along with everything else.


But for more recent and complex projects involving multiple versions of 3rd party photorealistic rendered textures (all of which I might wish to keep for possible future use), I'd still need some complex nested folder chains beyond even what your own example above shows.


NOTE: I began using MCX first to "convert" SCASM objects for learning purposes, thus my need to retain multiple texture folder paths for ongoing reference purposes.

This eventually led to my interest in having "pre-sets" of MCX user configuration dialog options for specific purposes with both conversions and newly created content.

And due to variable results with conversion of SCASM objects in much earlier development versions of MCX, I got into the habit of installing each new build of MCX into its own uniquely named folder chain to avoid losing some functions in prior versions that 'previously' worked to get at certain objects.



FYI: I also noted during a cursory inspection that the Dot Net code associated with each new MCX install seemed to put unique entries in my Windows XP Pro system folder chain, so I assumed I was going to lose any configuration info I had saved anyway.


Consequently, I wondered if perhaps it might be feasible to have a discrete external "configuration" *.CFG or "initialization *.INI file implemented with MCX that could be copied / imported from an existing MCX installation into a newer MCX version installation.


BTW: In the context of ideas about yet another way to extend the functionality for MCX... if we had the ability to use batch routines which passed command line parameters etc. in conjunction with command line 'switches' when 'calling' MCX, we could also swap out such a *.CFG or *.INI file.


Witness FSX being given short shrift in all versions, yet ESP in the 12th hour was given the ability to swap between alternate terrain.cfg files and scenery.cfg files; imagine the headaches we could all avoid if the FSX platform had that ability as well !

http://msdn.microsoft.com/en-us/library/cc526948.aspx

""-scenery:path_to_folder"

This switch enables specific scenery and terrain configuration files to apply to a specific run (mission or free flight). The folder specified in the switch should contain a terrain.cfg file and a scenery.cfg file, and must be a writable folder (so that the correct scenery index files can be written to it by ESP). If either of the files is not present in the folder, the folder does not exist or is not writable, then ESP will revert to using the default terrain and scenery configuration files. Note that there should be no trailing "\" in the path (if the example was entered as ESP "-Scenery:C:\Alternate Config Folder\" it would not be parsed correctly).

If this switch is used while the simulation is running, then some unexpected behavior can occur -- the new scenery can be slow to load, and autogen objects can appear to float. One way to correct the floating issue is to select the Scenery Library menu and simply click OK. Changing scenery this way may have some value during development, but should be avoided when deploying a solution.

Use this switch without a path to revert to the default scenery folder. ESP "-Scenery:C:\Alternate Config Folder""


[EDITED]

Due to issues with other software in the past, wherever possible, I prefer to have the ability to maintain and run older versions of applications from "unique install destination paths" ...without being compelled to only use the "latest version" (or worse yet, for 'update' installations being forcibly routed to overwrite local and system folder locations as well as registry strings of an existing install).


Imagine if FSX forced us to over-write any prior FS installs (ex: FS9) so we're "allowed" to only use the 'latest' version !

[END_EDIT]


Hope these ideas prove to be of some interest as you contemplate future features for MCX.

GaryGB

 

[robystar]

C:\temp\project name\GSU jpg
C:\temp\project name\orig photo bmp
C:\temp\project name\MCX\conv dds v1
C:\temp\project name\MCX\MDL v1
C:\temp\project name\MCX\adapted dds v2
C:\temp\project name\MCX\MDL v2
C\.......................................................v3
C\.......................................................v4, etc.
and finally C:\...\...\....\texure
There must be a better way indeed.

 

[hcornea]

I quite like Modelconverter to preview the final dds version of the textures (as a check of sorts)

Project Source
--Max
--Gmax
--Textures
--Model Files and bgl Library (construction area)

FSX Scenery Folder
--Scenery
--Texture

After exporting a model, I like to check it with Modelconverter for any glaring errors (or Texture update / omissions between the source psd and build dds files) For this purpose it is important to me that Modelconverter is using the FSX dds files for rendering.

The library and project is rebuilt using a batch file, which also copies the Library bgl into the FSX scenery folder once it is rebuilt.

A similar file is used to rebikd photoreal textures.

 

[Pyscen]

My textures are keep within the default settings... so no problems here,...

 

[arno]

Hi Gary,

I guess it is related to putting each version in a different folder that you loose the settings. I have been thinking before about this. With the .NET settings I don't have to worry about updates, etc. If I made my own it might be harder to keep it stable with changes. But I also understand that you want old versions to keep working. Let me have another thought about this.

 

[arno]

Hi hcornea,

In what format do you store the source textures? I ussually use psd files. Since MCX can not read those it is forced to read the dds files. But that depends on the user indeed. Let me see if I could force that somehow.

 

[hcornea]

My diffuse textures are in psd files
The lm textures are "distilled" off as bmp files
(same with spec and bump, if used)

I occasionally use tga for transparent textures where I need the alpha channel displayed in Max/Gmax.

Usually the dds files ONLY live in the relevant FSX directory.

 

[vishzu]

Project
- Object A
-- Gmax
-- texture (final FS texture)
-- bmp (for gmax texture)
-- models (.xml+.mdl+.bgl )
-- pictures (with the object)
-- photoshop (final texture in .psd format)
- object B
......

 

[arno]

Hi,

I forgot to mention, for aircraft it is indeed partially implemented now already. But ModelConverterX does not read the aircraft.cfg file, it just scans for folders with the name texture.LIVERY. I think in most cases that should work OK.

 

[GaryGB]

Hi Gary,

I guess it is related to putting each version in a different folder that you loose the settings. I have been thinking before about this. With the .NET settings I don't have to worry about updates, etc. If I made my own it might be harder to keep it stable with changes. But I also understand that you want old versions to keep working. Let me have another thought about this.

Hi again:

Since your wondrous and ongoing innovation now has made MCX capable of output to different versions of MS-FS, and even to "other" non-MS flight simulation platforms, IMHO, this would also result in end users needing to toggle between different types of settings in the MCX parameters depending on what I/O is intended for a given work session... rather than having to manually re-configure them for each project and/or platform change.


Along the same line of thinking above regarding possible swapping between pre-set configurations via batched command line configuration input, perhaps one might also be able to achieve even greater ease of work-flow in MCX if it featured a choice of pre-set (and custom end-user created) configurations via a GUI pick-list (... such as we have for scenery display configurations in the FSX GUI):

http://www.screenshotartist.co.uk/fsx_settings_config.htm


Perhaps one might even have a simpler "mode selection" prompt at start-up like ADE has to 'swap' between FS9 and FSX mode.

PS: I accidentally stumbled upon this info... although I'm a non-programmer, it looked like it 'may' be a pertinent example of implementing "custom configurations" (albeit via a different flavor of Dot Net coding than you might be using).

http://www.mindfiresolutions.com/How-to-Create-Custom-Configuration-Section-in-ASPNet35-267.php

http://joelabrahamsson.com/entry/creating-a-custom-configuration-section-in-net

http://msdn.microsoft.com/en-us/library/2tw134k3.aspx



Hope these ideas might prove helpful in the consideration process for future MCX features !

GaryGB

 

[arno]

Hi Gary,

I will keep those things in mind. For sure the current way of storing the settings should be made better, so I am going to spend some effort on that later.

Another thing I have been thinking about is to put the settings closer to the tools. So that you can choose them on the form where you need them, instead of hidden in the options.

 

[lordofwings]

I don't know if it is possible but the only limitation I have found is that sometimes I need to "rework" the model with MCX and it seems I have to re-rename all the textures again. I am not sure if the "Match" option does that for me.

My project structure is as follows (it is a template I use over and over):;

-project_id (<2_letter-ISO-country_code>-<ICAO>
--Docs
--Reference
--FSX KML
---Backup
---Generated
--FSX Planner
---Generated
----scenery
----texture
--FSX SBuilderX
---PolyTextures
--Sketchup Models
---Library
----scenery
----texture
---Model-n
----FSX
-----scenery
-----texture


Though I am looking at ways to restructure it before adding the whole thing to source control.

Great tool, I can now do what I always wanted to do: make my custom FSX buildings.

 

[arno]

Hi,

When you import a model from SketchUp again it will indeed have the old names again, so they need to be renamed again.

The Match function was designed to detect the textures that are the same, but have a different name. So in some situations that will work.

If you also minimized drawcalls it won't work usually. In that case the only option to do perform all those steps again.