search

c172p-team / c172p

A high detailed version of the Cessna 172P aircraft for FlightGear
GNU General Public License v2.0
80 stars 43 forks source link

Update wiki page #437

Closed gilbertohasnofb closed 8 years ago

gilbertohasnofb commented 9 years ago

I believe we urgently need to update the wiki page of the c172p with the list of new features of our plane, as well as some basic explanations that new users will find handy. For instance:

etc.

Can you guys help me come up with some ideas, and then we can rewrite that article?

gilbertohasnofb commented 9 years ago

@Juanvvc @onox @wlbragg @wkitty42 @dany93 @tigert suggestions?

wkitty42 commented 9 years ago

@gilbertohasnofb i don't have anything specific... i'd say to do like on wikipedia and be bold with your edits... we can add to or clean up later ;)

gilbertohasnofb commented 9 years ago

i'd say to do like on wikipedia and be bold with your edits... we can add to or clean up later ;)

Sure, but I'd rather brainstorm it here before and then edit it at once. So if anyone has any ideas to add I'd be happy to hear them!

wkitty42 commented 9 years ago

the list you made previously looks fine to me... i'd say to go ahead and fix it up... others may have a different opinion, though... there's always the talk page over there, too...

at some point there may even be a tutorial on landing and taking off on water with either of the pontoons...

gilbertohasnofb commented 9 years ago

@wkitty42

at some point there may even be a tutorial on landing and taking off on water with either of the pontoons...

Great idea, added to the list above. As soon as I have some time I will propose some modifications to the wiki page then. Thanks!

gilbertohasnofb commented 9 years ago

Hey guys, I made a first improvement to our wiki page, see: http://wiki.flightgear.org/Cessna_172P

I'd be very happy if you can help me add some more information there. Could you all have a look on it and see if you can contribute with something?

dany93 commented 9 years ago

@gilbertohasnofb ,

gilbertohasnofb commented 9 years ago

Is the wing damage and breaking during flight (wing overload) included in your phrase?

Nope, forgot about those!

Some words about the spin departure possibility when stalled?

That would be great.

Would you be able to make those edits yourself, or maybe help me creating the phrases so I can copy them there?

gilbertohasnofb commented 9 years ago

About your first point, what do you think of this?:

"The airplane now can get damaged from collisions, crashes, hard landings or overload while in-flight, and the damage includes wheel collapse, wings breaking, etc."

dany93 commented 9 years ago

Yes, I'm going to try writing and propose.

gilbertohasnofb commented 9 years ago

:+1: thanks!

dany93 commented 9 years ago

At first view, your phrase seems good.

gilbertohasnofb commented 9 years ago

Nice, so just propose a phrase about stalls and I can add both there myself. Thanks a lot for the help!

dany93 commented 9 years ago

"Stall and spin feature: the aircraft can start spinning (rolling) in case of asymmetric stall. Such as the particularly dangerous last turn at low speed, low height, before final."

(I feel my english is not very good..)

gilbertohasnofb commented 9 years ago

I think that's good, but I would suggest making the phrase more fluid. I also think we can add more things about the FDM. So what about this?

"The FDM has also been modified. The aircraft may enter in a spin in case of an asymmetric stall (a particularly dangerous situation is when turning to final, in which the aircraft is at low speed and low height). The FDM has also been tweaked to include hydrodynamics effects while taking off or landing on water, as well as by using the more powerful 180 HP engine."

If you like it, I will add both now.

dany93 commented 9 years ago

That's good, thank you for the corrections. "may enter in a spin" or "may enter into a spin"?

Anyway, we can change it later if we think of a better writing. That's a good start.

gilbertohasnofb commented 9 years ago

Done, thanks! :+1:

dany93 commented 9 years ago

Also, maybe a few words about the Autostart feature? (important for beginners)

Engine Start (manual)

Autostart

gilbertohasnofb commented 9 years ago

Sure, I will add to the list on the first post of this page.

dany93 commented 9 years ago

I was just thinking of one or two lines (see above) in the wiki. No extra explanations needed.

gilbertohasnofb commented 9 years ago

Done, I added it to the bottom of the subsection Engine Start: http://wiki.flightgear.org/Cessna_172P#Engine_Start

gilbertohasnofb commented 9 years ago

Guys, I created a FAQ, as well as other modifications to our wiki. Now if some of you could help me with the checklists and procedures (particularly complex startup) I'd be very happy! Then I think we could close this issue here :smile:

gilbertohasnofb commented 9 years ago

