tkyler

The primary thing to keep in mind here is the concept of "math modeling" of a behavior. When any engineer decides to model something mathematically, they will have to make choices about how to go about doing so. The "x-plane approach" is a sound approach, but doesn't guarantee that Austin has yet implemented any given feature or relationship accurately. For example, ground effect due to air compression. This is something that Austin might choose to 'approximate' by altering aero forces close to the ground. He might come up with some heuristic function relating wingspan to lift and apply that to his equations. We may find that his choice of model was lacking for some reason...perhaps he was in a hurry or didn't feel like digging up research or thought "this is good enough and nobody will know"....and in such a case, we might seek to alter that behavior to get even more accurate. Just because Austin wrote the code does not mean that adopted the correct math model for a behavior. So we feel we do not go against the x-plane philosophy, but rather seek to improve the areas that Austin has yet to either get to or has no interest in getting to. So for any given behavior, usually the first thing we do is assess how well x-plane simulates something....and if it comes up short, then we try and find ways to improve it. Being that we are multiple guys working on one project (as opposed to Austin working on 3 or 4)...then it's more reasonable for us to spend lots of time fixing one area while Austin is dealing with dozens of other issues with mobile or his VP400 AP system, etc. The challenge for aircraft developers is to assess x-plane and making note of what it does well and what it does not do well. Austin is not interested is absolute accuracy across the board anymore and is content to let 3rd party folks customize it. I give props to the relevant Laminar team members for at least providing a way for folks to simulate that which Austin has elected not to via the SDK. TomK Laminar / IXEG

That is a heavy topic best suited for another section Michel, but in general, yes, x-plane computes forces on elements based on the geometry....but as you surmise, its a very "first pass" approximation and the "geometry part" only applicable to a narrow range of the entire model. It is my opinion that there is a perception that if one enters highly accurate information across the board, that x-plane will handle the rest, which means that if once can simply access such information, then anyone can make a high quality model, which is why we have people with naught but 3D experience building flight models. What x-plane has is a "series of methodologies" for simulating certain aspects of an aircraft. Forces on elements uses one technique, BEA or FEA if you will, drag another, slipstream effects another, etc and each technique has limitations, assumptions and approximations. There is no guarantee that the technique that Austin has decided to use is the best to represent a certain behavior, he may have been in a rush to get XP out the door.....but by understanding it, we can 'bend' it if we know the real underlaying physics and that's what we do at IXEG. Understanding of not only the engineering principles behind any given behavior, but also numerical techniques or state models to approximate such behavior are a pre-requisite for getting really good results IMO. CFD goes to the n-th degree (or can), calculating complex flows from N-S equations that x-plane neither seeks nor needs to do. In typical numerical element modeling, one always has to choose a "convergence level" that is good enough and this is what x-plane does. it's a 80 dollor sim and is as good as any sim for basic flight simulation. A few examples. The geometry of the aircraft is suitable for caculating force vectors on elements against relative airflow, nothing more. It is not suitable for momentum effects, gyro effects or parasitic drag effects or vorticie effects. The mass model is simple a 3D matricie of point masses which is suitable for calculating momentum, but has to make "guesses" as to structural densities or "common equipment" and therefore only approximates moments of inertia. The slipstream model makes assumptions about conservation of energy and prop efficiency and applies a simplified forcefield to the wing elements (but not fuse elements), etc. So the whole is a collection of parts and while x-plane will handle about 70% of the workload for you simply by entering information, getting really good performance and feel means having a deeper understanding of how x-plane goes about its business and then using some programming tools to try and pick up the leftovers. Having experience in numerical methods myself, I can usually guess how Austin might have chosen to do something, but I have called him on a few occasions to find out what's he's done. The bottom line here though is understanding what x-plane is and isn't trying to do. X-Plane isn't trying to be a CFD tool, it isn't trying to be aerospace design software...it's a recreational flight simulation that uses a reasonable engineering model to simulate flight that has some pros to it that lots of folks like, including myself. TomK

It's a brilliant static reflection by Nils....until such time as X-Plane gives us dynamic reflections....which will happen some day. A lot of the "plastic pieces" in the cockpit have subtle reflection effects done by Nils also and is one of the major reasons the cockpit feels so immersive. TK

