FSC via 3ds to SU

[robystar]

Hi,

I am facing the problem of having inherited a rather complicated FSC scenery object that has to be further worked on. I do not have FSDS and do not intend to use it either for this kind of inanimate scenery as SKetchup is much easier.
However, upon converting the fsc file with MCX to a 3ds format for importing in SU, I lose the applied textures.
Any inkling how this can be avoided?

Thanks,

 

[=rk=]

Roby you have to pick up the textures in MCX and export them to a format SketchUp reads, then it usually works fine. Pretty sure both .bmp and .DDS are out but .jpg and even layered .PSD's will import.

 

[arno]

Another issue might be that the 3ds format only saves 8 characters of the texture name.

Does SketchUp not read Wavefront OBJ as well? That might work better.

 

[=rk=]

SketchUp actually supports very few file formats. Native .skp, .3ds, .dem (whatever that is) .DAE and the associated embedded .dae plus placement as .kmz. Within the MCX interface one can define textures explicitly, you can rename and reformat and as long as the mapping is intact and they are compatible they will import into SU.

 

[robystar]

Hi,

I have an obj exporter for SketchUp but not an importer.

 

[arno]

I have a COLLADA exporter on the wishlist. That would make things easier in the future. But for now 3ds is probably the only option then.

 

[=rk=]

Hi,

I have an obj exporter for SketchUp but not an importer.

With extensions's your options go up dramatically, about the only format not supported is .max. The downside is that I bet your extension used to import .obj, I think I have the same one, they expire and they don't seem to be cheap.

 

[GaryGB]

Hi Roby:

After a copy of the source *.FSC model and all mapped textures is placed into a single 'work' folder location, then imported into MCX with all mapped textures displayed in MCX 3D Preview mode as desired:

1.) Material Editor > Textures tab

a.) Set the texture output path to that same 'work' folder location where MCX is going to write the converted textures

b.) select and Convert mapped texture files with the following criteria applied:

* Powers of 2

* File format for texture Material supported by Sketchup: ex: PSD, BMP, PNG, TIF, TGA, ...or JPG

* Over-write existing textures

NOTE: IMHO JPG is not recommended unless JPEG compression is disabled by any graphical editor subsequently used in Sketchup to edit such textures (...otherwise image will degrade with each saved edit to the JPG image).

If the 3D model mapped texture size is an issue with an adverse impact system resources for the Sketchup and/or (eventual) MSFS task session, PNG textures can be utilized, and when saved / edited / re-saved ...only 'loss-less' compression will be applied to the image.

However, IMHO, TIF with LZW 'loss-less' compression is a better option as it allows multiple layers and Alpha channels to be used for easier editing via a more commonly-utilized method for configuring transparency via Alpha channels.

IMO this is preferable rather than dealing with the multiple optional ways the PNG format allows coding transparency, not all of which may always be accessible by all graphical editors, and when accessible, the syntax used for the transparency coding methods and parameters varies between those graphical editors that can work with PNG files.

c.) close MCX Material Editor


2.) MCX Menu > Export Object > choose desired export format (ex: 3DS or Wavefront OBJ)

3.) Export the 3D model to that same 'work' folder location where MCX wrote the converted textures


FYI: This allows the textures mapped onto the 3D model to be found and read during import by ex: Sketchup, GMAX, 3DSMAX, Blender (or MCX without manually adding the folder location to the existing default MCX texture search path) because the texture location may be internally coded by MCX into certain 3D model import / export file formats.


BTW: There are free plugin Ruby scripts for Sketchup that are actually more capable than the default importers /exporters.

Assuming you are using the faster and (last) free version 8, 32-bit version of Sketchup which does not require a license when used for either freeware or payware production, you can more easily install such Ruby plugin scripts (aka "extensions") via :

thomthom: Simple Plugin Installer v1.2.0

http://sketchucation.com/pluginstore?pln=tt_simple_installer


Once the above plugin is installed, and Sketchup is re-started, one can install other plugins via:

Sketchup Menu > Window > Preferences > Extensions > [Install Extension] button



BTW: If you wish to test your *.FSC 3D model MCX export via OBJ, consider installing this free plugin for Sketchup:

TIG: Import OBJ with Materials v2.2:

http://sketchucation.com/pluginstore?pln=obj_importer


The above instructions may suffice to get your MCX 3D model conversion into Sketchup; feel free to inquire further if you require further suggestions.

GaryGB

 

[=rk=]

I went ahead and downloaded the .obj importer linked above and made some screen captures of my results. The model I used was of the Summit Museum on Mt Diablo in Clayton Ca. I made it using a combination of tiled and projected textures with SketchUp 2015 as an enhancement of the ORBX scenery covering the area and tested it in P3D V3.2. Here is a picture of the default avatar contemplating the view towards San Francisco. Curiously, this avatar is able to negotiate steps:

