I’ll have Sven post with some plugin updates soon after he gets settled in after his latest move. That is where the real magic is happening.

Alex

About a month ago Alex was looking at the 777 operators list on wikipedia. Back when we really got into the project, the 772ER was the most popular variant of the bird flying. The 777-200LR (77L) and the 777-300ER (77W) were in their infancy. Turns out that over the course of just a few years, the balance has shifted. By far the most popular version with carriers of the 777 is also our favorite, the 77W (now this is in terms of orders…there is a lot of backlog). We’ve wanted to get a move on with some of the other variants for along time now and these new figures gave us just the excuse that we needed to get started on the 77W conversion. The modifications also open the door to the 200LR and 200LRF to complete the entire 777 line.

Our release schedule is still going to focus on putting the 200ER out the door first, but we thought it worthwhile to share some of the new stuff with you. The stretch has also given way to further refinement of the details including wing components and landing gear components. More importantly though, we’ve got brand new GE90-110B and 115Bs, modeled from the ground up and detailed to the hilt. There is a little bit more work to do with the engines obviously, but they are at a point now where they’re pretty enough to show them off.

Keep in mind that this is just a future development announcement at this time. Our full time priority is still the 200ER. We’re going to put up comprehensive 200ER progress report sometime next month (which consequently will all feedback into the 77W anyway…gotta love parallel development). You want it, and we want it. With that goal in mind, its a no brainer ‘win win’ for all of us.

Some images. All white areas are areas are where new geometry has been applied or old geometry updated. We’ll get to texturing the new stuff in due time.

From all of us at XPJets, enjoy!

I’ve been working on some new developments that we’ll announce shortly, but long story short, I’m building and having to animate more complex systems. And in order to do it to the fidelity that I like, it requires keyframes, and lots of them. I do believe that the 777 gear all is roughly 30 keyframes per strut just in the retract and extend cycles. All of the scissor drag links are a royal pain as I’m sure many of you out there in dev land know. To get to the point, I have rediscovered inverse kinematics. By adding IK constraints to my armature rigs, I am able to forego manually setting up animation strings, rotating each bone a few degrees and praying that things all will still line up keyframe after keyframe. Now all I have to do is define how the bones in my armatures should behave in relation to each other and other geometry. The biggest advantage to this is simply the time saved in order to pull entire complex systems together. To quote Mr. Spock, “Admiral, if we go ‘by the book,’ like Lieutenant Saavik, hours could seem like days.” Now I’m not going to elaborate on the technique specifics in this post. I’ve just been playing with stuff in my test files and I’d rather have something 777 related to show it off with. Stay tuned for Blender tricks part 2, and developers, I promise, if you’re not doing this already, you’ll like it It turned my animation world upside down when I found out how to overcome the last few obstacles. Happy building!

Cheers!

Alex

Then you have the did I just do that moments where the answer was staring you in the face for hours. A new train of thought later and the results are better than what you could have hoped for. Yes, I may be waxing poetic a bit, but I had one of those this evening, and I’ll get back to it momentarily. I’ve actually had several over the past week. I’ve just started really getting into texturing the 3d pit of the 777 and its already been an experience. Some of those moments are just learning new facets of the tools that we rely on to do our work. Some of it is realizing that I can bypass some of the export limitations and achieve greater resolution in my object file for more precision in the geometry where it is needed. Some of it is finding new software to help out what used to take much longer to achieve. Others are techniques conceived in conversations with my colleagues to get past those brick walls that we inevitably run into every now and then. I’m always amazed that the small stuff is harder than the big stuff. I know that some of you are waiting for ‘thee to get to thine point’, and yes, I know that my rambling probably isn’t the most interesting thing going on in cyberspace.

I suppose that my point is that even after years of playing around with this, the sim and the development process still has the capacity to frustrate and surprise you. This evening’s puzzle was how to texture the gear handle knob. Its a semi translucent piece of plastic or acrylic. I found that it is not a straightforward process because most of the light scattering happens below the surface. In the right circumstances, this object can appear to be illuminated from within below the surface. While its likely that you could hand texture the knob to some degree of convincing success, I wasn’t convinced that a simple texture was going to be the solution. How the mesh is unwrapped is nearly as important as the material used to render out the texture. Its shaped like a wheel yes? Okay, so what do we do? You can treat it like a hub and wheel situation with two disjointed pieces. I’m not a fan of the texture split for solids like this. Spherical unwrap gets closer, but there are fiddly bits where the effective texture resolution is zero on the wheel due to the unwrap. Long story short, the wheel ended up being unwrapped as a hub projection with a series of concentric rings radiating from the center. Unfortunately, this solution ultimately cut out the easy photoshop option. I had to dive deep into materials and try my luck at achieving the appropriate level of internal refraction. Lets just say that for hours I struggled with this. Nothing that I did ended up looking convincing. Achieving that perfect, to quote the ever quotable James May, “boiled sweet” look was looking increasingly more and more distant.