I can't speak for those having not tried all of them, but we have taken stock of all the current offerings out there, their level of 3D animation and texturing and believe we have some cutting edge stuff for sure, we certainly like where we are with our 3D immersion. We also interviewed several ardent users of PMDG products and we demonstrated it to a few folks at the AVSIM Fancon conference and was received extremely well there. It will ultimately be up to users though to decide how we stack up. This is our first effort after all and there are some challenges remaining that we have yet to see how we'll do. All we know is that we want to feel like we're in the real thing for every possible sensation we can cram into it and though time is important, getting it right is moreso, and being a 737, we don't have airline food, but if you keep a close eye on the AC ammeter gauges shortly after takeoff, you might catch some evidence of the coffee maker being turned on TomK

It wouldn't be a study sim if they didn't eh? That's the easy stuff TK

An exterior shot.

I agree too. I like HDR on at night, but not during the day. Not sure why though, haven't really thought about it, but if we can come up with the "why" in specific terms, we could at least make points to Ben Supnik about it. TomK

Thy, I think you misunderstand x-plane's lighting engine and how it works. Prior to x-plane 10, there was no "real lighting". LIghting effects were faked through textures and there was no "real" lighting at all. With HDR rendering on, x-plane can simulate "real lights" that cast glows on objects. So while HDR isn't required for good night lighting, it is required for realistic looking lighting effects. Texture based lighting effects require a lot more work but have the downside of never shining on anything. If you taxi an airplane underneath a ramp light with no HDR on, the plane will remain dark...not real. The best lighting work by a scenery author will combine both technologies but some authors choose to only use HDR light effects, which is limiting for those without HDR on like yourself. You are mistaken for blaming x-plane for it though. What has NOT moved forward as much are folks computer hardware, but such is the computer world. Nobody uses rotary phones anymore and nobody complains now, but for a while they did. Same here. In the not too distant future, HDR capability by all video cards will be the norm. I've tried my sceneries with the latest version of XP and HDR works fine, everything works like its designed to. TomK Laminar

NEWS UPDATE: Hello gents. For the last several months, the MU2 has been pretty much ready to roll but has been waiting on some gizmo functionality to be implemented. The scale of the latest gizmo 13 update has been staggering what with new features and also the transformation to 64-bit....and this is what has resulted in the wait. We are getting very close to the point where Gizmo 13 has been stabilized and though I know a lot of you don't necessarily know it, the wait will have been worth it for what it means to development for gizmo adoptors. For us developers, what we are seeing from Ben Russell and gizmo is staggering in its power, speed and flexibility and will allow us to rely on other technology less and centralize all our customization into one location. Ben R had a vision that he's stayed true to, preached and brought to fruition and it couldn't be more exciting for the future and I have been happy to wait though I know others have not....but nobody said growth was easy. I believe in the gizmo vision not only for me, but for what it means to the x-plane community in terms of creating higher quality simulation experiences and bringing products to market much faster that in years past. The tech that the MU2 has been waiting on is currently in development and undergoing testing from what x-aviation says and some initial testing of those features on the MU2 will hopefully transpire within the next seven days. Upon successful completion of those test, then it will be incumbent upon me to undertake one final programming task on the Garmin 330 with gizmo and then the 1.5 update will be ready. When? Of course I won't say, it may be 6-8 more weeks....I have yet to schedule it in, but we are indeed seeing the light at the end of the tunnel...and no it's not a train. TomK

I'm not sure of the cockpit only as it's comprised of several objects but the whole of the project: fuse, cabin, engines, everything comes in just shy of 500,000 tris before any optimizations. I'm estimating we'll end up around the 600,000 tri mark when it's all done as we are winding down the 3D and there's not much left. TomK

Lets go a little bigger: https://dl.dropboxusercontent.com/u/955680/aw2.jpg https://dl.dropboxusercontent.com/u/955680/aw3.jpg and one here in the forum:

Possible? possible? More like, PROBABLE! You are very right and I was very wrong in writing that...good catch. I changed it so others won't be misled. Those look really great...good usage of your light and I'm glad you are up and running. As far as the lights being on in the daylight, ...instead of using "full_custom_halo".....use "full_custom_halo_night". These have their daytime parameter set to zero so they do not show during the day. You are very welcome. I hope to have my x-plane training school up some time in 2014 and be able to teach all sorts of stuff. Tom K