@tigert @Juanvvc you guys are the ones with the most RL experience here I think, so would you be able to give me a hand with the checklist and procedures part of the wiki? Maybe also the FAQ list. I don't mind updating the article myself in case you don't have an account.

thevirtualfer commented 9 years ago

suggest non-HD liveries for low end users (since the new default is an HD one)

Well. With als on, i have noticed just the contrary.

The frame rate increases a bit when i use 2048x2048 textures and goes a bit low when i use 1024x1024 (talking about interior textures. I have not exterior textures over my fuselage).

Maybe some graphic guru can explain it better.

Also, maybe it is a variable thing, depending on the hardware used.

Can you verify this in your copy ?

gilbertohasnofb commented 9 years ago

@thevirtualfer How come you are gaining performance from larger textures? It doesn't make any sense to me. I will test, but on my computer (relatively powerful CPU and GPU and lots of RAM) I don't see any difference at all. But I remember there were some tests of our c172p posted in the dev list some time ago and people on low end computers were particularly sensible to texture size, compression, etc.

Which brings a question I've been wanting to ask you: I know you favour to have a single texture file for all textures as (according to what you read Thorsten write) switching between textures increases memory consumption and lowers the performance. The problem is: with individual textures, it's much easier to optimize them. If their colour palette is small enough, one can diminish their sizes considerably by using a 256 or less palette. Also, it separates the interior from the exterior textures, allowing liveries to be only external. Finally, it allows certain files to have higher resolution than others (in our case, the HD liveries have double the resolution of the non-HD ones, but certain textures such as floats.png have the same size).

thevirtualfer commented 9 years ago

I know you favour to have a single texture file for all textures

Hi Gil.

Not exactly. What i am saying is to maintain related things in as less texture files as it is possible, but, of course, not being paranoic enough to merge all into one single texture.

For example, the breakers.

For the maintainers point fo view, it is logical to have the blend file, lets say, breakers.blend addressing the texture breakers.png and exported to a model breakers.ac.

It is so useful work this way, because, at least in theory, breakers can be reused through the sim.

And this is still valid to a lot of things. We can have a 2stateswitches.blend addressing a single texture, a MixtureLever.blend, addressing a single texture, and so on.

It both, is very logical and adds versatility, to developers.

In the other side, we have the render engine. In the time of the render, it will load the, lets say, MixtureLever.png, and draw it, switch to breakers.png, and draw it, switch to 2statebutton.png, and draw it.

Nothing bad, if "switching" is not a pain to the engine.

So, what i am saying is to, ok, we have these separated blend files with their single texture etc.

But then, when building the plane.blend, we group these related textures in as less texture files we can.

Like we already group then.

So, the engine will switch to a single texture and draw more than one thing, like breaker, Mixture Lever, 2statebuttons, etc, without the penalty of the "texture switch" op.

switching between textures increases memory consumption and lowers the performance.

Not exactly increases memory consumption, but is one of the most expensive task to the engine.

The problem is: with individual textures, it's much easier to optimize them. If their colour palette is small enough, one can diminish their sizes considerably by using a 256 or less palette.

The main benefit having individual textures is the versatility and easy to understand and maintain.

Also, it separates the interior from the exterior textures, allowing liveries to be only external.

I am ok with this. The exterior textures grouped in one, or at least few texture files. Also to the interior. More or less as we already do.

But we can, for example, have an object called beaconLight, with your own beaconLight.blend, beaconLight.png, beaconLight.xml, beaconLight.ac.

And also, an object called propeller, with your own propeller.blend, propeller.png, etc, etc.

It is logical, i agree. It eases the contributor life, i also agree. And it will lead to more "texture switching".

but certain textures such as floats.png have the same size.

About floats and skis, it will not affect so much. Or you are using floats, or you are using skis. So, there will be not the penalty. In the time i commented, i had not figured it.

Also, until now, i think i misunderstood what @Juanvvc was proposing.

The c172p.blend is a huge file. If someone needs add a new 2StateButton, he can be aware to do it, because of the complexity of the file.

If we have separated models, lets say, a Panels.blend, Fuselage.blend, etc, etc, but yet a c172p.blend that link or proxy these individual models, will be more easy to others deal with it, without the scare thing.

What i understood on the first read, was that logical model i talked about. Like a BeaconLight.blend, a BeaconLight.png, and so on.

The merge being made only into the .xml file, not in the model itself.

Cheers, Gil.

thevirtualfer commented 9 years ago

How come you are gaining performance from larger textures? It doesn't make any sense to me.

