SceneryDesign.org
And here is a screenshot of the church made with SketchUp in FSX. It has been converted with ModelConverterX and is showing on the NL2000 v4 scenery. I am not completely satisfied with the textures yet, they seem a bit too light when viewed in FSX, so I think I will change them a bit.
Oh, and don’t expect to find this object in the coming NL2000 v4 release, since I am too late now to still add it. We are already further in the testing and release process.
Let’s start with the good news, I finished my model of the church in Abcoude. All the textures have been applied as you can see in the screenshot below. But I learned some interesting things while trying to get that far.
Let me start with explaining my approach to texturing the building. I had decided to make separate texture files for each of the different walls. Mainly because I have not yet found a way in SketchUp to define the UV coordinates very accurately. So trying to map a sheet with many different texture elements would become hard that way. If each wall has its own texture though that becomes a lot easier already. And of course I will use the drawcall minimizer of ModelConverterX later on to still make one combined texture sheet for FSX.
One of the things that I encountered is that I needed to position the texture very accurately, because even a small error would result in the textures repeating over the surface and then I can not combine them into one texture sheet in ModelConverterX anymore. So especially for the textures that do not simply fill the entire face that took some trial and error.
One performance related lesson I learnt is that you need to export as COLLADA DAE and not as Google Earth KMZ from SketchUp. When exporting as KMZ (almost) all of the faces are exported double sided, which increases the polygon count a lot. And in the KMZ exporter I could not find an option to disable this, when exporting as DAE there is such an option (and by default they are not double sided anyway). So although it might sound easy that a KMZ has the textures in the same file, it seems better not to use it.
Another performance related issue is that while drawing geometry in SketchUp some additional polygons might be created without you really noticing it. So in the end I spend some time to remove polygons that could not be seen from the outside anyway. I guess this is the price to pay for the easy way to draw the geometry, but it is for sure worth the effort to check and remove such polygons in the end.
So if I look back to this SketchUp experimentation until now I think I have to say that the modelling itself is easier in SketchUp than in GMax (and it seems also more fun). It is very easy to just draw some more geometry. The texturing part I am not so sure about yet, it seems you do not have as much control over that as I am used to. Which can make it hard to make a model with optimal performance for FSX. But it might also be that I still have to learn some more options, so I will continue exploring. For sure it is a lot of fun.
At the moment I am installing the latest test version of the NL2000 scenery, once that is done I will post a screenshot of the church in its proper environment.
After finishing the geometry of the church I am modelling in SketchUp, it was time to move on to the texturing of the object. So also for this part I tried the different options that SketchUp offers.
First I tried to use the project texture function when using the match photo feature. This allows you to align your model to a photo and will then project this photo as a texture onto your model. I guess this might work well if you have an object that is not so complex in shape, but for my church it did not work that well. Since the shape I modelled did not match the real church 100% and because some photos had some distortion as well, the texture never fit properly on the model. I think later I will try this function again with a more simple (rectangular) object, but for now it does not allow me to make textures with the quality I want.
So after that I just tried to import my photos directly as textures (without letting SketchUp projecting them). You can then map them in SketchUp quite easily by putting the pins at the corners of your faces in the photo and then aligning them with the face. This gave slightly better results than the projecting, because you have more control over where the texture goes. But still it is quite hard to align different photos correctly and let the textures continue smoothly over different faces.
So I guess in the end it sounds too good to be true that you can very easily make textures using only photos. My next attempt will be to make the texture in the normal way, by composing it manually from the photos using GIMP. I am sure that will result in the quality I am looking for, just a little more work. I will post the results again once this phase is done.
After all the work I did on the COLLADA and KMZ importers for ModelConverterX, I thought it would be a good moment to try to model a bit more in SketchUp myself. So about a week ago I cycled to the nearby town of Abcoude and made a bunch of pictures of their local church. With those as my reference and some maps I found on the internet, I started modelling the church today. In this blog posts and those that follow until I have finished the object, I will try to give an overview of my adventures while learning more about SketchUp.
Being a bit of a number-head, one of the things that worried me about SketchUp was if I could easily enter numbers for sizes of objects and offsets. I know many people do not worry so much about this, they are mainly concerned with how the object looks, but my style of modelling involves using paper and pencil to calculate distances and things like that. And although it works different from GMax, I must say that I am very happy with the way SketchUp allows you to enter distance when drawing lines or when moving objects.
Below you see a picture of the church and drawing the roof was quite a nice learning experience. With all the SketchUp functionality to draw lines parallel or perpendicular to other lines or the axis, it was in the end quite easy to make this roof. Even though the walls supporting it have different heights.
While modelling the church I also experimented with the match photo function of SketchUp. This function allows you to align your view so that it matches with the position from which you shot your photo. Afterwards you can then model in that view and make the object match the dimensions as show on the photo. At first I had some troubling setting this up correctly, but I think that was many due to make lack of good overview photos. Due to all the trees planted around the church, I mainly made detail photos, while not having many good overviews. My impression is that the match photo function works best with pictures that show a big part of the object.
But in the end I got it setup for some shots I made and it turned out to be a really easy way to determine the height of the roof and the tower. Below you see an picture of the object being aligned with the photo (I made the object transparent so you can see the picture better).
So as you can see in the pictures, the basic shape is done now. I will probably have to add some minor details to gables and that kind of stuff. But I am quite satisfied with the result until now. The next step will be texturing the object. I have already done a little experimenting with projecting pictures on the object (after I used the match photo function), but as you can see in the picture below the results are not good enough yet. I am planning to see how far I can go with projecting the pictures and then using the Drawcall Minimizer of ModelConverterX to make a nice texture sheet. If that does not work, I will go back to the traditional way of making the texture sheet myself.
Another thing I hope to learn from these experiments is how to model most efficiently in SketchUp (from the point of view of FSX). So how do you keep the polygon count and the drawcalls within limits. Using ModelConverterX I can get nice statistics about all those performance related numbers. So more on that and the texturing in a next blog post.
It feels like it is a long time ago I wrote a status update about the gPoly tool. And now that I think about it, it is actually a long time ago. But this weekend I have done some work on the tool again. I have mainly focussed on two functionalities:
I plan to first improve the exporter further, so it writes the kind of code that works in FSX, before I return to the GUI part of gPoly and start polishing the features there. Now most of them have some rough edges left. But that is for another status update.
A few weeks ago I introduced the Drawcall minimizer functionality of ModelConverterX. This function can pack the different textures used on your model into bigger texture sheets to reduce the amount of drawcalls. This will result in a better performance in FSX.
One of the main drawbacks of the initial implementation was that only the diffuse textures of the model were packed. I have now finished the code that also packs subtextures, like night textures or bump textures. So that should make it easier to reduce the amount of drawcalls on models that have such textures.
This updated functionality is not yet available in the development release though. It seems to be working on the models I tested until now, but since I made quite some changes to the code to work more efficiently with these subtextures I want to do some more thorough testing to be sure I do not introduce new bugs. So I hope that tomorrow I have finished those tests and this new function will be available.
With this functionality finished, I have implemented all of the features that I planned for the ModelConverterX 1.2 release. There are some minor bugs that I want to fix, but I plan to release another stable version soon. I’ll keep you updated about that as well.
The problems we had at FSDeveloper, which resulted in no emails being sent out by the forum software have been solved. So from now on the forum notifications and the confirmations for users that are registering are working again. Thanks for your patience while we were solving this problem and a big thanks to fellow administrator Lefteris for finding what the problem exactly was.
I guess everybody knows the abbreviation RTFM and of course we all read the fine manual when we are using a tool. But for ModelConverterX I usually only update the manual with every stable release and the recent survey showed that most of you are actually using the development release. So as a result of that I have started a discussion on the forum to find out how you use the manual now and how useful it is to you. I am looking forward to hearing your feedback!
Some time ago I started a survey to understand better how ModelConverterX is used. Thanks to everybody who provided their feedback, I have now collected the answers and made an overview of them.
Luckily many of the answers are not too surprising, it seems in general the tool is being used as I had expected. And the features people are missing are those that I had on my wishlist already. And of course there are always some nice new ideas, so I will put those on my wishlist as well.
I would like to put some more focus on two of the results that surprised me most. First the COLLADA DAE format seems a lot more popular than Google Earth KMZ to import models from Sketchup. I find this a little surprising, since I had expected KMZ was more popular. I think the advantage of KMZ is that the textures are contained in it as well, so you never loose them. But it seems most Sketchup users use COLLADA DAE files instead.
Another thing that surprised me even more is that import SCASM files and API macros is not popular at all. Even the recently added functionality to import COLLADA files is more popular already. Since I started developing this tool to convert my old API macros over to the FSX MDL format, I was a little surprised to see that most people perform other conversions with the tool. I guess you could almost say that the tool has a sort of mid-life crisis and is transforming into other functionalities as well.
Once again, thanks everybody for your feedback, it is really interesting to get an overview of how you use the tool!
In the next development release of ModelConverterX you will find a first implementation of exporting animations to FS2004 scenery MDL files. This item was on the wishlist for quite some time already and I have now given implementing it a try.
I am sure you will find some bugs in this first implementation. Some of my test objects still go wrong, but the majority works fine already. So if you find any trouble or have an object that does not yet work correctly, please let me know.