Cekko, that particular line from the lights.txt file DEFINES a named light. The actual line written into an object file would be slightly different. In an object file you would have the following format: LIGHT_PARAM full_custom_halo X Y Z R G B A S dx dy dz F The first 3 values, X, Y, Z is the physical coordinates of the "bulb" in meters relative to the origin of the object. The next 3 values, R G B represents the color of the light in Red/Green/Blue format. a white light is (1, 1, 1), a red light is (1, 0, 0), a green light is (0, 1, 0) and so on. These values are also normalized so you may also use the format (255, 255, 255)....which is a very common way among "color pickers" to represent RGB values....which numbers you use depends on the color picker tool you use. The following site: http://www.colorpicker.com/ Uses the values 0 - 255 for rgb color values....I myself use the 0-1 range because the color picker I use gives me those values. Ok, onto the next value, the 'A'. This is the alpha value which basically causes a "dimming" of the light and goes between 0 and 1. Most of the time, there is no reason to dim a light, so generally leaving it at 1 for "full brightness" is OK. The next 3 values, dx, dy, and dz represents the direction the light points. I cover this in a post above. The final value is the width of the light and should be a value between 0 and 1. 0 is a special case and represents a "omni bulb" or "point light" that shines 360 degrees. The number 1 represents a "zero width beam" or no beam at all...so you never use a 1. What this number actually represents is "cos (0.5 * light_beam_angle)" So a light beam 110 degrees wide would use a 'F' value of (0.574). When all is said and done, it would probably look like this in your object file: LIGHT_PARAM full_custom_halo 0 20 0 1 0.463 0.176 1 30 0 -1 0 0.71 The above light is 20 meters above the ground. It is the same color as my sodium floods (R:255, G:118, B:45) OR (R:1, G:0.463, B: 0.175). It shines for a distance of 30 meters. It shines straight down and it is a beam 90 degrees wide. TomK

Projected 2013. Mid fall is my best guess, but that's an unofficial guess, not a company statement. My wife is going to get pretty angry if it isn't darn near close by then. TomK

Thank you Cekko. I have always been around here at x-pilot and barring some medical issue, always will be more than likely. Feel free to ask anytime. I am banned from participation at the org, which is why you see no posts from me there anymore. I would that I could answer a lot of questions for users over that I know the answer to but unfortunately can not. You can replace my sodium flood with another named light called a "full_custom_halo" where you have no billboard, it takes nine parameters. I'm heading out the door, but will elaborate on this more in a few hours. TomK

