Three simple questions...

#1
Hey all, just some simple questions about your preferred workflow. As a newbie to modeling I'm wondering what the easiest way is to do things. So before I go downa path that will later see me backtrack and take huge detours because of something I did wrong previously, I thought I'd ask here first.

1) Render engine: I noticed there are two main (?) rendering engines that people use in Blender, namely Blender Render and Cycles Render. In the majority of Youtube videos that I've seen (with or without focus on FSX/P3D development) it seems like Cycles Render is more popular. I have given both a go and found the workflow of Cycles Render easier to get my head around, but I'm wondering what people advise?

2) The use of the Blender2FSX/P3D toolset or ModelConverterX (MCX): Most Youtube videos I watched invariably export their model as a Collada file, which they then open in MCX for final preparation for FSX/P3D. I've really only seen one video where somebody used the Blender2FSX/P3D toolset, but it does seem like the easier way to go about things. In regards to this, I'm also confused how setting up any kind of special modules for texturing effects has any influence on the final product if you use MCX? Does the Collada file store all that information? or do you somehow apply the effects of the different modules to the texture that you create, similar to when people 'bake' shadows and lighting onto textures?

3) Model export: Finally, I've always noticed people making a bunch of models in one file, but then I've also seen one or two people advise to export models one by one (for reasons I don't remember). So, I was wondering what people generally do? Currently I've modeled an entire trailer park by making some 5 or 6 different models and simply duplicating them to fill the entire park (I gather that with the trees in-between them you wouldn't really see the difference that well anyway). I thought to just export this whole thing as one Colada file, but was somewhat unsure at that point how to continue in MCX, so that I was wondering if that was the reason I had previously reed somebody advising to go one-by-one. What's people's preferred method here?

Curious to hear your all's ideas regarding these things. I have a ton to learn, that much is clear, but would like to start on the right foot :) Whatever modeling I've done so far has been fun; now I just want to make sure I'm doing things in the most straightforward way possible before I go into modeling something actually complicated. Any comments are appreciated!
 

dave hoeffgen

Resource contributor
#2
1. Cycles render can't be exported using both the collada-MCX approach or the toolset. It can however be used to bake textures. This could work the following way: you have two versions of the model. One to bake the textures and one to apply the textures and export. The "bake model" can use any of the engines while cycles typically has the better render result.

2. I personally prefer the toolset because it can even export the model directly to .bgl (if you specified placement data). There might be reasons of mesh/shading quality to use the collada approach but I dont know any details on that.
Note that if you use collada and MCX the Blender2FSX toolset won't be necessary, as FSX/P3D aren't exported to collada and you'll have to do all of that in MCX every time you export.
Not sure what kind of "special modules for textuhring effects" you are talking about but if the effects can be baked into textures it will work either way. any other effect has to strictly follow the way FSX/P3D can read it (particle effects, special material settings, bump and specular maps, what do you mean?)

3. you can group things into one model if you see fit. Is that what you mean? Other than that you can group exported models into a single library file.
If you model a group of buildings for example, it can improve performance by keeping them in one model. The group should not be too larg in size though. A model that's several kilometers large has the opposite effect and should be split in smaller ones.
There are also models that you might want to place multiple times over your scenery so these should obviously be exported as a single object. Also make sure a single model does not exceed a certain amount of geometry. Blender has a counter at the top.


Hope this helps for a start. Feel free to ask if further questions occur :)
 
#3
Hello Dave and thanks for the helpful information! Already you mentioned several things I had no idea about.

1) So currently I'm working with Cycles Render, and was able to export into Collada and open it in MCX, so I'm not sure what isn't working about that according to you? In addition, can I switch between render engines once I have the model? And if not, how can I move the model between render engines? You touch upon something else: the best "render result". This has been terribly confusing to me, because it doesn't seem to me like I'm rendering anything in the process from modeling to exporting to MCX. At what step does the rendering occur? Is this something automatic that happens when I export, or...?