Here is how the model appears in MCX, the parking lot is a separate model. For texture mapping, the seamed roof and mortared stone are tiled, everything else including the separate parking lot model are mapped from a single texture:

Here is the model in SketchUp after being exported using the extension linked above:

Clearly there are scaling issues and while these might be rectified by arbitrarily selecting (or somehow knowing) the correct units to assign, there is the matter of missing textures and texture mapping that is completely lost or distorted as along the long flight of stairs. Some of the tiled textures are lost while some are preserved and some of the projected texture is lost or distorted. Additionally there are several planes that have been duplicated around the windows which are very obvious when changing perspective slightly, they are visible in the image as default texture, the condition is actually present around all the windows at that level.

Here is a basic .3ds import taken from the MCX export of the model. It was saved to the same parent folder as the .obj version and the .jpg format textures:

There is no scaling discrepancy, indeed there is no dialog from which to select a different unit scale. Also the textures are much more perfectly mapped. There is still a matter of duplicated planes around the windows but it is much less pronounced. You can see I used textures that were partially transparent and that mapping was lost in both export/import procedures.

Based on my previous experience with the .obj format which was only re-enforced with these most recent experiments, I can't see why it would be recommended, especially in light of the relatively simple procedure of using MCX .3ds export. Gary, do you actually test these things you link to? Is there some procedure or detail I have overlooked with this .obj importer?

 

[GaryGB]

Hi Rick:

As with all software (particularly when it is intended to import 3D models into Sketchup), results may vary due to many factors, some of which are explained in the accompanying documentation for the above linked plugin, and most of which have to do with the settings used for both the conversion script as well as Sketchup itself when 3D models are imported.

Did you read the documentation for that software before you used it ?


BTW: Although you stated:

http://www.fsdeveloper.com/forum/threads/fsc-via-3ds-to-su.437496/#post-746003

Here is the model in SketchUp after being exported using the extension linked above:

...because the extension I linked to above is actually an importer, IIUC, perhaps instead you may have intended to describe the following work-flow for your model:

1.) Created it in Sketchup

2.) Imported it into MCX (which has its own settings and procedures for how it processes a 3D model)

3.) Exported it from MCX (which has its own settings and procedures for how it processes a 3D model)

4.) Imported to Sketchup via above plugin (which has its own settings and procedures for how it processes a 3D model)

5.) Rendered on screen via Sketchup (which has its own settings and procedures for how it processes a 3D model)


If one has access to the source file for a 3D model, one can analyze the model and detect factors resulting from how the model was created.

One might even clean the model up prior to attempting to convert that 3D model for use in yet another software application.


If you would be willing to post your 3D model depicted above as a downloadable attachment to this thread, I would be glad to process it via 1 or more Ruby plugin scripts for Sketchup which can analyze your 3D model for factors resulting from how the model was created, and which may impact how software intended to convert 3D models may have been influenced by the 3D model itself (independent from factors involving additional individual settings and procedures for how 3D file conversion or modeling software processes a particular 3D model).


I believe that making your 3D model shown above available for further analysis might help allow a more appropriate evaluation of the capabilities of the above linked OBJ import plugin for Sketchup (...which I have tested, but for which I make no claims other than that script being authored and meticulously vetted by a brilliant University instructor in architecture and CAD having extensive experience with multiple CAD software packages and related LISP, Java, and Ruby programming, in addition to also being a consultant to the Sketchup development team).

http://www.revitrev.org/HomePage/who


Like the default Sketchup 3DS importer, the above linked OBJ import plugin for Sketchup has its own pros and cons, not the least of which is the pervasive triangulation ...unlike the "cleaner" 3D model imports that can be achieved via Collada DAE files.

The subsequent extra steps one may be compelled to perform on either 3DS or OBJ imports to Sketchup to clean and remove undesirable areas of triangulation to form as many quad faces as possible with yet other plugin scripts, IMHO, certainly underscores and "reinforces" the need for Arno or a 3rd party to provide a Collada DEA (...as well as Google Earth KMZ compliant ? ) exporter for FS Developers who utilize Sketchup for creation and editing of 3D model add-on content requiring inter-conversion by MCX.


Alternatively, if Arno were to clarify whether the DirectX *.X file that MCX outputs can be read- and a 3D model inter-converted fully intact- when converted by a 3rd party utility (and not by MCX itself), perhaps this may prove to be an alternative work-flow ...until such time as Arno is able to provide a Collada DAE export function in MCX.

GaryGB

 

[robystar]

Hi,

