Towards version 1.3

[arno]

With version 1.2 released, I think it is a good moment to write down my ideas for version 1.3. I should directly note that at the moment I am focusing more on the gPoly tool, so it might take a while before all these features get added.

At the moment these are the main features I have planned for version 1.3. But things can always change depending on other developments of course. Originally the COLLADA reader was only planned for version 2.0, but when I realised the potential of SketchUp I decided to accelerate it a bit. So this set of planned features is also not 100% fixed.


Improved LOD creator, with better performance and different methods to generate LODs
New material editor user interface, with the mass texture editor and drawcall minimizer integrated into it
Support conditions on (parts) of the object, e.g. the SCASM IfVarRange and IfVarAnd commands
Support for AC3D format
General performance improvements to 3D preview

[gary20]

Thanks Arno

This really has turned into an incredible tool.
Glad to see you'll be looking at the SCASM IfVarRange and IfVarAnd commands

Gary

[hcornea]

This is fantastic work Arno.

An idea for consideration:

When checking a library, would it be possible for Modelconverter to compare the "like" materials ... to suggest correcting ones that would represent an unnecessary additional drawcall.

Maybe a report of "Unique Materials" by Texture (and which objects use them). Sounds obtuse, but this would enable you to see which textures had several materials attributed to them .. and hence adjust the outliers.

Thanks for all your work on this.

[bertvk]

hi Arno,
Again thanks for all the work done sofar.
Happy "Pinksteren"

Regards.
Bert

[arno]

When checking a library, would it be possible for Modelconverter to compare the "like" materials ... to suggest correcting ones that would represent an unnecessary additional drawcall.

Maybe a report of "Unique Materials" by Texture (and which objects use them). Sounds obtuse, but this would enable you to see which textures had several materials attributed to them .. and hence adjust the outliers.

That's a nice idea indeed. I have put it on the wishlist.

[Sidney Schwartz]

My needs are pretty simple. The only feature I'd like to see improved is the LOD function. I'm still not convinced, though, that creating LODs (removing parts) in MCX is preferrable to creating LODs in whatever program we're using to create them and then letting MCX combine them. Using GSU, I see two possible scenerios:

Scenario 1
1. I create the full object in GSU and save it.
2. I make a copy of the object, remove some details, and save it as a second object. Since GSU is a full featured modeling program, doing the editing is fast and easy, and I already know how to do it.
3. Repeat as necessary for additional LOD models. I this point I have saved copies of all LOD models and can easily do further editing on them if necessary without having to redo them from scratch.
4. Import full object into MCX and then indicate to MCX which objects I would like to use for LODs and let MCX combine them. Hopefully MCX would create a data file that saves this information so it would not have to be re-entered the next time I load that object into it.