Cekko, Unfortunately, there is no way to disconnect the billboard from the sodium lights as they are permanent. It was not this way in the beginning, but they were made permanent to be consistent with other lights. What I would recommend is that in each of your "multi-lamp poles" , you put in one spill light, set where any of the normal 'bulbs' would be....and 5 billboard only lights at the other bulb locations. The spill light would be a bit off-center in this case of course, but you can tilt it a bit and widen its light cone to conceal it. If the light pole is tall enough, nobody will pick up on it anyhow. Regarding the coordinates. in X-Plane: +x = east, -x = west, +z = north, -z = south, +y = up, -y = down. In addition, when it comes to lights, there are two sets of coordinates. The first is the lights physical location in cartesian space, and these numbers represent meters....and second are unitless "vector coordinates". A vector coordinate for (x, y, z) of (0, -1 0), given the above relation would represent a vector pointing straight down. (0, 0, 1) would be a vector pointing directly south. (1, 0, 1) represents a vector pointing to the South-East....(1, 0, -1) to the northeast....(0, -1, -1) would be a light pointing towards the north and at a 45 degree angle. Internally, these vector values are normalized so (1, 0, 2) is the same as (50, 0, 100) or (0.5, 0, 1). So as an example, let's use my tall sodium flood light with 3 bulbs Here's the param lights lines from the object file. LIGHT_PARAM sodium_flood_BB -0.4755 22.6079 -0.0475 -0.20 -0.71 -0.67 8LIGHT_PARAM sodium_flood_XYZBTSS 0.0059 23.5864 -0.1224 0.0 -1 -1 1.0 50 0.57 8LIGHT_PARAM sodium_flood_BB 0.4797 22.6038 -0.0444 0.20 -0.71 -0.67 8 Above, there are two billboard only lights and they cast no spill, they only have the lens flare billboard effect.....and also there is just one flood light which does cast a spill and also has the billboard lens flare. The flood light and the billboard only lights all have the same size billboard so it looks like all three lights are on when viewed in sim, but only one is actually casting light in xplane. The sodium_flood_BB lights have 7 parameters, (X Y Z dx dy dz size). The first 3 are the physical location of the "bulb" in meters....and these values are relative to the object origin. Note that the big value, '22.6079' is in the Y parameter....so that means the bulb is 22.6079 meters 'up'. The next 3 values are the vectors, dx, dy, dz....and the last value is the billboard size, but as I mentioned, these are now hardwired and the value of '8' doesn't do anything. So looking at the dx, dy, dz values of the billboards, you'll note the dy value is negative...meaning the light is pointing down...BUT it also has a rather large z value of -0.67 which means the light is pointing towards the north almost as much. This is a apron light that throws light out onto the apron away from the light pole so these values make sense. There is also a small dx component on the billboards because for a 3 light pole, the side lights point a bit to the side as well as outward and down. Now when I say "north", that means the directionality of the light when it has no rotation value in WED. If you were to click and place a light in WED and not rotate it, then these values in the object file could be considered, "default directions". Of course you want to rotate the light if you need to point it into a particular direction. I designed my directions so a user drags in WED in the direction they want the light to point so it would be somewhat natural. For the flood light itself, ..._XYZBTSS. The first 3 values are the physical location of the bulb, X, Y, Z. The next 3 are the direction this light points, dx, dy, dz and the last four values are the BRIGHT / THROWS / SPREAD / SIZE. Ignore size...its that pesky billboard that you can't change. The '50' is the distance the light reaches in meters...beyond that value there is no spill effect in sim. You can up that to 100 or whatever you need. The spread, '0.57' is how wide the beam is. The lower the value, the wider the beam. Acceptable range is between 0 and 1. So for your six bulb situation, I recommend your suggestion #1 above.....I could see something like: LIGHT_PARAM sodium_flood_XYZBTSS ...bunch of numbersLIGHT_PARAM sodium_flood_BB ...bunch of numbersLIGHT_PARAM sodium_flood_BB ...bunch of numbersLIGHT_PARAM sodium_flood_BB ...bunch of numbersLIGHT_PARAM sodium_flood_BB ...bunch of numbersLIGHT_PARAM sodium_flood_BB ...bunch of numberswhere each lights dx, dy, dz value is (0, -1, 0) as I assume they all point down; however, if each bulb points "outward" at all, then you have some trig to do! Below is a little reference I kept handy in my blender files early on. I do NOT know if the coordinate system in AC3D maps to x-plane in the same way as blenders and you might have to experiment a bit, BUT I believe that BenS made it so when you look at your 3D model in a top down view, that "screen up" is "object north" AC3D users correct me if I'm wrong please. TomK

I haven' compiled the Falco plugins to 64-bit yet Larry. Dealing with 3 operating systems is a pain...its the main reason why we're all wanting to go with gizmo and we wont' have to deal with that kind of stuff. I suspect I'll get to the Falco at some point. I have higher priority things that I must manage first though. TomK

There are two ways to do it. One is to use blender (or any 3D program that supports baking) to bake a reflection map. You need a little experience with "environment mapping" to get the best results and there are also some camera angle considerations as reflection calculations are camera location dependent. The second way...the one we use is more customized for our needs. We use a combination of normal maps and our own specialized environment maps and we have written our own program (Nils did actually) to merge the two into a customized reflection map that gives superior results than blender's basic baking. For basic exterior reflections though, blender is more than adequate. http://en.wikipedia.org/wiki/Reflection_mapping TomK

Not in their entirety, but maybe a few initially. At least for some of the major busses. There are some very interesting cases where one can disable a bus with a breaker and achieve a particular goal, especially with respect to the hydraulics as we simulate many electromagnetic relays that are attached to various busses, so disabling busses and setting switches in a specific combination can be used to accomplish things in emergency situations. Our systems are coded such though that we can insert a breaker into the "virtual circuit" very easily for lots of things. We are currently texturing the cockpit shell and as we come across each breaker label, we will probably make decisions about which ones to simulate based on how relevant they may be in our operations. In normal operations you never mess with them of course so what will most likely transpire is we might simulate only a couple initially, but later write a failure module and perhaps we'll add circuit breakers then. TomK

All custom datarefs created in Gizmo are registered automatically during their creation. All of ours are prefixed with "ixeg/733/" and easily identified....but we will probably need to provide descriptions of many of them at some point. That will be a dedicated effort after release when I start working with cockpit builders. TomK