Thanks for all the explanations and all the trouble you went through to test some stuff.
I am away from home till thursday so I cannot do any testing for the moment.
Just wanted to clear up some things.
I do have the source folder but it is an FSDS one (.fsc), that I load into MCX and convert to 3DS. Thanks to your explaining that when textures are converted first (in MCX) to formats recognized by SU, I can now (well, i.e. thursday) see for myself whether the mapping is preserved in this model or not. That would help a lot already. The abundant triangulation is another PITA but OK, be that as it is. It is just more work.
By the way, apart from the possible texture mapping problems, I also noted that the 3ds converted and in SU imported models in some cases have some weird artifacts like as if the conversion was not 100% successful.
Will be back with more news from my side as soon as I have it.
Cheers,

 

[=rk=]

Understood Roby. In my experience the artifacts you describe are fairly superficial, relatively speaking and are a consequence of discrepancies in the data format translation. The procedure does ultimately give access to the model geometry.

Gary, to be honest, I didn't read through most of your most recent post. I stopped at "importer," not sure why you highlighted it. I wrote that I made my model. I exported it from MCX as .3ds and as .obj using MCX. I used native SU importer .3ds and the .obj importer you linked. We were trying to tell Roby how to get a FSDS model into SketchUp, do you remember? Why would you assume I used your tool as an exporter and why do you write so much? The question is rhetorical, as if to say it's like a novel. I try to be as concise as possible, because I know I am boring and people want to get to the facts. I worry I miss facts scanning through all those paragraphs you write.

Also, thanks, but I don't need the model analyzed. It works perfectly from conception, through editing and compiled into .bgl. Did not the avatar look content while enjoying it? The model even worked well enough to explore the practicality of using it to demonstrate .3ds export from MCX. Why would I want need to read the documentation of a buggy importer that is an alternative to the my proven and trusted work flow - assuming of course I ever even need to decompile a .mdl without the source code. Anyone reading can have the placed scenery files, I got married about 2 miles from this building in 1990. It is also available at Avsim under my name.

Finally in regard to continued requests about MCX exports. I believe MCX works very well as it is and does not need to be stretched any further past it's original design goals. Model Converter X was written, in my understanding, to consolidate procedures, to simplify working with the ACES toolset and give authors more freedom of expression. Originally Arno would not allow MCX to decompile anything, wisely - and many posts were made about guns and users to convince him otherwise. Now the analogy is - to me, "sorry Arno, this .277 is a great hunting gun, but I need something more .357ish just to survive as an artist." Personally I do not believe decompiling models need be that high a priority and if I were to ask, I would have a really good reason beside it being something I felt like Arno should do. Like this:

work-flow ...until such time as Arno is able to provide a Collada DAE export function in MCX.

GaryGB

Just what kind of operation do you propose that involves a work-flow of converting models from a format you do not have access to into a format which you do have access to?

 

[GaryGB]

Hi Roby:

You are certainly not alone in having reported issues with importing 3DS files into Sketchup with default or 3rd party converters:

https://www.google.com/#q=Sketchup+3DS+import


BTW: If you have not yet read it, Sketchup's documentation on the default 3DS import feature is here:

https://help.sketchup.com/en/article/3000169-0

GaryGB

 

[robystar]

Thanks, Gary. I had not read it.
Interesting.

 

[=rk=]

I'd overlooked a very important feature of SketchUp that pretty much ends any issues with lost texture mapping upon .3ds import. It has to do with the fact that texture mapping can be shared or stretched across polygons. To employ the feature, establish a working environment where you may select individual polygons of the model. Now, working from the border polygons between good mapping and skewed or lost mapping, select the bucket tool and use the control key to switch to eyedropper tool and copy from a good polygon. Click the adjacent bad polygon and it will paint a texture segment appropriate to be adjacent to the copied poly. Distortions increase as the copy/paste procedure moves farther away from the originally good polygons into the area to be edited. The technique might take some getting used to but in this way you can restore holes and even paint texture around onto the backside where you previously hadn't mapped it. You can, for example, map a large texture, defined as projected, onto a single polygon, at a scale appropriate such that the polygon occupies a very small portion of the texture. You can then copy that single poly, select the entire model and paste the entirety of the texture onto the model with the same mapping as the original polygon.
This will work with any model that has lost mapping including the .obj format, but with the clear loss of large portions of the mapping and an absence of any recommended fix from Gary for the extension he'd recommended, I'd stick with .3ds.

Of course you could always pony up and go for Autodesk, the creators of the .3ds format. 3ds Max 2016 will export to many formats, including Collada and MSFS native .X with the proper plug-in.

 

[GaryGB]

http://www.fsdeveloper.com/forum/threads/fsc-via-3ds-to-su.437496/#post-746035

Just what kind of operation do you propose that involves a work-flow of converting models from a format you do not have access to into a format which you do have access to?

Hi Rick:

To clarify what I posted above, I am not proposing analysis of a Sketchup import from a MCX-derived export of your 3D model.