Nor to me, but it is absolutely true. I have a gain of 3-4 frames/sec when using 2048 textures. I tested with the same texture scaled. Maybe it is related to the graphic card.

onox commented 9 years ago

Larger texture just cost more bandwidth (to upload to the GPU) and VRAM. It would be a good idea to at least partially reduce the number of textures that is needed. Not saying to reduce it all the way down to 1 texture, but if there are tons of tiny objects each having their own texture, maybe these could be combined.

onox commented 9 years ago

The problem is: with individual textures, it's much easier to optimize them. If their colour palette is small enough, one can diminish their sizes considerably by using a 256 or less palette.

Textures in RAM are usually just RGB(A). So reducing the file size doesn't reduce the size in VRAM.

Also, it separates the interior from the exterior textures, allowing liveries to be only external.

Yes, keep interior textures separated from exterior textures.

wlbragg commented 9 years ago

@gilbertohasnofb, The wiki has a small misprint, I would have just fixed it if I knew what it was suppose to say.

The new c172p has a much better 3D model and is now fully textured (including the interiors), has improved FDM, the cockpit switches and toggles are all clickable, has more complex procedures and new realistic checklists, has a damage model and working and it has plenty of new sound effects.

Specifically

has a damage model and working and it has plenty of new sound effects.

gilbertohasnofb commented 9 years ago

Hi guys, I will answer everyone in a single message:

@thevirtualfer I really don't understand the performance gain, it could be something related to your hardware. Following its logic, using 8192x8192 textures would result in the fastest performance of FG ever :laughing:

@onox @thevirtualfer So what if we try to keep 3 texture files only: a single exterior file, a single interior file, and one for panel + radios + dashboard? The exterior file would merge wings, tail, fuselage, also floats and skis, and also those minor textures like the lights, etc, and the panel texture would then include all the panel_parts textures (breakers, switches, etc.). I think this is a reasonable thing to do. What do you say?

As for the instruments, each of them have between 2 and 4 textures, what should we do about it?

@wlbragg I must have rewritten that paragraph some 100 times and the final version became a Frankstein's monster! I corrected the last part to:

[...] has new sound effects and can get damaged if mishandled (e.g. gear collapse after a hard landing).

thevirtualfer commented 9 years ago

So what if we try to keep 3 texture files only

The first try we done, all we want is a better UV MAP of the panel. Then, we gone doing things without a plan (i an talking just about model/cut).

So, our texture files has a bad distribution of textures and a waste of white spaces.

We can do it better. I am not in this point yet, but when i reach it, we can talk better and see.

Following its logic, using 8192x8192 textures would result in the fastest performance of FG ever

Hehehe. I guess some hardware deals better with 2048 textures than with the 1024 ones. Maybe.

gilbertohasnofb commented 9 years ago

Sure, I don't mean it now, I am just proposing a possible plan for us to follow since the subject appeared now. But I know we are not yet in the point of dealing with the textures, no worries about it.

onox commented 9 years ago

I think this is a reasonable thing to do. What do you say?

Sounds good.

legoboyvdlp commented 9 years ago

Just updated the wiki with grammar as well as other stuff.

legoboyvdlp commented 9 years ago

http://wiki.flightgear.org/index.php?title=Cessna_172P&type=revision&diff=88781&oldid=88084

gilbertohasnofb commented 9 years ago

@legoboybdlp Thanks for the corrections, the page looks much better! :+1: I just did some minor tweaks which you are welcome to revise:

legoboyvdlp commented 9 years ago

;) Thanks! Seems good.

gilbertohasnofb commented 9 years ago

The pre-flight instructions will be added to our wiki page by @dg-505. If you feel comfortable, you could also add a section about starting the engine with complex procedures (primer, full mixture, throttle at around 25%, etc.) and then we could close this issue.

gilbertohasnofb commented 8 years ago

There is still a lot of room of improvement to our wiki page, but all the items referred in the first post have been written and therefore I am closing this issue.

@dg-505 when you update the checklists and tutorials, please feel free to make the wiki page consistent with them. I just added a small section about pre-flight inspection, but I'd be very happy if you can improve on it after you have a proper checklist.

dg-505 commented 8 years ago

Yep, but for now the checklists and tutorials have higher priority for me. When they're finished, I'll bring the wiki article up-to-date.

gilbertohasnofb commented 8 years ago

the checklists and tutorials have higher priority for me.

Absolutely! I just added something to the wiki so that people using our plane are at least able to understand what is going on. But there is no rush :snail: