Today I stumbled upon this new tool by Google: Building Maker. It is quite impressive to see how with a few mouse clicks you can make a 3D model using images showing the object from different angles. I guess this way of constructing would be the dream of many FS developers as well.
I did try the tool for a simple office building and that worked quite good, but I am not sure how easy it is with irregular shapes. I guess it is mainly suitable for objects that don’t need too much detail and mainly rely on their photo textures.
I also noticed that the latest Google Sketchup has a function to use Google Streetview images on the object directly. Although it might be easy, this new feature and the Building Maker tool make me wonder about the copyrights of the images used. We are not allowed to take images from Google Earth and use them in FS, but these kind of object depend a lot on such images. So would a designer who made an object like that be allowed to use it outside Google Earth?
As a little bonus feature on top of the COLLADA reader I added yesterday, I have now also added a KMZ reader. KMZ is the file format used by Google Earth for its objects and basically it is a ZIP file containing the COLLADA file for the object and all the texture used all in one.
Below is a little screenshot of this reader in action. I took this cottage object from the Google Sketchup Warehouse to test if the reader is working fine and as you can see it is.
The COLLADA reader for ModelConverterX, that I talked about in the previous post, will be available in the development release from tomorrow. The reader can read the geometries and materials used by the objects. At the moment transformations and animations are not yet supported. Below is another screenshot of the duck test object, now with the texture applied correctly.
I have tested it with some of the COLLADA sample objects and with some Sketchup output and the reader seems quite robust. But since this is just the first version of the COLLADA reader I would not be surprised if some user would find DAE file that can crash the tool. If you do find such issues please let me know.
Last I week I gave Google Sketchup another try and it seems a program you can learn to use quite quickly. If you compare it with GMax I think it has a learning curve that is much less steep. And I think if you model carefully in Sketchup you can make models with it that are suitable for real time rendering. So I think that for some people who just want to make some simple objects Sketchup might be a nice alternative.
But how to get those objects into FS? The free version of Sketchup only exports KMZ and DAE files. You could probably convert them to 3DS, import into GMax and then export, but I think all those extra steps make things too complicated. So I decided to work on a ModelConverterX feature that has been on my list for a while already, support for COLLADA DAE files.
I am not there yet, but I can now read the basic geometry from COLLADA files into ModelConverterX, below you see a screenshot where I loaded the COLLADA test duck. I still need to work on reading the materials used correctly and I guess some testing to see how robust the code is would be nice as well. But with a bit of luck I will have a beta of the COLLADA reader in the development release soon.
Time for a little update. This weekend was the annual FSWeekend in the Netherlands again, and I was present there on behalf of NL2000 and FSDeveloper. For NL2000 this was certainly not the first time we were there and it was a lot of fun to meet all those users of our scenery again. There are people you see almost every year at the weekend. For FSDeveloper it was the first time we were (a bit) visible at the event. Due to the more technical nature of the FSDeveloper community there was maybe a little less interest, but hopefully it helped some people to get starting in making some addons themselves.
Another interesting thing at the FSWeekend was that IVAO had organised a seminar about the future of Flight Simulation. At those sessions a panel discussed the consequences of the closure of ACES and what it meant for our hobby. The panel of 5 consisted of Jonckers (IVAO), Kenny Moens (IVAO), Mathijs Kok/Winfried Diekmann (Aerosoft), Francois Dumas (FSAddon and more) and me (NL2000/FSDeveloper). I guess this topic could deserve its own blog post later on, but in short the participants agreed that for the short term the consequences were mainly more stability and more time to develop nice addons. For the longer term the opinion varied more, but it is logical that you look differently at it when you try to make a living on FS addons. The fact that Aerosoft is considering to build their own simulator was also discussed of course and that sounds interesting indeed. I guess we’ll see what the future brings, but the FSWeekend also showed that there are still many people enjoy flight simulation as a hobby.
So with the FSWeekend over now, it is time to move on to some other things again. Besides the busy work schedule and the normal family activities, I will try to focus on two things in the coming weeks. The first one is to finish the typical Dutch windmill objects for the NL2000 scenery. Since we got asked many times at the FSWeekend when the next release will be, it guess I should try to give this some priority. Because we can’t release a Dutch scenery without such objects, we should keep up the myth that we all live in windmills and wear clogs. Oh and to come back to the question about the NL2000 v4 release (which I answered a dozen times this weekend), it will be released when it is ready and we can’t promise a date yet. But we can see the end of the beta testing tunnel by now.
The other activity I want to put some focus on is the new gPoly tool I am planning. The idea has crystallized quite clear in my head by now, so I am looking forward to start the actual coding. I really think that a tool to make the creation of custom ground polygons a lot easier would be helpful to many developers. So hopefully I can report some progress on this soon.
Today I made a new version of a small tool I did some time ago. Actually I redesigned it completely from scratch using C# and .NET this time. The tool I am talking about is CompileHelper. This is a small tool to assist developers in compiling their source files. For many developers using command line compilers like BGLComp, BGLC or SCASM gives quite some trouble. This is mainly because they have not been designed to be used in the drag and drop fashion that is so popular nowadays.
On forum you often read that people get no BGL or MDL file from the compiler and that a little black window showed for a micro-second. That proves to be too short to read the useful information the compiler is throwing at the user. Often that information will tell you exactly why your BGL or MDL file could not be created.
A few years ago I made the first version of CompileHelper to ease this problem a bit. The tool allows you to drag and drop the source file on it, just like you would love to do with the compiler. CompileHelper then calls the compiler in the background, but captures all feedback. Then we the compiler is finished this feedback is presented to you. Besides that the tool will also determine which compiler you need.
So today I made a new version of this tool, because the problem is still as common as a few years ago. And the old version of CompileHelper did not support the FSX BGLComp directly. Therefore I decided it was time for a redesign. So if you want to get the new version, have a look here.
The functionality in ModelConverterX to create lower level of detail versions of a model was running very slow for complex objects. I have not fixed that completely (yet), but I have made some changes to this functionality that should at least make it easier to work with. The calculation that simplifies the object is now running on a different thread, so that at least the rest of the tool should remain more responsive. I have also added a progress bar, so that you can see how far in the simplification process the tool is already. See the screenshot of the new dialog below.
As you might see there are some more changes. I have removed the 3D preview from the LOD Creator dialog. Instead the mean 3D preview is used now to display the result of the LOD Creator dialog. You can still select the LOD you want to see from the LOD Creator dialog though.
Optimizing the simplication code further, so that it will run faster is still on my todo list. But at the moment I am also busy with preparing for the new gPoly ground polygon tool. So I am not sure which one will get my attention first. Now that I am talking about the gPoly tool, I would still be happy to receive your input on what you would like to see in a tool for custom ground polygons.
I have just fixed some bugs in the 3DS exporter of ModelConverterX. The main issue solved is that complex objects often could not be imported into GMax. Without going into too much technical details, this was caused by some variables being stored as a short, allowing a maximum value of 65535. Some object parts had more triangles or vertices than this limit and that resulted in the error when importing. This has now be been fixed and those model parts will be split when exporting.
Another improvement I made to the 3DS exporter is that the night textures and bump textures are now also written to the material when exporting.
For future improvement of the 3DS exporter I still have the wish to add animations as well, but that is a little lower on the priority list at the moment. And another 3DS related wish is to have an importer for the 3DS format as well.
As I posted before, I am planning for a new ground polygon tool. To get more clear how potential end users, yes that is YOU, would prefer to make ground polygons I have setup a poll at the FSDeveloper forum. So please let me know what your ideal way to add ground polygons to a scenery would be. That will help me in creating a tool that is easy to use. I hope to see your vote!
You could say that recently unions have played a role in my life. First there has been my wedding one and a half week ago of course, forming a nice union between me and my wife. But that is not what I want to talk about in this blog post.
I have also been working on some code that allows me to do boolean operations between polygons. This functionality is something that will come in handy when I start working on my new ground polygon tool, It can for example be used to automatically slice the polygons into piece of no more than 100 meters, so that there are no problems with the curvation of the earth within FSX.
Below you see a screenshot of my test application, where I am testing out these boolean functions. The red polygon is polygon A and the green one is polygon B. The four small pictures below show in grey the union of A and B, the intersection of A and B, polygon A minus B and polygon B minus A respectively.
At first I looked around for some library that implements this functionality and although some exist, I still decided to code it myself in the end. The main reason for that was that I wanted to understand how the process works and that why learn a bit more from it (although it might not always be the easiest way). So in the end I used the algorithms described in Geometric tools for computer graphics and make my own implementation, building further onto for example the polygon class I had already made for ModelConverterX.
The boolean operations are not completely bug free yet, I have already found a few polygons that are not processed correctly. So there is still some more work to do and after that I will start with creating the tool for ground polygons that can make use of this logic. So I still have much more fun ahead…