2) That makes sense. I gathered that the toolset will automatically identify the textures, along with the bump maps etc and compile the whole thing without needing further intervention, but I'm guessing that you will need to proparly format all the textures before doing so (proper size, including the night maps and alpha channels, etc EDIT: read in the toolset manual that you have to add various kinds of materials for that to work. Sounds easy enough...)). MCX has a nice UI that would allow you to pick and choose everything, making it perhaps a little easier to get my head around. But it might just be better to jump in the deep end and get used to it ASAP?
As for the modules... I'm probably using the wrong terminology. Maybe it was nodes? I watched a Youtube video that talked about nodes (?) that can be linked up to change the appearance of a texture, e.g. make it shine like a lamp, or gloss like a chrome surface. Will this be all applied to the texture upon export (via Collada/MCS or toolset)?

3), Yes, grouping is what I meant :) Here's my situation: I have a trailer park that consists of 5 or 6 models that I duplicated and placed at different locations. They are not grouped into one model though, they are all their own, discrete models. I guess what makes me confused is that when I export the park as a Collada file, the entire thing appears in MCX, regardless of whether I grouped them as one model or not. My question is whether it would make sense to group them all into one model, or export them as separate models? They are all very simple, basically a roof and four walls, perhaps with or without a sunscreen protruding form one wall. And erm... how exactly do I export them as separate models...? I tried selecting a single trailer and exporting that to Collada, but when I open it in MCX, it turns out everything was exported...

4) Now, you specifically address exporting models separately and making them into a library, so that they can be placed separately all over the scenery (I can see ground equipment falling in that category). This is another thing that derives from (3) that I was wondering about: How does one make an object library, and how does one then place the objects in P3Dv4? I understand SimDirector can do this, and I'm guessing that ADEX or SBuilderX can do that too. Is there a preferred method? Are there big differences between the methods? So far I'v really only used ADEX to update the layout of my airport, and SBX for laying down some landclass and flatten polygons...

I know I know, lots of questions... Thanks for helping out!
 
Last edited:

dave hoeffgen

Resource contributor
#4
1. The 3D geometry always exports, regardless which rendering engine is used. What might not work using cycles are the materials. The Blender render engine has a more more simple structure and contains all the things (texture, specular colors....) the way they are typically exported. Also the toolset is designed for Blender render.
When switching between the two rendering engines you will need to redo the materials. The material for the unused engine will remain as you made ith though. Texture images don't have to be reimported.
"Rendering" in that case is meant in relation to baking textures (which is actually some kind of rendering process). If you already have the finished textures you can skip this part completely.

2. That's right. Blender is not specifically designed for FS Development so you will have to care for the FS related requirements yourself.
Speaking of nodes in materials, that's not supported for FS (I've seen some node material editor for P3Dv4 but I have no idea if that can work with Blender's node system). Lots of stuff can be baked into textures though.

3. To clarify the terminology as I used it: a "model" is the whole thing you export to a file. so your trailer park seems to consist of a small number of trailer "objects" you copied around the scene and exported as one "model". Jou can join them into a single "object" within Blender which will not affect the exported result.

4. A library is made of multiple .mdl files (the "models") listed in an .xml file and comiled using bglComp.exe. There are tools like LibraryCreatorXML that help you generate the xml via GUI.
there are a lot of programs that can place models (aka "scenery objects") from libraries. ADEX is definitely one of them.
 
#5
1) Thanks for the clarification! Redoing the materials would be tedious, but I was already afraid I'd have to redo the model itself! Glad that's not the case.

2) Okay, got it! Sounds like those 'nodes' can be baked into the textures, and all will be fine...? Would you be able to recommend a good tutorial that deals with baking textures?

3) Ah... Okay, that makes much more sense now. So that means that if I want to use the Collada/MCX route, I would have to have separate .blend files for each model, correct? Whereas the toolset would allow to export only a selection, making it much more versatile? If yes, then the toolset sounds like the superior route, as it'd be much easier.
Now, with that in mind, is there anything against modeling the entire airport in a single .blend file, and simply exporting the various objects as separate models (say, a trailer park model, a terminal model, a cargo apron model)
Also, MCX, with its wizards and all that, has functions to correct for FSX/P3D's curved earth. This was the primary reason for me to use the Collada/MCX route. Does the toolset do these kind of things automatically? I'm asking mainly with ground polygons in mind, or would it be recommended to still use MCX for this?

4) Sounds great, I'll have a look at LibraryCreatorXML and its documentation, and then it ought to be straightforward from there on out (I hope). What is your preferred program to place scenery objects?

Thanks for this help, it's invaluable! Already saved me days (weeks?) of wallowing around in despair and frustration.
 

