Please tell me what confuses you about XPlane2Blender on this bug, or here!
We are going to be releasing the XPlane2Blender 3.4 beta soon, and with it, a refresh of the UI and documentation. Thanks to a great e-mail about a lack of documentation, it was put as an important part of 3.4 release roadmap. It goes to show… we can’t fix it if we don’t know what’s wrong, even if its not a code problem. And we do want to fix it, I swear!
In addition, I want to remind everyone a core part of the Laminar Research philosophy, identity, and business plan is a thriving modding and third-party plugin ecosystem. Aside from build scripts and the like, Laminar Research employees use the same scenery development tools that are available to all. This is was a deliberate choice that elevates everyone to the same level – except when there is a gap of knowledge. This is never intentional, and never benefits anyone in the long run, especially third-party-devs. If your work is suffering because we forgot that not everyone knows what every little checkbox means, tell us! We’ll put it in the bug queue like everything else, and try to get back to you, personally, quickly.
Thank you for highlighting this..
As a 3D developer educated on 3DS MAx I find Blender to really annoying and totally screwed up. But that is of course beside the point. It only means my knowledge of it isn’t that good. But I must use it as it is by far the only good way to import buildings into XP and as a scenery content developer, my workflow could have been better.
1. Lights
– I do not know if lights added in 3ds max will be exported along with the model when exporting as .3ds – If it is, well then I blame my knowledge level of Blender, if not will it be an option down the line?
2. Multiple textures per model!!!! I cannot distress how important this is.
I cannot say this enough Ben, X-Plane needs to be ok with having multiple textures on a model or at least Blender. Now I need to make a model, unwrap it, then render it as texture, import to Photoshop and try to fit all on one texture 2k, 4k etc.
This is a horrible way to work and the detail is restricted to the quality of the texture for one but also resizing within. If the building has lots of detail, then packing everything into i.e. 4k by 4k texture file just because X-Plane cannot use multiple textures per building is in most cases very difficult.
Let say you build a house, ok so the building is made up of the roof, walls, chimney, porch etc. Each has their one texture right? Well if one could use seamless texture or substance material using programs like substance painter, well it would be dandy. But X-Plane as far as I know, do not handle this, again one texture per building. And as goes to PBR, I heard a rumour that you guys are implementing separate channels in XP, is this true? For example, can you have a secondary UV channel just for AO?
I see in Blender we can attach multiple texture/images per building, but I do not think the export script make use of this feature for X-Plane?
Well I hope this info can be used, if not keep up the good work 🙂
Hi Tom,
We are absolutely _not_ going to introduce multiple materials/textures per object.
For higher level ‘things’ like an airplane, you simply use multiple OBJs. For the case you described (roof, walls, chimney), establish a global UV map over your object and bake it. The goal is definitely not to have lots of small repeating materials per building in the sim.
X-Plane works well with Substance Painter 2 now – establish a uv map and paint materials onto the right areas.
“can you have a secondary UV channel just for AO?”
I think you swizzled your terminology here. We are strongly considering a secondary UV map for the next version of the OBJ format. This would let you map your day and lit textures differently (for example). As an example of why this is a win: you might have a 2k x 2k atlas of building texture for an airport, but only a tiny fraction have _LIT details. Right now you have to waste an entire 2k x 2k texture for lighting in order to get a LIT texture at the same res – most will be black.
With the second UV map you can make a UV map that covers only the elements with lit textures in the OBJs and use a much smaller lit texture, saving VRAM.
Hi Ben,
I have to disagree with your stance of multi-textures. Of course this would mean a higher draw call, but the end result would be in a much cleaner model. In the case of aircraft, having the wings or fuselage subdivided into multiple objs is rather unacceptable in 2017. One of the reasons why I’ve also been harassing you over vertex animation support for XP12.
You also once said you’d support a uv for “weather maps.” Could you explain more how you would achieve this?
Any chance to introduce 3D texture support then?
Multiple images can be placed “above” each other so they reside in the same texture yet store completely different images, without having to keep track of multiple texture objects at the same time.
I too would like disagree with your not_ever statement about multiple textures, but I do see how this would impact performance and I am all about performance. But can it be done with 3D texture support? Keeping in mind the future is PBR, it also means one extra program to learn. But that’s cool we love that shit 🙂 I do however think an extra UV Map (sorry for the mixup) could be beneficial for texturing game assets. Right now I am adding lights in Blender, then defining them with the Blender script. I have not used any LIT textures yet. So I will now just to test, make a very simple object in 3ds max, unwrap the UV’s and export the collapsed stack/model to first Substance Painter, then from that into Blender and X-Plane to see if this workflow can be utilized. It would as you say provide more detailed texture for less effort 🙂 Not sure if you answered it or not, but is PBR fully compatible with buildings in XP?
Hello Ben,
you wrote not so long ago:
“Our goal is to have 3DS be a first-class citizen for content authoring.”
Is this still your goal? If yes, what is the status of the project?
Greetings from Bavaria
(another) Tom
Hi Tom,
Yes – and – we are doing testing on a major update to the 3DS exporter that Step2sky has done – we are sponsoring this so it can be open source.
Great, thank you Ben…
Tom
I’m a big fan of Blender for many reasons (one being that I don’t have the money to pay for 3DS Max monthly), and I’m happy that it’s treated seriously by LR unlike other sims that just presume if you’re making airports you’re using 3DS or Maya and have $100 a month spare for the license.
Some things that are lacking for me though are:
– Creating lights is confusing and fiddly. It would be really good to be able to use the spotlights in Blender to position and orient a light rather than using a spreadsheet with calculations to get it. Having the lights match exactly as they would appear in the sim would also make baking LIT textures so much easier.
– Animations are still hit and miss. e.g. If I want to make an animated flag (which hides and shows different parts of the mesh), it’s presently really a pain to do, and I always find myself editing the .obj file by hand.
– I find the ATTR options confusing in Blender. Example, if I want part of my model to have culling I use a material for it, but it rarely works properly. Happy to send examples if required (it’s probably something I’m doing wrong)
– The new principled shader in 2.78 is very useful for setting up PBR materials, but it uses Cycles and the plugin doesn’t pick up material settings from it. I like the way the plugin will produce a normal/spec map for you when using the internal renderer, but if you want PBR, at present it’s a manual process of baking out PBR maps and then combining them in Photoshop. I’d love for a way for this to happen automatically based on some material setting.
– When designing an airport, I generally create the entire airport as one scene in Blender. Exporting it though means everything shares the same origin and causes floating problems. For root objects, could it be possible to ask the exporter to treat the origin as (0,0,0) even if it’s at another position.
– Lights: Better support is the next big feature after 3.4 bugs.
– Animation: This sounds important. Can you please submit a bug explaining what you’re trying to do and maybe a .blend file showing an example?
– ATTR Options: One of our goals with the scenery tools is to never have artists need to know or worry about the underlying formats, such as OBJ, apt.dat, dsf, etc. Would it be possible to rephrase this in terms of which GUI options you find confusing?
– Principled Shader: Not enough data to say either way right now, sorry
– Same origin bug: Is this bug (fixed) what you’re talking about? https://github.com/der-On/XPlane2Blender/issues/214
ATTR option I normally just remove from the .obj file 🙂
If not, I found that my models will not show up in WED
I see. Please file a bug when you have the time and I’d love to look at it more
Thanks for getting back to me Ted,
Regarding the same origin bug. I’m not sure this is the same issue. Let’s say I have a ground poly with my airport. I want the draped ground polys to share the same origin (as I’ll split them up). However, when I then start placing 3D objects on top of the ground poly, like a hangar, I don’t want the hangar to have the same origin as the ground polys when I export them out (I’ll drag them into place myself using WED), otherwise they end up floating in the air. For large airports, the origin could be over 1km out which is really undesirable. Basically, I was hoping for a tick-box for each root object being exported that allows the local object’s origin to be used, rather than the Blender’s global origin (0,0,0) origin. For some instances it is desirable, and others it isn’t, so it would be great for it to be configurable, or perhaps some documentation on how to achieve this. It would make authoring objects and painting/baking textures much easier if this was possible.
Principled Shader. This is new in 2.78 and only appeared around 2 months ago. At the moment, I don’t think any exporter uses it. With PBR coming into 2.80 via the Eevee renderer, it might be worth looking into then 🙂
I’ll fire over some examples on github for the other bugs.
Tony
Hi Tony,
The intended behavior is that the root object’s origin is ALWAYS used, so you can control this by controlling the displacement of the root object in your Blender scene. If you want to line up draping, overlap the location of the root objects for every draped element. If you want to have a local origin, just move the root object to that origin.
The missing link is: if you apply an offset to the root object of an object (to get a “local” Y test) you don’t have a good way to automatically position that object in WED where it ‘should’ be except visually.
If visual placement in WED is okay, use draped .pol files for the ground – it’s a better solution over large areas, and just place the objects by eye.
If you really want a “3-d” authoring environment, .agp files are really the useful tool here – they provide exact registration of an object at a point in a draped tile with draped or non-draped Y placement on a per-object basis.
The problem, of coarse, is that the .agp exporter, like many of the specialized v10-scenery-tech exporters (.agp, .fac, .net) is Blender 2.49 only, which is pretty useless going forward.
Thank you for the encouraging information. I have used Blender for years and gave up fairly recently because the plugin for turning 3D creations into X-Plane objects required a version of python my new apple mac could not use. Now that time as gone by I assume this is rectified. I will try again.
I also wonder why its still called xplane2blender when as far as I can see it no longer does what Marginal’s original script did and import x-planes to blender. Perhaps it should be called belnder2xplane?
Regardless of copyright problems there are good reasons for importing a plane’s overall structure into blender, not least is to make add-on objects that actually fit to scale and position. I’d like to do this for a belly pack our Maltese AFM uses on its Kingairs. Personally I like to make CSL objects too – but I know you already discarded the obj 7 CSL obj format for the new obj 8 format meaning that x-plane fly-in participants will get fewer and fewer CSLs as time goes by. Unless the xflightserver is updated of course 😉
XPlane2Blender is indeed poorly named by now. It was hoped to have Import and Export, but export is what got started on and was more needed. Import has forever been, set aside. Renaming the project would cause a mess of confusion that really wouldn’t be worth it.
If you want to turn OBJs into Blender files you can jump through a series of toolchains and 3D importers and exporters with varying degrees of success, but I know that is hardly a replacement for a good solid tool.
I’ll make a note of the name change in the manual, thanks
On Python issues: Firstly, I’m surprised by this. Blender comes with its own internal copy of the Python interpreter, and XPlane2Blender runs on it. Secondly, could you describe, or better yet file a bug (https://github.com/der-on/xplane2blender/issues), what version of XPlane2Blender, Blender, and macOS you have?
OK I will try to do that even though its a well known issue with older python versions and MacOSX after 10.9 I think. I first came across it trying to get Marginals scripts running in Blender 2.49 which require python 2.6. Any version below python 2.7 will not install in MacOSX 10.9 and above (I think). Well the precise numbers elude me but the upshot is that marginals scripts never ran in newer Macs.
Trying to get the older blender models into a new version with scripts for xplane that work proved to be impossible. The solution is to start all over again.
Not optimal.
Unfortunately I gave up and my efforts on Concorde remodelling stalled for a long time.
Good news: a Blender2.49ToBlender2.78 script is a planned feature (unfortunately lights will be worked on first). Your work in 2.49 will not be lost forever!
I cannot comment on scenery as I do not make any. I just Build planes. I’m not one of these guys who advertises on the Third-party websites. So therefore my work goes largely unnoticed But it is substantial.
Having said that let me apologize in advance, But I must say under no circumstances can I bring myself to use blender. The user interface is just to Foreign. And I have no interest in learning keyboard commands and simple point-and-click will do just fine as it does in every other program. That’s not to say I haven’t tried, I have, repeatedly. But there’s no nice way to say this “Blender Is Not Intuitive.” I cannot make heads or tails of the workflow in comparison to tried and true 3-D programs such as Max and even AC 3-D.
Also, I Must agree that we need multi-texture objects. There’s But so much you can do with single large textures. Especially in the area of liveries. An example I can think of is creating a polished aluminum leading-edge with a painted wing surface, such as found on Blue Angels Jets. If you break those UV’s out and texture them separately Then that leads to other issues when painting the aircraft in normal military colors.
I personally would like to see more development go into plug-ins for Max and for AC 3-D. In any event, I also agree that documentation is key and it is sorely lacking with a lot of these plug-ins. And what is available is actually confusing with not enough real-world examples.
Anyway, that’s my Two cents, Ben.
As always, thanks for the great job you’re doing
yours truly
Jim
JazAero Designs
https://www.facebook.com/JazAero
Hi Jim,
I do not want to derail that blog but I tried Blender 3 times and I quit 3 times.
Yes, it was interface.
Then 4th time, I started reading here and there, watched few tutorials and things slowly started making sense.
I am not going to compare or criticize but for an average developer like me ( 3D modeling, UV mapping and exporting to XP) Blender is a perfect choice LR choose.
3DSMax is simply too expensive for majority of users and even developers.
Blender has much more tools than ac3d for efficient modeling, making and checking UV maps ( showing stretching, hiding certain vertices and many more)
I perfectly understand and respect other opinions but I am very happy LR picked Blender as a main 3D modeling platform.
Excellent job Ted on documentation plan and excellent job the whole LR crew for working on final version of the exporter!
BTW Jim, Ted wrote that blog 😉
Hi Andrzej,
Ted wrote the blog, but Jim is railing against my “one-texture-per-obj-forever” stance. 🙂
The truth is we have multiple textures…it’s just done by having multiple objects…and the logical way to heal the pain of this is to make the tools (Blender, etc.) more able to cope with the deployment tech (AGPs, DSFs, .acf files).
But I do strongly think that having the OBJ/texture/material configs be _highly visible_ to authors is very beneficial — if you could just make whatever soup of materials you wanted with no way to know what the final OBJ output is (because the tools would just cut everything into a million OBJs as needed) it would be really, really hard to ensure that things that have to be fast actually are fast.
Ted wrote the blog, but Jim is railing against my “one-texture-per-obj-forever” stance.
Yes, was not reading carefully, sorry.
As someone who creates aircraft for X-Plane as a hobby, I prefer Blender due to the fact it’s (a) free, (b) feature-rich, (c) cross platform and (d) the source code is available. Yes, the interface can be clunky in areas, but I haven’t seen a 3D software package which didn’t have a learning curve. There are many video tutorials on the web describing how to use the various features of Blender, which is how I approached the package. Patience is key. I took notes, jotting them down in an easily searched text file, using my own phrases/terms to help me learn. When I released my BD-5J for X-Plane, I included the Blender and Gimp files used to create it so others could learn and help expand the X-Plane ecosystem. As far as I’m concerned, Blender is adequate for my needs.
Glad Blender is working out for you. Do you have any suggestions for the XPlane2Blender Manual?
Not really, no. I have to admit I’m still using the older v3.20.14 with a minor modification for Blender 2.78c, but I took a look at the v3.3 documentation anyway. I find it a bit disturbing there’s no screen captures (i.e. all the images are little question marks indicating file not found). It also has minor spelling errors here and there. Generally I’ve been able to understand the XPlane2Blender documentation, though. I don’t expect it to teach users how to use Blender since there are plenty of other resources for that. The older v3.2 documentation was sufficient for me to understand what settings carried over from Blender into X-Plane object files via the script. I don’t know how typical I am for your audience, though. I’m a software developer who works with OpenGL daily, so the terms and ideas are quite familiar. Those with less 3D experience might be overwhelmed at first simply because there is so much to learn.
Hello Ben,
Are there any plans to update the AC3D plugin with the new features of the blender exporter?
thanks!
Laminar Research does not have plans to do this. Andy Colebourne offered to take over maintenance of the ac3d exporter – I do not know what his plans are for it.
Guys let me say that you are doing a great job with this exporter and the way you build and introduce the new version.
I’m confident that we are getting a stable and backward compatible release (I’m contributing on the beta tests).
As a professional developer, I’ve learned how vitally important a reliable exporter is.
Blender is a great tool for many developers free, part time or pro. Open, powerful and with a great community and tutorials.
Suggestion for the manual:
+ Complex nested bone animations (landing gear)
+ Multiple SHOW/HIDE animations for one object
+ Lights (cockpit and outside)
Best regards
Florian
COLIMATA