Rather, I would propose that if you were to post your 3D model depicted above as a downloadable attachment to this thread ...in its original SKP file format, "I would be glad to process it via 1 or more Ruby plugin scripts for Sketchup which can analyze your 3D model for factors resulting from how the model was created, and which may impact how software intended to convert 3D models may have been influenced by the 3D model itself (independent from factors involving additional individual settings and procedures for how 3D file conversion or modeling software processes a particular 3D model)."

http://www.fsdeveloper.com/forum/threads/fsc-via-3ds-to-su.437496/#post-746020


Processing "the placed scenery files" attached to this thread or those files "available at Avsim" of your "Mt Diablo Vista House" via MCX import / export, and then via the OBJ importer or default Sketchup 3DS importer, would not allow for accurate analysis "for factors resulting from how the model was created ...independent from factors involving additional individual settings and procedures for how 3D file conversion or modeling software processes a particular 3D model" (when imported into Sketchup).


IMHO, it is apparent from the screenshots you posted above, that there may be issues with the existing "Mt Diablo Vista House" 3D model when imported into Sketchup via MCX import / export and then via the OBJ importer or default Sketchup 3DS importer.


BTW: While I personally would always welcome any ongoing fixes / enhancements to any software (and TIG has probably issued more updates over the years for nearly all his scripts than any other Ruby plugin script author I am aware of), AFAIK, his OBJ importer linked above is already quite likely to have been "meticulously vetted", and is less likely to be the cause of issues seen when your 3D model is imported into Sketchup.


Thus, IMO, it is more likely that there may be issues within your "Mt Diablo Vista House" 3D model resulting from how it was created that would require adjustment of settings in MCX and/or any default or 3rd party importer to accommodate.

Additionally, there may be some cleaning and/or modeling / texture material mapping which might be required to allow a more 'flawless' result when finally (re-)imported into Sketchup ...via either the above linked OBJ importer or the default 3DS importer.


IIUC, by your own acknowledgement above:

http://www.fsdeveloper.com/forum/threads/fsc-via-3ds-to-su.437496/#post-746084

...you are just now seeing where a fundamental procedure of texture material application required for working with Sketchup's default UVW mapping mechanism may not have been utilized with your original "Mt Diablo Vista House" 3D model in "the placed scenery files" attached to this thread, or from the copy "available at Avsim".


If you would like to allow an objective determination to be made of factors within the 3D model file itself that may have resulted in a less than flawless (re-)import of your "Mt Diablo Vista House" 3D model into Sketchup via either the 3rd party or default 3DS importer as seen in your attached screenshots above, please feel free to post as a downloadable attachment to this thread, either the original SKP file (or any current and updated SKP file version) of same ...for evaluation.

GaryGB

 

[=rk=]

I'm confident Roby and anyone else reading in the future has the necessary information to get their own FSDS file into another editor and while occasionally things have to be decompiled; I consider it of passing interest to encounter more efficient ways of doing so and much more productive to discuss ways of creating and improving original works. The scenery just went online at Avsim and 62 simmers are enjoying the view so far.

 

[robystar]

Hi all,

Sorry but I think maybe there is some misunderstanding.
The fsc model I was trying to convert (MCX>3ds>SU) is not perfect. Otherwise it would serve no purpose trying to convert it to get rid of inaccuracies in the model and its texture mapping, as there would not be any.
Thanks to the both of you for providing enough information. I can now try both the 3ds method and the obj method and see which one is easiest and gives the best result as to the texture mapping integrity and as to the presence/absence of hindersome superfluous triangulation. Wouldn't it be nice to have a .fsc importer for SU.

Cheers and thanks once again.

 

[robystar]

Hi Rick, hi Gary,

It is always more complicated than at first you think it is.
From MCX>3ds>SU: SU cannot find the materials because the model still has the dds'es. So I have to go back to MCX first and change all the textures back to 24 bit ones first!
From MCX>obj>SU: the same plus you have to register to get it first and I wonder if it is worth the trouble because I remember that a couple of years ago I wanted to try it but it was payware at the time (no trial period either). Moreover, the 'info' on the website says that if a model is too complex (it rather is) it (or the textures) may not show up at all. Besides that it gives the same kind of warnings as for the 3ds one.
Right. So I will first go through the trouble of converting back the dds'es to 24 bit BMP's and see what that brings. What I do know from the imported 3ds model is that it looks OK (no artifacts at least) but without textures for the moment.
Will be back until you get sick and tired of me.

Oops, I forgot my PS!
PS: I do not think that Arno's future dae/collada converter option will change the necessity of changing the dds to some other SU readable format either.

 

[robystar]

For your info:
Dino Cataneo has the same problem as I have: http://indiafoxtecho.blogspot.nl/
(courtesy of Flynby)