dave hoeffgen

Resource contributor
#6
2. You can look at some of these: https://www.youtube.com/results?search_query=blender+guru+baking

3. I think the collada can also export a selection instead of the whole scene.
Also the problems with modeling everything within one blender file and exporting partwise will be that all mdls will have the same guid which they must not have and also have the same origin point which might often be far off the actual geometry.
I still recommend ground polygons to be put through the MCX ground polygon wizard as Blender has no earth curve correction.

4. I use Whisplacer sometimes. It is free, GPL licenced and has a realtime preview within the sim. But pretty often I have unique models that I place via the location form in Blender.
 
#7
2) Thanks, looks promising! As always Blender Guru makes things look terribly easy ;)

3) I tried exporting a selection but was unsuccessful so far... I probably made a mistake somewhere along the line. Will try to find some info on that.

4) Looks like a great tool, thanks for mentioning it!

Thank you so much for the pointers, this is a huge help. Let me just put all this together to see if I understand what you're saying. It sounds like the best way of going about designing a smallish regional airport would be along these lines:
  • In SBX, partition the ground imagery of the airport into several discrete areas, such as the GA ramp, Pax terminal area and cargo apron. With this I mean to create several small background satellite images, rather than just taking one big one. My reason to use SBX is because it gives you all the coordinates as well as the image with essentially the press of one button.
  • Use those subset ground imageries as background images for use in Blender. They have their own coordinates as well as origin, so that whatever you make, the geometries and origin will be overlapping.
  • With those three ground images, I can then make three blend files that all will be their own model. Thus this airport would have three models with their own name and GUID, though I see one could also devote several blend files to one such ground image and make several models of of it... Whatever works best, I suppose.
  • These can then be exported from within blender using the toolset, circumventing MCX for the most part.
  • The only exception would be the ground polygon, for which it would be good to get an image of the entire airport, export as Collada and use the MCX wizard to convert it into a model.
  • Finally, for ground equipment, cars, trees etc, the preferred way is to make discrete models (meaning multiple blend files) that are then placed into a library, to be placed at will around the airport.
One final question: does the origin also define the central coordinate that has to be entered into the toolset's placement form? Meaning that if the origin moves, the center coordinate also needs to be adjusted?
 

dave hoeffgen

Resource contributor
#8
  • In SBX, partition the ground imagery of the airport into several discrete areas, such as the GA ramp, Pax terminal area and cargo apron. With this I mean to create several small background satellite images, rather than just taking one big one. My reason to use SBX is because it gives you all the coordinates as well as the image with essentially the press of one button.

  • Use those subset ground imageries as background images for use in Blender. They have their own coordinates as well as origin, so that whatever you make, the geometries and origin will be overlapping.

That's a reasonable approach. Though I always recommend using a plane textured with the imagery instead of the background image function. That's simply because you can give the plane the exact dimensions (you can calculate them in MCX's coordinate converter). Also there might be some distortion in your imagery that can be easier dealt with using planes.
I once made a wiki article on this: https://www.fsdeveloper.com/wiki/index.php?title=Ground_Polygon_modeling_in_Blender#Background_Image

One final question: does the origin also define the central coordinate that has to be entered into the toolset's placement form? Meaning that if the origin moves, the center coordinate also needs to be adjusted?
Exactly. The origin of the entire Blender file is the point the placement coordinates apply to. I usually calculate it by interpolating it from the imagery's georeference.
 
#9
Ah it was you that wrote that tutorial? I've been using it happily - initially with some trouble, as I in general had only little idea of what I was doing in Blender, but now successfully. Following your pointers I have been able to use the toolset to export my models. After some confusion with the textures I remembered that FSX+ textures need to be in flipped DDS format, so after a quick fix for that, voila:

2018-5-20_22-44-9-643.jpg


Assortment of 'mobile homes' as well a Greyhound bus station just to the left of the trailer park :) I do need to rework the autogen a little. perhaps I'll end up making some tree models and place them myself, as I'm not too taken by the way the autogen populates the assignments I created. Also, the use of the toolset to compile the bgl was indeed a way more straightforward way of handling things rather than using MCX, which I also tried but ran into all kinds of niggles. The toolset saved me a lot of time on that, actually.

Thanks Dave for all your help! You saved me a lot of time!
 
Top