Dan's ERJ available

[OlaHaldor]

I tried it at work a little bit before I went home. It has two 4-core 2.8GHz XEON, 6GB RAM and a GeForce 8800GT with 256MB RAM. Obviously, I tried the Lite version on this monster machine. It all went smooth up until short final. It started stuttering like nothing I've experienced before, and kept on doing that until I slammed into the runway. Yeah. Slammed. Ever tried to land an ERJ at 3fps?... 

I couldn't believe that my super crazy work horse would have such a hard time playing with this plane. So I went over to another airport. Yup, same thing there too. And another airport. No change. What on earth is this plane doing to my system? It's having a heart attack!

When I got home to my PC where I usually fly, I went for the big guns. The regular version. Loaded at my WIP scenery Alicante, and was shocked by the crazy low FPS. I usually have about 60-70fps, even with the MU-2 I get something like that. But with the ERJ loaded I had 28-30fps. By all means, take-off and landing was no problem with this frame rate, I was just incredibly shocked by the sudden drop.

Can't speak too much of how it is to handle though. This is quite simply another type of bird than I've flown since the days of MSFS9.

[crs]

It happens on my machine as well. Is not as monster as yours (I have more memory on GPU though) but still, should be good enough.

That makes me wonder… How about those planes being developed here? Will they be as heavy on my machine as ERJ is? Or is it just poor ERJ's modeling? I know nothing about 3D. But if CRJ will behave the same - that will be a little disaster.