So after dinner and a drink, I’m back with the same problem. More test renders and hours pass and I’m still no closer to finding a solution. After some research and digging online, I came across a great website. The Blender Open Material Repository turns out to be a great resource for materials. I’d recommend it to anyone having material and rendering issues. I found an acrylic glass material that I felt I could adopt and modify to serve my needs. Those aha moments, well, analyzing this material’s attributes couldn’t have been more helpful. The render bake went more or less well, followed by some touch ups in photoshop and finally I felt that I had a reasonable base…plenty of diffuse illumination throughout, nice strong highlights where they needed to be etc. Never one to leave anything well enough alone, I took some ideas that Josh had during a conversation today to heart and well, can I say little victory? Imagine if you will a semi transparent doughnut inside another semi transparent doughnut inside another semi transparent doughnut. The result is going to allow you to see specular highlights from within the external mesh. Done carefully, you end up with a transparency gradation that mimics some of the refraction that happens inside the actual handle knob. Victory or not, the fact of the matter remains, this ended up being alot of work for a gear handle. I could easily have gotten much more done on the cockpit today had I just left it and let it fester for a while.

This small victory…literally at just 3 cm in diameter, is one of many that I’ve had, and one more checked off in a line of ideas that haven’t been had yet. Some you arrive at easier. Some are a little more involved. This knob was was especially involved. My whole story may seem a bit anticlimactic, perhaps a touch anecdotal, and in the grand scheme of the cockpit, it really is. However, small victories like these propel developers in new directions. New ways of thinking about things are vitally important. It makes the end result of what we’re working for that much better. And thats why I’m posting. In the name of innovation, small as it may be, it all builds on itself. If I can spread some innovation around, then I’ve done my job. If people can inspire innovation in me, then they’ve done their job. Having said all of this, I am going to attempt to keep this kind of blog posting alive. It gives all of you a sneak peak into some facets of the process. I get to tell a little bit more of my own story in hopes that maybe the community can get to know one of their fellow devs a bit better.

So a little long winded? Most definitely. Informative, insightful, or helpful? I hope so. And as you probably guessed…a little preview of tonight’s small victory. I for one am looking forward to seeing how this gear knob acts in the sim’s lighting.

Cheers

Alex

Cheers

Alex

I’m waxing poetic geek right now, but there are three solutions to the cockpit text problem that I can work out. First of all is to texture all of the panels straight on with a white texture basis for the text. This works for several things, but not when you need to isolate interior illumination from the backlit textual illumination. Admittedly, it is far easier to shade this text with shadows and the like which is a plus. Second is to texture the letters in the same regard as above, but use an alpha channel to do it with, so that there is a ‘hole’ in the panel where the letter should be. A polygon behind the instrument provides the backlighting. I’ve seen this used and have thought long about using the technique myself. The problems though are identical to those from the first solution. The resolution required to have sharp letters in the 3d cockpit environment during all times of the day is far too high to be productive. I’ve also noticed that while the letters may be crisp during daylight, once illuminated at night, the effective crispiness drops and the cockpit text becomes very difficult to read. Again, this can be solved by upping the resolution to very high levels on all of your textual panels. The third solution is to do away with textured text of any sort and draw it out using polygons. If you’ve been following the Comet project, you know exactly what I’m on about. I’m trading textures for polygons and so far I like the results. While this process has its ups and downs as well, I do feel that for large cockpits like the 777s, with lots of space and surfaces, the polytext solution is going to be the best all rounder, with limited use of the first solution for non back lit placards.

While I can’t take credit for the idea, I am going to throw out a big thank you to Guy (guym-p) for the inspiration!

Having said all of this, just because our text will be nice and sharp doesn’t mean that we’ll be skimping on cockpit texture resolution. It just won’t have to be near as astronomical to achieve the clear legible quality that we want and we can better spread that quality throughout without having to spend huge amounts of VRAM just on the instrument panels. From my perspective, this really is a win win for all of us!

The reason I bring this is up is that I fired up the sim to get a feel for how the process was working and to see what kind of look I’m going to achieve. I was pleasantly surprised when I was greeted with this…and even more pleasantly surprised when I noticed that framerate wasn’t effected. Its amazing what a little text can do to completely change the feel of the cockpit environment. Definitely thought that it was worth a share!
Keep poking around in the gallery as I’ll do my best to update it with panel shots during the texturing process on a semiregular basis.

If you want to go straight to the HD version, click here.

I’m off to bed for now, but its the AP panel and overhead tomorrow. Once we’ve gotten this all hooked up to light level rheostats, this will be a happy place.

Alex

Let me just, not to steal the phrase from Apple, lift the reality distortion field surrounding x-plane developers, especially us here at XP Jets. Most of us, and I do believe that I speak for the majority of us, actually work for a living or are in school. For those of you who haven’t gone to flight school, Dhruv spends an extremely large amount of time flight instructing, building hours, and doing his own advanced studies. I wish him the best as he’s going to graduate in a couple of weeks. As for me, I’m an art student. I spent more time in the studios than the house that I pay rent to live in during the course of the school year. I for one bit off more than I could chew this semester. There were many a day when I didn’t even come home. Add the fact that both Dhruv and I have bills to pay, well, we had to make money somehow, so we work. Its the problem with x-plane development on the high end. Yes it will pay dividends in the end, but not while we’re working on it.

Admittedly I’m a little spooked by the prospect of the 777 from ramzzess on the org beating us to the punch. It was the kick that has sent all us off of the diving board. We’re getting wet whether we want to or not. I’ve opened up Blender now that I have time and am putting the finishing geometry into the cockpit. I’ll be texturing it and animating it over the summer. I’m completely done with finals this Wednesday so believe me, there will be time. Sven has been more or less constantly plugging away on the plugin since his last post this past November, so with any sort of luck, we can cross that finish line simultaneously, possible cross the X-Plane v10 threshold as well. Dhruv will be firing up the sim doing extensive flight testing and flightmodel tweaking here following his CRJ training.

X-Plane developers live in the real world just as do the rest of us. Let me stress that real life priorities always take precedence. I’m not saying that we don’t deserve some of the chastising that we get because yes, it has admittedly been four long years. We ought to be able to finish what we’ve started and on that, you have my word, we will.

Don’t expect updates in the galleries for a while yet. We’re going to keep updates spread relatively thin because lets face it, there is nothing worse than building up undue anticipation when we’re likely at the very earliest, still a good six months off. Look for milestones, not every little extra texture or polygon that I put into the model.

Keep up the faith. As long as we’re breathing, we’re still capable of dreaming up some pretty spectacular things.
Thanks

Alex

Yeah, that’s what i would say if i would need to post news regulary. Fortunately I don’t. However, i agree with you, one post per year is somewhat sparse. Maybe I’ve lost all sense of time…

Seriously, we’re busy. So busy that I don’t shutdown my PC; I leave it on with emacs and gdb running so I don’t waste time every day setting up my environment before I can start working. And that’s the truth.

So, what’s new with the plugin? Hmm, it works. What it does right now works. But what does it do at the moment? Not enough. Not enough to say “Yes, that’s how a 777 works”. And to be honest, there are still many things missing that will make it really act like a 777. What we have now is a “framework” and some systems working or partially working. It has taken almost a year for me to get a framework that I’m happy with. Displays drawn with vector graphics, multithreading, custom and X-Plane default command handling, I/O of default as well as custom datarefs, the option to save the plugin-state together with a flight, sounds etc. All these things must be written from scratch. Then the “real challenge” began, that’s what I call the real work: put in the stuff which makes the 777. We’re not talking about “basic systems” only. FBW, AFDS, FMC, these are what really makes the 777 the plane that it is, and they are what really cost a lot of time. But that’s also the most funny part. Yeah, we have some FBW logic, custom flight director and we’ve started the FMC. None of them is finished, and what they do now they do well but they are far from complete. And you can’t just say “finish FBW first or finish AFDS first”, because all of them depend on each other, more or less. As i said: funny stuff.

We’d like to show you a short video. Normally we wouldn’t post something this early, but I think you might be interested anyway. Just showing a really basic thing: “How to enter a route into the FMC”.

Said enough, need to write some code. Bye

Monty Python references aside, it has become painfully clear that there is grumbling and murmuring going on out there in the XPJ blogosphere. We’ve been getting emails and obviously posts to the tune of, ‘are you guys dead?’ ‘Is the project dead?’ Allow me to fill in some holes for you.

First and foremost, we’re not dead. I checked my pulse this morning before I went to class just to make sure. Much disappointment was to be had when I realized that I had no real excuse not to get out of bed. Joking aside, the project is very much alive as well. There are lots of exiting things happening behind the scenes in Sven’s little computer programming universe that I still can’t even begin to fathom. We’ve got the beginnings of an integrated FMC and autopilot/flight director system taking shape along with the 777s fly-by-wire logic. The autopilot is a work in progress. The majority of the displays and vector graphics have been worked out to a high degree with a few odds and ends here and there still needing patching up. Underlying system logic and relationships are always being worked on. Bottom line is, the plugin is getting very exciting. I’ll leave it to Sven to spell out the particulars later on.

As for Dhruv, he has been working with Sven on deciphering the particulars of the system logic. He’s also busy preparing for flight instructing. If he wants to leave a few words about that, I’ll leave it to him as well.

And me, well, I have moved out of Wyoming and am going to school for a BFA in ceramic arts at Utah State University. My work on the 777 isn’t critical at this point. Much like Javier has branched off while waiting for the CRJ-200 plugin to be completed, we’re doing the same for the time being. Dhruv and I have a trio of projects for a client that we’re finishing up and we’d like to push something small out the door over the holidays. Lets face it, we’ve all got rent to pay.

Long story short (with many more facets to it than I care to go into), we’re still very busy and simply haven’t had the time to contribute to the blog when there honestly  isn’t anything tactile to show for it. We are still here though, and will be until you hear otherwise. Just keep us in your RSS feed and when there is something new worth showing, you’ll know about it when we do.

We’re not going into that handcart just yet. We are feeling better. We’re feeling happy. And yes, comedic timing tells us when to duck avoiding getting knocked out over the head with a blunt object.