G4 Artists Reference Document (PDF)

[Dave Lauck]

G4 Artists Reference PDF (http://www.knifeedge.com/KEmax/G4 Artists Reference.pdf)

Ok, there it is. I've gone through it pretty thouroughly but if I've missed something, let me know. Of course I'll answer questions in the Designers Corner if they come up.

This document complements the web page we put up awhile back that has tutorials on how to build planes and helis for RealFlight here:RealFlight Tutorials (http://www.knifeedge.com/KEmax/tutorials.php)

While that is a tutorial, this PDF is a reference. It assumes that you have some rudimentary knowledge already about building aircraft for RealFlight.

Download Adobe Reader (it's free) if you haven't already to view the PDF. I made it a PDF because there's so much graphical info in there. With the PDF format, you can zoom in and out to read the smaller stuff.

Acrobat Reader (http://www.adobe.com/products/acrobat/readstep2.html)

Good luck.

Dave

[Dustyk]

Thanks Dave. This will be a HUGE help to us. i cant wait to crack into my box when I get home.

[dhk79]

One thing I noticed in reviewing this was that it specified "ALL ~CS_" objects required a collision mesh. Is this a hard rule? I ask, because it seems like a waste. There are some parts that are pretty much impossible to hit by themselves.

Also, what are the polygon limitations for G4?

[0xdeadbeef]

One thing I noticed in reviewing this was that it specified "ALL ~CS_" objects required a collision mesh. Is this a hard rule? I ask, because it seems like a waste. There are some parts that are pretty much impossible to hit by themselves.

For G3 the rule was to either not use collision meshes at all or to use them for all components that could/should be able to collide with the ground or other objects.
I would guess this rule was not changed since else a KEX for G3 without any collision mesh would have none in G4. Any clarification on this would be nice though.

While this document is a large step forward from the previous documentation, I'm also a little disappointed that no advanced features - such as bump mapping - were added. I also don't get why the strange concept of movable pods wasn't reworked. It would be a much clearer and more consitent concept if movable pods were just pivots without mass or aerodynamic (+ hydrodynamic) influence and you would always have to add a wing to get a physical effect. G4 would have been a good point to change this.
Also note that lots of custom models use movable pods just as to move a rudder arm or the pilot's head. It's pointless to add a burden to the physics simulation just for this.

[Dave Lauck]

Making a collision mesh for all ~CS parts is a rule that we follow here mainly because of standards we've developed. If a part breaks off that has no collision mesh or one that is not made properly or "closed", it may react with the ground in the wrong way when it touches it.

Our poly limit for the artists here is officially 10k for an aircraft. We break that rule on occasion, but usually only for helis and scale aircraft.

Dave

[arb6591]

Our poly limit for the artists here is officially 10k for an aircraft. We break that rule on occasion, but usually only for helis and scale aircraft.
Dave,
Is that correct? Not 20,000?
I would not be able to get my latest SU-27 even close to what it looks like with 10,000 polygons.

What do you mean by breaking this rule on occasion?
What is the meaning of "officially" ?
I thought all the rules were oficial :)

Andrzej

[Dave Lauck]

Andrzej,

I suppose officially the KEX exporter warns you when you go over 20k. I meant that our policy "in-house" is 10-15k.

The higher you go, the more the plane itself is going to affect your framerate. In house we have to think about multiplayer and how large poly count planes may affect the framerate of on online session.

D

[Keylitho]

Dave,

I think that this has been asked before but I have yet to hear an offical response, is there any way to make custom objects for the sim in this release? (objects for the environments)

[Dave Lauck]

Not yet Erik.

Dave

[arb6591]

Thank you Dave.

Now it sounds right :)
I was aware of "magic" number when you have to use collision meshes and the 20,000 polygon limit.
10k just got me wondering...

Frame rate seemed to be the same when flying high polygon and low polygon plane in multiplayer with 2 players but I understand that it might drop dramatically with larger number of players.
My FPS dropped under 20 when I was trying to fly with 6 players.

Thank you again.

Andrzej

[inky00]

I think framerate has alot to do with the complexity of the flight model,when i made the Weeks Solution it had over 10 movable servo arms and control rods and that seemed to affect the framerate quite dramatically.When a variant came out that dropped the moving servo arms and control rods the framerate was loads better.That particular model was right on the 20000 poly limit but with a simple flight model it works well.

[arb6591]

Mark,

That goes pretty well with what I have noticed.
What lowers FPS the most is:

1. Number of players in multiplayer mode.
2. Complexity of the Physics Model.

Number of polygons seems to have very little affect on FPS.

If anybody have noticed that it is not true, please comment here.

Dave, do you second that or there are other considerations?

Andrzej

[inky00]

I find it quite amazing that we are limited to only 20,000 poly's as i believe some of the models in AFPD can have as many as 100,000 poly's in them.Why can they use soo many more than us?is it because the physics modelling in AFPD is much less processor intensive and they can get away with it more?Its an interesting topic for sure.If we could up the poly limit to 30,000 surely it wouldn't affect the FPS to much if the physics are kept as simple as possible.I am trying to model a reasonably scale Apache AH-64 at the moment and i am going to struggle to get all the detail i want in it.Shame really but you cant have it all.

[arb6591]

I would sure like to see higher polygon limit ..... 30000 would work for me.
I would not expect any changes in this area though ... :)

Andrzej

[Dave Lauck]

To be honest, I have such a high end machine here, it's tough to tell the difference between the framerate of a 20k plane and a 10k plane. I've been told that by the people here that are much smarter than me, that it does make a difference, so I go with what they say.

The tough part is making them under that 15k limit. I get a scale plane to do and I get all excited about making look the best I can. It's quite a challenge to stay under that. The Mosquito in EP4 is a good example, I fought with that one longer than I should have and it still came out to close to 20k. I'm happy with it, don't get me wrong, but I could have done more with it, especially the cockpit area.

I'm always eager to see what you guys come up with for the swap pages. I've seen some very innovative designs in there, and I'm sure there will be more since G4 is out and we have water. New float planes, boats, whatever, will start showing up, I can't wait to see them.

Framerate is king in this business and it's always a struggle to get to that magic number, and that magic number is different for everyone. So play with your settings and fly your hearts out, that's what it's all about anyways, isn't it?

Dave

[0xdeadbeef]

I find it quite amazing that we are limited to only 20,000 poly's as i believe some of the models in AFPD can have as many as 100,000 poly's in them.Why can they use soo many more than us?is it because the physics modelling in AFPD is much less processor intensive and they can get away with it more?Its an interesting topic for sure.If we could up the poly limit to 30,000 surely it wouldn't affect the FPS to much if the physics are kept as simple as possible.I am trying to model a reasonably scale Apache AH-64 at the moment and i am going to struggle to get all the detail i want in it.Shame really but you cant have it all.

From what I can tell, G3 doesn't seem to be CPU limited on a descent CPU, but mainly GPU limited - especially on 3D fields or on 2D fields with lots of depth buffer objects. Dunno exactly why this is the case, but I would assume the lack of a proper depth ordering/optimization (Octree/Portals/whatever) could be the cause. So most probably lots of pixels and zbuffer entries are not drawn once (or a few times), but several time, which is crippling the performance.
In photofields, this is augmented by the way that the depth buffer is created. While most surfaces could be defined by a two dimensional shape (e.g. a room's wall), G3 offers only 3D objects. Often multiple objects have to be arranged to approach a certain shape. Thus creation and checking of the depth buffer is slowed down.

About AFPD: the stock planes always looked pretty low poly to me. Then again, AFPD has only very basic 3D fields and no multiplayer option (with more than two players) AFAIK. There are also no complex 3D trees and it doesn't feature self shadowing. Also I guess the depth buffer in the photofields is not so prone to overlapping as the approach used in G3. So having one or two aircraft(s) in a photofield with a relatively simple depth buffer should indeed be less of a GPU burden.

[NAWS]

thanks for the info on making the different color schemes will hafta give this a try
using PSP XI have done many repaints for aircraft for a WW2 sim
:)

[Ello?123]

what program do you use to make the aircraft cuz i want to make one so what program and where to get it plz!!!

[theecoop]

here is blender
http://www.blender3d.org/

but from what i understand is the only way to get it into G4 sim is to have 3dmax and the KEX export plugin.

So guessing you could build one ,but someone with 3dmax would have to import your 3ds or obj then export the KEX file for you

[REBEL]

This is a nicely detailed reference document, but it's only good for those few RealFlight users that can design the aircrafts.

Are there any detailed reference documents for the airport and aircraft editors? If not, when will they make them?

I'd like to see a reference document for the aircraft editor first. It should contain a more detailed section for things like configuring elevons and other linked control surfaces, brakes, gyro, and other advanced functions.

[phrank]

"It's in the Manual" :D ....and the search bar....
....although G4 manual cut out a lot of info on aircraft editing that can still be found in the G3.5 manual (http://www.knifeedge.com/downloads/RealFlight%20G3.5%20Manual.pdf):
Here are some starting points.
* Airport editing starts at the bottom of Page 40 in G4 manual, and continues on for a few more pages.
* Aircraft is briefly covered in G4 manual starting at page 113.
G3.5 manual has quite a bit more detail starting at page 116.
A more in-depth Editor forum discussion was done by Doug, and is still the best source of info, check his physics tutorial (http://www.knifeedge.com/forums/showthread.php?t=17498).
* Back to G3.5 manual, Gyro is discussed around page 239.

The info is out there, you just got to make an effort to find it.

Good Luck,
Frank...

This is a nicely detailed reference document, but it's only good for those few RealFlight users that can design the aircrafts.

Are there any detailed reference documents for the airport and aircraft editors? If not, when will they make them?

I'd like to see a reference document for the aircraft editor first. It should contain a more detailed section for things like configuring elevons and other linked control surfaces, brakes, gyro, and other advanced functions.