I might try Lite version at some point - but... I paid for a full one. ;(

Kind regards,

Kamil.

[Goran_M]

It happens on my machine as well. Is not as monster as yours (I have more memory on GPU though) but still, should be good enough.

That makes me wonder… How about those planes being developed here? Will they be as heavy on my machine as ERJ is? Or is it just poor ERJ's modeling? I know nothing about 3D. But if CRJ will behave the same - that will be a little disaster.

I might try Lite version at some point - but... I paid for a full one. ;(

Kind regards,

Kamil.

I have seen some screenshots of the ERJ in the org forums and I noticed people complaining about the "marching ants" effect.  The marching ants is almost definitely a mesh problem.  ie. duplicate objects occupying the same space.

Dan has said it is a texture issue but I don't know what kind of texture issue he is speaking of.

The ERJ looks to have somewhere over the 200 000 polygon (triangle) mark.  Duplicate objects would push that to a maximum of 400000 if ALL objects were duplicated.  Add that to a bunch of 2048 ^2 (and no 1024 ^2 textures) texture maps and you're going to have fps issues.

However, he has said he will be coming out with some kind of patch somewhere down the line so I guess people will have to wait a little bit.

I don't mean to criticise Dan's work and that's not my intention.  If it was a small handful of people with these problems, then it's a hardware problem.  But there are at least 6 pages of fps complaints on the org forums so I suspect it's a problem with the add on.

[-TheoGregory]

His plane has possibly more manipulators than the MU-2. Though I don't know exact figures on both, there must be in the ball park of 150 manipulators in the ERJ. That's quite a lot and every ATTR command slows down sim (Manipulators are ATTR commands), then you have 6 2048 by 2048 maps, each with a normal map, then somewhere with 300,000 polygons, + or - 50,000.

When you look at it that way with all the manipulator code, polygons etc, the performance hit isn't as terrible as some of the people on the .org are making it out to be.

-TheoGregory

[tkyler]

Despite the fact that Dan comes across as a "knowledgeable mentor" because of his tutorials, from what I've seen and read, the ERJ is not as efficient as it could be.  Dan's taken what I call a "brute force" or "simple minded" approach.  I don't say this to belittle Dan, far from it, he displays a well rounded knowledge in lots of areas but expertise in less.

Javier, by comparison, is a professional game developer, not self-taught 3D hobbyist as Dan is and understands quite a bit more about game development.  As such, I'll bet the CRJ performs quite admirably given its level of complexity.

My point is that I am confident that complex planes can be developed without massive performance hits.  Obviously more complex aircraft will take a greater toll, but Dan's ERJ, with minimal systems simulated should not be one of them.  The Falco plugin is every bit as big as the MU-2 one and has several hundred custom datarefs and nearly 100 manipulators running every flight loop.  Now I have to turn down my clouds and rendering settings to one below max...but I'm running a Pentium 4 with 1.5GB ram so I have an excuse :-).  Still I see 30 FPS in that configuration.

The "marching ants" problem is very much a mesh issue and not a texture one.  Dan can argue this but he'd be wrong.  This is nothing more than a "clue" that there are some issues which Dan can't see yet and it's probably affecting his performance adversely.  This is Dan's first real complex aircraft though and I'm sure he learned a lot from it...my concern is....how much bad information has he passed along in his tutorials?  I can't say as I've watched them but I certainly feel their positive impact is probably much greater than any negatives.

Do not judge future products performance based on any other product.  Juggling quality and performance is in the hands of the developer and all developers are not created equal...nor are developers skills static, they are continually evolving.

My personal opinion and impression...without having actually tested it but having plenty of knowledge in the topic.....is that's its a pretty facade with a weak foundation.  It doesn't surprise me to see FPS issues.  His foundation needs repair...and those are tough.  The MU-2 suffers the same type of issue and I'm having to pretty much rebuild the plane.

[alxunru]

Not to drag the topic of artifacts on, but I have had a bit of experience with the marching ants issue in the development of the 777. When normal maps first came out, I experimented with them and noticed the artifacts immediately on areas of the mesh that once had been clean. There were artifacts in strange places, like the tip of the nose, a couple of polygons on the top of the wingroot, and some on small details. Turns out (and I've confirmed this with Supnik), that these artifacts are the result of faces being mapped on edge, ie a line representing one polygon. The video card can't make sense of the normal mapped surface and sure enough, it spits out garbage. The severity of the effect is dependent upon lighting conditions, sun position, intensity etc.

Here is what Supnik told me a couple of months ago in response to my inquiry.

Ah - yes.  Sorry, that's a design limitation.  A normal map is fundamentally "3-d"...to build the 3-d space to apply it, we use a triangle's normal, and the 2-d UV map.  If the UV map has been rendered 1-d (by mapping a tri to a line) then we can't construct a sane cordinate space. :-(  There isn't a way around it that I can think of...

Take this a step further, its actually pretty easy to fall into this problem with the publicly available set of Blender scripts simply due to the sims rampant growth. Take a small antenna. More than likely I'm just going to planar map it as I'm not terribly concerned with distortion at that small size. If I've finished off the top of the antenna to be smooth, I'll have several vertices that are likely to be very close together. Consider that I'll be using a small texture area (call it the same pixel area that I would have mapped this to on a 1024 sized map) on a 2048 map. Blender's export scripts only export UV coordinates to four decimal places (believe me, I'd love to have 5 for the UV coords). That gives you 10000 possible coordinates across a 2048 pixel surface. That sounds like plenty, until you have vertices that are closer to one another than 0.2 ish of a pixel. Doesn't take much math to realize that by increasing your texture resolution from 1024 to 2048, you've effectively halved your UV coordinate resolution. The exporter will round your tightly packed UVs off to the nearest decimal, and because of that they can be plotted to the same texture space. It is why the tip of the 777 nose and tip of the screwdriver tail exhibited the marching ant syndrome. If you UV map intelligently, these kind of pitfalls can be avoided relatively painlessly. You might need to do a little bit more texture work, but the final textured surface is always going to be better off for it. And do note that you're only ever going to see these artifacts if you have a normal map in place. No normal map, no problem.

Here's a quickie test to demonstrate more or less whats going on.

Hope that this helps people out

Cheers

Alex

[Airbus]

Hmm now that you bring up the normal maps, I remember running into this when i was trying out normal maps on the Cessna panel. Its an  pretty easy fix too.

[WombatBoy]

To add to Alex's comment about the normal maps. Here's why it's the case on Dan's plane. One of the main spots I see it is the landing gear, the main surface being that somewhat triangular one that sits front and center on the nose gear. Well, it's not really a surprise, but here's how it's mapped. Just map it from the front, texturing will look the same, and we won't have to call Terminex to get all the ants off Dan's plane

[MdMax]

Hi all !

In this week's podcast at minute 47, Mark Stewart talks about Dan's Embraer ERJ-140:

"It looks fantastic, it's got a beautiful virtual cockpit..."

More here about this:

http://www.fsbreak.net/podcast/2010/5/5/fsbreak-67-new-carenado-aircraft-on-the-horizon.html

8)

[amerrir]

Dan has said it is a texture issue but I don't know what kind of texture issue he is speaking of.

The ERJ looks to have somewhere over the 200 000 polygon (triangle) mark.  Duplicate objects would push that to a maximum of 400000 if ALL objects were duplicated.  Add that to a bunch of 2048 ^2 (and no 1024 ^2 textures) texture maps and you're going to have fps issues.

I'm sure you didn't mean to suggest that Dan might have been careless enough to duplicate the entire model... Whatever, in my case it's not the polygons that cause FPS issues, but the pixels:

On my system, the 'lite' low poly count version gives me about 6 FPS more than a 'low res' version that I created for myself. That has a set of 1024 textures I made up applied to the 'full' version of the aircraft, so the reduced poly version is really doing very little in my case. In fact I'd suggest anyone with FPS issues using the 'full' version tries creating a new option with the original model & lower resolution textures from the 'lite' version. I certainly think the aircraft looks better with the original model, but as my screen resolution is not that high, I don't actually see any benefit from 2048 textures unless I zoom right in on external views. Which I rarely do. YMMV

[Jack Skieczius]

what file format did Dan use for the textures?

If he used PNG, one might try converting them to DDS and seeing how the performance difference as DDS generally load faster, and you shouldn't need to lower them to 1024.

from what i have researched. when you load up the exterior view it has to load all the textures, ok fair enough, but if you have say 6 or 8 2048 images all formatted as PNG file types then X-plane has to load up that many 2048 textures and then size them down to the size that the renderer calls on for the current zoom level, like 1024 or 512. This can casue a long pause when switching to external view while the computer dose this extra work load. The more textures the plane has on its exterior the more noticeable the load time.

If the file type for the textures was DDS it would work a bit different. DDS are compressed just how the graphics card would compress them and they are mip mapped(pre-sized to have multiple sizes). when you switch to exterior view X-plane calls up the texture files and only grabs the size it needs out of the texture file, which makes load times much faster.

anyway, thought i would add that here so it can hopefully help people run Dan's plane better without sacrificing quality.

I will be using DDS on my Q400.

[amerrir]

If he used PNG, one might try converting them to DDS and seeing how the performance difference as DDS generally load faster, and you shouldn't need to lower them to 1024.

Interesting point - but I'm sure in my case I'd still need to downsize as it's VRAM usage that is the issue. With any aircraft using multiple 2048 textures (say 4 or more), I risk a slide show rather than just low FPS. I'm talking seconds per frame, as the VRAM requirements jump over my video cards limits.

It's obvious to see how this happens when you consider each PNG is needing another 9Mb of VRAM, (I have a 512Mb card), but it would be interesting to see if DDS textures actually help FPS when VRAM is not being exceeded.

[Jack Skieczius]

I, well, i don't know. i am feeling very disappointed right now.

i should never had a look at his textures.

His Normal maps.....well they aren't normal maps. he did it all wrong, as if he never even bothered to look up what a normal map was. looks like he just amused they were similar to bump maps in such a way as he edited the normal map images just the same way.

Normal maps are a whole other beast entirely, and a very effective instrument to make any polygon look a whole lot better. tho i may have made them sound like rocket science, they are far from it. with just a few simple basic understanding of normal maps Dan could have made better use of them.

i am totally applaud, and i am not sure even my little rant here can explain the way i feel right now.

yeah that shine on the wings looks nice eh? but he only got that because he used the normal maps the wrong way, and you are actually not seeing what you should be seeing. I sure thought Dan was a better man then this.

I wonder if he would be willing to be taught how to do real normal maps......

[Ben Russell]

...sounds like you should do up a thread, so that everyone can learn.

I'm all for throwing rocks, as long as you have solid ground to stand on and a bunch of text books or reference papers that you can use to deflect returned missiles.

[Jack Skieczius]

...sounds like you should do up a thread, so that everyone can learn.

I'm all for throwing rocks, as long as you have solid ground to stand on and a bunch of text books or reference papers that you can use to deflect returned missiles.

This ain't a bad idea. I shall perhaps do just that. i would hate to see this happen again on more "payware" airplanes.

normal maps had always been a fasination to me ever since i first learned about them so many years ago now.

[Jack Skieczius]

And so i did.

http://forums.x-pilot.com/index.php?topic=863.0

not perfect yet, but that's all the time i have for tonight. i will check back on it Sunday and fix it all up.

[MaidenFan]

It needs a wind indicator on the EFIS screen.