Ok, the above quote came off the org, but of course I can't answer there and a lot of 737 questions I do have answers for. Really really curious folks should ask here in this forum FYI. "Not decided yet" means "we haven't decided because its probably easily done and we can wait till the end to think about it as higher priority stuff remains. As far as months away from release, that is true no matter the "not decided yet". We are not going to rush this thing out the door in a "hurry up and lets make some money" manner like I've seen other products do. IXEG is, without a doubt, of the "success through quality" mentality. You no happy...we no happy! One thing in this business that I have learned is that it easily takes several months AFTER the aircraft is "finished" just to do bug chasing, installation checks, finish up the documentation, get the marketing materials ready, set up the web sites, etc......so we are definitely several months away no matter what. How many months? I don't know. We are moving along very well though as you can see and you should see more screenshots and the occasional movie along the way. One thing is for sure....once it begins to look "finished" from the screenshots, then we will still be a few months away as we make final preparations....but at least on that day, it will be closer than it is on this day TomK

cockpit texturing is currently underway, that's the best we can say for now. Tom K

Cockpit building is a big deal to me, probably moreso than the rest of the team. Though not currently active building one, I certainly want to get around to it as soon as possible. I'll be attending the AVSIM Fancon in a month and talking to cockpit builders to get their experiences and feedback. We have very much structured our simulation design to be "cockpit builder" friendly though and providing / sharing datarefs is very easy, indeed creating new ones just for cockpit builders is probably not too heavy a task. Expect us to get the product out and have to wait for a bit so we can work out any bugs.... maybe a few months and when customers are getting solid reliability in their installations and operarations, then I will most definitely turn my attention to cockpit builders to see what their needs are. TomK

Hey Mike, I'll jump in on this one. We have all discussed internally "theories" regarding documentation for the flight sim market. One approach is to basically copy the AOM. For us, this implies that if it's in the AOM, it must be in the sim and despite marketing claims of many companies, very rarely will everything in the AOM be in the simulation, probably barely half in most cases. Most developers are willing to take the risk that customers won't go in so deep as to discover where they come up short and would rather have the marketing value of saying, "our stuff is so real you can use the real AOM". Going this route means either copying a whole lot of info or licensing the information, which is usually quite overwhelming in its breadth. We have good perspective with Jan's consultation because I believe even he will tell you he doesn't read all of the AOM that close and indeed MANY times, we had to read it together to find out how to simulate something exactly. So we asked ourselves, "what satisfies best all levels of simmers" and here is where we are now. We will be writing our own documentation that is a slimmed down paraphrasing of the AOM but not necessarily light. It will follow the AOM roughly but it will also contain product specific stuff of course for installation mumbo jumbo and the like. We'll have a quick start so users interested in instant gratification can get some satisfaction. We will back off somewhat on explaining in depth how systems work and focus more on how to work the systems from the pilot perspective. We believe this will satisfy the majority of the simmers out there. We might include less information initially on backup and standby systems which most simmers won't get into. Now for the hard core junkies, we feel that being hardcore junkies, they either have the AOM or know where to go get it as they're not too hard to find. So the question we asked ourselves in this situation was "what if a hardcore guy gets the manual and puts on thick glasses and goes over it line by line". In that case, we said, "well our sim should try and handle it". So we use the AOM to develop the sim as best we are able with our resources but we will not ship the same volume of information as the real one. So what you will find shipping with the sim is more basic descriptions, typical operating procedures with paraphrasing of the AOM; however, becasue we simulated it according to the AOM, we have some overhead to grow and expand and I think over time, after release, we will certainly consider adding a supplement to the documentation based on feedback or include more specialized stuff, but even for us we have to ask, if it follows the AOM exactly, why not just include it? Our final response to that is that most simmers, ourselves included, don't want that volume of information to have to wade through to find info. This is a entertainment market and not a high risk liability market and therefore the documentation needs are different. We want documentation that caters to what customers will be doing most often BUT if one desires more info, then yea, grab the AOM somewhere and knock yourself out because if it's in the AOM and our sim doesn't work as described there, then that is fair game for questioning. We may tell you that we voluntarily chose not to simulate a feature, but we may have missed something also. We use the AOM to guide our programming so we are game to look at it all. All that said, it market demands dictate, we may eaily change our minds after some feedback and it's not like adding the AOM to the download package is a big deal, only a big licensing cost TomK

nevermind TomK