• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

P3D v2 T-346A

SixGhost

SixGhost

Resource contributor
Messages
103
Country
italy
I've been working on this one for a lifetime it seems to me. I started it a few years back but due to a chronic lack of decent material and that damn thing called life always getting in the way, this is where my little project is at right now.

Some shots of the pit in construction:

One of the seats

MkIT16D-1.jpg


The front panel assembly

front_panel.jpg


Here's the latest stage of development

cabin.jpg


And finally a couple of old shots of the external. It will be heavily reworked because of some inaccuracies and the need to fit the pit which is based on actual drawings, unlike the external.

side.jpg

front.jpg


What did I learn? Never ever start a plane that is still in a prototype stage!:banghead: And never trust your eyes when most of your reference material is made of pics taken with a widish angle lens. I literally had to redo some parts tens of times. Getting curves right was a mini challenge in its own way. :)
It's also to be said that I'm really picky though.:p

Luca
 
Thanks guys, much appreciated. Work still continues, I'll have something to show by the end of the week all going well.:wave:
 
The hand grip assembly is complete. I managed not to split it into chunks and it's just one smoothing group. I now really hate the 1mm welding threshold though!:D

hand_grip.jpg
 
UE, the polycount so far for internal + external is 220k tris.
Yes I know, I'm going beyond the "reasonable" amount of detail, but it's been done like that for a number of reasons and with a plan.
You may see a lot of rounded edges for example, when in fact, they're not. I add edge loops to "confine" the creasing you would have between two perpendicular faces with the same smoothing group, much like you would do in high poly modeling before applying a turbosmooth modifier.
This allows me to:
- fake a chamfered edge with less polys
- easily apply a turbosmooth modifier if I need since most of the sensible parts of the mesh are quads
- effortlessy reduce the amount of polys by a lot retaining all the basic geometry once the textures are baked, just by erasing all unnecessary fake chamfers
It's a slow process, at least for me, but it gives me the freedom to go sensibly up or down in resolution.
Of course, the gridding won't be seen and it will have to go, but it's a nice touch and the less poly heavy part in there :D:D
 
If you go by that route, my suggestion would be to mesh out the whole thing like a CGI one, and then bake the normals onto a low poly variant. The so far 220k is a lot of polies for an in-game mesh.

When you do meshes meant for realtime rendering, you want your poly and texture count as low as humanly possible, or you get extreme hardware demands on running it when you add the whole finished product together, that's the main trait of a good gaming 3D artist.
 
I can think of some modellers who would say "Chickenfeed!" to those poly counts. FSX and P3D can handle that and the solid chamfers with low smoothing counts make it easier for the sim to deal with.
 
Sorry, but a 9 year old 32bit game is done for a really specific set of limitations that if you don't abide by, you just cause problems for. Some games just reject a mesh that's outside it's set limits, some make it prone to errors and instability, some can crash. Plus you can never be sure what the entire polycount of stuff shown at a specific moment in a scenery on a particular persons PC can be.
 
I understand where you're coming from NSA, it's just that other modellers have found the limits for FSX are higher than Luca's position at present. P3D raises the bar still higher since it offloads the rendering burden to the GPU.
I don't know what the actual limits for FSX on today's hardware are, but I do know there are models on the market which easily exceed 250,000 polys without the sim protesting. I know of no limits being hit with P3D to date but would like to hear if there are.
 
The limits aren't hardware dependent mind you, but on the forced limitations of the engine itself, hardware just make it's realtime rendering more efficient within it's own constrains. That's why modern engines like the one Star Citizen is made on can have scenery with polies in the millions (so, ships, character models, scenery assets combined), the engine that is being written for the game I'm in the dev team of was stressed up to 2 million by us without any negative effects. I'm not so sure with FSX tho, especially with todays addons. And that's just the poly counts, if we add in animations and textures it just goes downhill from there on rapidly.
 
NSA, baking a high poly mesh over a low one sure is one way of doing things (for organic shapes). I personally don't like it for non organic meshes because once things are in motion and specular kicks in, your beautiful textures are ruined by hard edges and the illusion goes to the bin, like your vertex count.
May I suggest you read this article?

http://blogs.technet.com/b/torgo3000/archive/2007/06/19/performance-art-3-polygons-don-t-matter.aspx

Chances are that the hand grip assembly above, if mapped correctly, will be way more efficient than a significantly lower poly one with different smoothing groups. And it will also look nicer!;)
 
Indeed. As someone who spends quite a bit of time writing HLSL shaders, its much easier for the video card to handle a couple hundred thousand or even a million polygons than something like nearly 50 million pixels in textures.
 
SixGhost said:
NSA, baking a high poly mesh over a low one sure is one way of doing things (for organic shapes). I personally don't like it for non organic meshes because once things are in motion and specular kicks in, your beautiful textures are ruined by hard edges and the illusion goes to the bin, like your vertex count.
May I suggest you read this article?

http://blogs.technet.com/b/torgo3000/archive/2007/06/19/performance-art-3-polygons-don-t-matter.aspx

Chances are that the hand grip assembly above, if mapped correctly, will be way more efficient than a significantly lower poly one with different smoothing groups. And it will also look nicer!;)
Click to expand...
No, you misunderstand. Make the whole thing like up to 100k polies, and stuff you cannot do through normals do with modelling. That's how I do it with my own stuff.

The article basically says that when you map something your vertex count goes up, depending on the way the mesh itself was mapped. That's why I said that when you add up the textures your problems get bigger fast. No matter how you approach doing the mapping, the poly count still gives you the bare minimum of verts you are working with.
 
Last edited:
NSAdonis said:
No, you misunderstand. Make the whole thing like up to 100k polies, and stuff you cannot do through normals do with modelling. That's how I do it with my own stuff.

The article basically says that when you map something your vertex count goes up, depending on the way the mesh itself was mapped. That's why I said that when you add up the textures your problems get bigger fast. No matter how you approach doing the mapping, the poly count still gives you the bare minimum of verts you are working with.
Click to expand...

I perfectly understood what you meant there mate. I stand by my own words though. I just don't like normal baking for non organic meshes. Simply put, given the level of detail I want to achieve, If I had to choose between adding normal maps for most of the pieces or 100k efficient polys, I'd go for the latter.

You're right when you say that polycount gives you the bare minimum of verts, but in my case, reducing the polycount means erasing hard chamfers and erasing hard chamfers means I can't use just 1 smoothing group and I lose my fake roundness. So basically by reducing polys, visual quality and verts, i add other verts because I now have lots of hard edges. At that point, the difference between the number of verts of the high and low poly meshes (same shape, same uvmapping) is considerably smaller than you might think. Once you add a normal map are you still so sure you would gain performance?

But hey! To each his own workflow, there's always something to learn and that doesn't mean that in my next project I won't completely change mine!:stirthepo

Cheers,
Luca
 
You must log in or register to reply here.
Back
Top