Scenario 2
1. I create the full object in GSU and save it.
2. I import the object into MCX and use MCX to edit the object and remove details. (I'm not interested in having MCX decide for me which details to eliminate.) The first question is what is the advantage of doing this in MCX vs. doing it in GSU? Second question is whether or not MCX will save each LOD that I create seperately so that it will be available for further editing if necessary. Suppose I use MCX to create 3 LODs for an object. I test the object in FS and determine that LOD #2 needs tweaking. Will I be able to recall LOD#2 in MCX, or will I have to redo it from scratch?

I like to keep things simple, like me. :D I'd rather MCX concentrate on conversion issues rather than trying to duplicate things we can already do very easily in our modeling programs. Since we can't automatically combine LODs in GSU like we can in Gmax, that's all I'd need MCX to do.

Thanks, Arno. :wave:

[Heretic]

MCX is a great tool indeed, even if I've just tinkered around a bit.

The only two requests I have so far:
- A batch function for the draw call reducer. Converting and modifying a whole library with ~100 objects gets a tad tedious. :o
Also, it would be great if one could merge textures for multiple objects onto one texture sheet, say merge textures onto a single new sheet until it is full. You need to make sure though that there's no object with "split" texture sheets, say one half on a full ned sheet and the other half on the new one.

-A "restore library" function (aka "Save As: .bgl"). You can read model data from a library .bgl but the output of the conversion process is just the model files. It would be cool if they could be recompiled into a library. This would save you from extracting the .xml and rebuilding the library with external tools.

[robystar]

It is pretty easy to use LibrayCreator.xml to do the job, but it is indeed an external program. Perhaps it can be incorporated into MCX?

[Heretic]

It is pretty easy to use LibrayCreator.xml to do the job, but it is indeed an external program. Perhaps it can be incorporated into MCX?

That's what I was implying.

[PakMac]

I was hoping for a FS2K2 converter. See post 3 (http://www.fsdeveloper.com/forum/showthread.php?p=132670#post132670)

I have tried converting the bgl's to scasm but I'm not having much luck.

David

[Sidney Schwartz]

Is it possible to import an airplane mdl and convert it to an object mdl? This would be great for making static aircraft objects. I tried to make an airplane object in Gmax and the results were horrible...I have no talent whatsoever in that direction. :(

[tgibson]

Sidney,

That's currently possible with true FSX aircraft, I understand, but not FS2004 models. It's on the list though. :)

[Sidney Schwartz]

Does that mean an FSX airplane could be turned into an FS9 scenery object? I don't care if the plane is FSX or FS9, as long as it works. :D

[hcornea]

Yes ... but often aircraft are unacceptably complex for static scenery placement ... so care would be required.

[Sidney Schwartz]

Sure. I figured that once the model was converted to a scenery object, it would have to be simplified, sort of like making an LOD.

[arno]

Hi Sidney,

Thanks for your detailed input on the LODs.

It is on the wishlist for version 1.3 already to have the ability to import and merge different models, so that you can design the different LODs in SketchUp and merge them in one MDL with ModelConverterX. If you prefer to manually make your LODs that is probably the most sensible approach.

The LOD Creator tool as it is now was mainly made to see if it possible to fully automatically make LODs. Mainly because I am too lazy to do it all manually, I find that a quite boring part of modelling your scenery object. But I must admit it is not fully mature yet.

[arno]

Hi,

Thanks for the suggestions.

- A batch function for the draw call reducer. Converting and modifying a whole library with ~100 objects gets a tad tedious. :o
Also, it would be great if one could merge textures for multiple objects onto one texture sheet, say merge textures onto a single new sheet until it is full. You need to make sure though that there's no object with "split" texture sheets, say one half on a full ned sheet and the other half on the new one.

That is a good idea, I have put it on the list. It would indeed be nice if some operations can be done in the batch mode as well.

-A "restore library" function (aka "Save As: .bgl"). You can read model data from a library .bgl but the output of the conversion process is just the model files. It would be cool if they could be recompiled into a library. This would save you from extracting the .xml and rebuilding the library with external tools.

At first I did not implement this function because I do not want to make it too easy to use (or "steal") models for a library you did not make yourself. If you did make it yourself you should have the XML source already.

But it is on the todolist to integrate Library Creator XML and ModelConverterX more, since they are often used together. So I think in the future Library Creator XML could become a part of ModelConverterX. Not sure if that will be version 1.3 though, might also be a bit later.

[arno]

Hi David,

I was hoping for a FS2K2 converter. See post 3 (http://www.fsdeveloper.com/forum/showthread.php?p=132670#post132670)

I have tried converting the bgl's to scasm but I'm not having much luck.

Like I mentioned in the other thread already, that is part of the todo list. I guess only once I try to implement it I will see how much work it actually is :). But converting the shape should be possible, full animations will probably never be possible.

[Sidney Schwartz]

It is on the wishlist for version 1.3 already to have the ability to import and merge different models, so that you can design the different LODs in SketchUp and merge them in one MDL with ModelConverterX.
Awesome. :D

Making LODs is boring? To each his own, I guess. To me boring is having to learn stuff like xml code. :rolleyes:

[roger-wilco-66]

I have another suggestion that helps those who build object libraries:

when creating the reports on an object library, pictures of the objects are created.
The nomenclature of the filenames is "object_GUID".jpg . It would be great if the report generator could generate a second set of images wich are smaller like 128x128 or so and have the nomenclature "{GUID}".jpg . These images could be used in SBuilderX (and maybe other programs) as thumbnails in the preview of an object.



Thanks,
Mark

[arno]

Hi Mark,

when creating the reports on an object library, pictures of the objects are created.
The nomenclature of the filenames is "object_GUID".jpg . It would be great if the report generator could generate a second set of images wich are smaller like 128x128 or so and have the nomenclature "{GUID}".jpg . These images could be used in SBuilderX (and maybe other programs) as thumbnails in the preview of an object.

That's a good idea. I already have it on the todo list to make the object report function more configurable. Adding option to specify size and naming convention is a good idea. I'll add it to the list.

[tsgucci]

Hi Arno!

Great version again!

I'm working now to convert sketchup objects to 3ds. I've some problems with the drawcall minimizer but I'll post it to a separate topic.

My wished working method would be the following.
I import the collada file.
Execute the drawcall minimizer.
Export it to 3ds to further work on the object in gmax. Reduce vertices and optimise the object, maybe add some details. For me it is easier to work in gmax (it is not the fault of MCX it is just my lazyness :) ). And than export the mdl directly from gmax in whatever version (FS9 or FSX).

My question is: Is it possible in the drawcall minimizer option to choose which format he should generate the textures. I would need the dxt format to my fs and the normal bmp to use in my gmax. Or even the dds if I want to generate a model for FSX. (sorry I'm modelling for both version, but my preferred one is FS9 :) ) Maybe an option list thicks.

[arno]

Hi,

I think at the moment it picks the format you have set as default texture setting in the options. You can choose normal BMP there as well. Maybe I should give the choice on the drawcall minimizer form.

[tsgucci]

Hi Arno!


What I mean to export the texture in several format at the same time. As you say to give a chice which formats we want in the drawcall minimzer form.

[arno]

OK, understood now.

[Heretic]

At first I did not implement this function because I do not want to make it too easy to use (or "steal") models for a library you did not make yourself. If you did make it yourself you should have the XML source already.

...or decompile the .bgl with one of the many tools for that out there and use the resulting .xml. ;)

With tools like MCX out there, "theft" is an almost guaranteed side-effect, so you can basically just hope that everyone using it uses it "honorably", say for him-/herself only or with permission from the original developer.

In my case, I need MCX for a rework of a performance-eating scenery with tons of objects (and even more drawcalls). I'm just doing this for my personal use at first, with a public release option once the original creator agrees to it (and not any earlier).


Btw:
The disclaimer upon export could be a bit larger, since it's a nice remainder to at least give credit where credit is due.



- Edit: Another request. :o

Could you make MCX read the alpha channel from 32bit bitmaps correctly, Arno? DDS (DXT5) works like a charm, but necessitates the conversion of the textures to correctly display any (semi-)transparent areas.
It would make quick cross-checks between texture editor, modeling program and MCX even quicker.

Also, the...err...liberal interpretation of animations (especially on aircraft) is a feature, rather than a bug, right? :o :D

[arno]

Hi Björn,

...or decompile the .bgl with one of the many tools for that out there and use the resulting .xml. ;)

With tools like MCX out there, "theft" is an almost guaranteed side-effect, so you can basically just hope that everyone using it uses it "honorably", say for him-/herself only or with permission from the original developer.

In my case, I need MCX for a rework of a performance-eating scenery with tons of objects (and even more drawcalls). I'm just doing this for my personal use at first, with a public release option once the original creator agrees to it (and not any earlier).

True. I also said this was my initial reason. Since then I have implemented that export message in the hope to make people more aware. Those who want will always find a way to use the work of other people. So now my strategy is to warn and make people aware. So the feature to integrate working with libraries better is on the wishlist.

Could you make MCX read the alpha channel from 32bit bitmaps correctly, Arno? DDS (DXT5) works like a charm, but necessitates the conversion of the textures to correctly display any (semi-)transparent areas.
It would make quick cross-checks between texture editor, modeling program and MCX even quicker.

I was not yet aware of that issue, I'll put it on the list as well. If you happen to have a simple test object that would be helpful, else I will make some texture myself.

Also, the...err...liberal interpretation of animations (especially on aircraft) is a feature, rather than a bug, right? :o :D

Humm, no :). Most animations should be read in correctly by ModelConverterX. It is a well known feature (or issue) that exporting them does not work yet. Especially for aircraft.

[Heretic]

So now my strategy is to warn and make people aware. So the feature to integrate working with libraries better is on the wishlist.

Thanks!

I was not yet aware of that issue, I'll put it on the list as well. If you happen to have a simple test object that would be helpful, else I will make some texture myself.

Attached to this post is a simple cube with an alpha-channeled texture in both 32bit and DXT5.

I've set the default texture to the bitmap, rename the .dds' file extension to have MCX use it (it will funnily always prefer .dds even with the bitmap still active).

Humm, no :). Most animations should be read in correctly by ModelConverterX. It is a well known feature (or issue) that exporting them does not work yet. Especially for aircraft.

Well, I've tested my aircraft in MCX and some animations didn't play right (they do so fine in FSX itself though). I then loaded the default 747 to check for errors on my part and it also showed weird animation behaviour in some areas (parts of the nose gear assembly not moving with others and thrust reversers going all over the place as the animations played).

As long as the animations work as they should in FSX, this isn't an important issue anyways. I only use MCX as a quick preview tool for aircraft (textures and draw calls) anyways.

[GaryGB]

Hi Arno:

We still need MCX version 1.0 available to download somewhere, since that SCASM code reader works more consistently with a wider variety of *.SCA files, IMHO, compared to version 1.2 (and the development releases). :idea:


Many thanks for your continued innovation with this outstanding utility... I'm looking forward to seeing a version 1.3 ! :)

GaryGB

[arno]

Hi,

Do you have some information about the objects that do not work correctly anymore? The SCASM importer has not been developed a lot since version 1.0, apart from the some bugfixes. And for the test objects I use regularly I notice no difference. So to make it more robust any feedback is welcome,

[arno]

Hi,

Attached to this post is a simple cube with an alpha-channeled texture in both 32bit and DXT5.

I've set the default texture to the bitmap, rename the .dds' file extension to have MCX use it (it will funnily always prefer .dds even with the bitmap still active).

Thanks, I'll take a look at it. I will also check how the DDS equivalence function works, since it should prefer the one specified in the MDL file first :).

Well, I've tested my aircraft in MCX and some animations didn't play right (they do so fine in FSX itself though). I then loaded the default 747 to check for errors on my part and it also showed weird animation behaviour in some areas (parts of the nose gear assembly not moving with others and thrust reversers going all over the place as the animations played).

OK, understood. I know some animations do not show correctly (default EH101 has some issues as well). When I continue with the animations I'll take a look at this as well.