olli_

Hey, I just noticed what you're doing here and I just wanna say it's looking great so far and I really appreciate you taking the time to improve this mod! Can't wait to try it out at release

Just got my 1080 and thought itd be nice to try out Apex on ultra graphics. Well turns out I get about 20-30 fps on ultra 1440p, Then I tried turning down the settings to all low, fps went up by like 5-10 so it hovers around 35 now, still nowhere near playable. so what gives? i5-2500K 3.30GHz 16 GB RAM GTX 1080 Also I get about 50-60 fps in editor with everything ultra, which is still lower than ive seen benchmark results. edit: ive also tried these low fps fixes, neither of which did anything

ah i see ill make it happen

ded gummit.. ill look in to it. edit: Ive fixed it and uploaded it to workshop. Bad news is I had to re-enable PhysX since turning it off apparently broke the flight model. I spent weeks getting that flight model just right, and i dont have time to retune everything to a new simulation model (an outdated one at that) Im sure PhysX support will improve, and hopefully the Nimitz will be updated to work with it in time.

class names?

you need to raise landing gear to use the gun

Alright I've pushed a new update to the workshop. Fixed the script errors showing when playing with -showscripterrors on Disabled PhysX. I downloaded the Nimitz and confirmed that the plane doesnt blow up when you place it/drive it around on the deck. hopefully i didnt introduce too many new bugs.. I cant guarantee the integrity of my source files since i moved a lot of stuff around when i was releasing the unbinarized source.. If you get any more bugs and such you can report them here or on the workshop page.

do the vanilla planes also explode on the carrier then?

@BagPiperGuy, the variable you need to set as "y" for the gun is called gun. So it should be gun="y"; also make sure you have the ; in between each variable declaration if you have more than one. @Eymerich The variable in question is OK_fold_wings. Its a feature i added last minute on request which allows you to spawn the plane with wings folded if you set it to true (apparently useful for mission makers). I forgot to add a failsafe for when the variable is not initialized at all, so when you dont give the variable a true or false value, it goes in to the if construct with a nul value, which throws an error if you have -showscripterrors added to your start parameters (which i did not at the time, so i missed the error) Theres no actual bug, other than the error message shown. The nul value does not trigger the if construct, so the plane always spawns with unfolded wings unless you specify otherwise (which was my intent from the beginning). I was going to patch it out when the submissions reopened a few weeks ago, but i wasnt sure about the integrity of my main build and no time to do a full playtest of everything, so i decided against updating the entry in case i end up breaking it even more. Ill probably upload a fix along with the physX thing when i get home in a few days. @Anthariel Thanks :)

@randomslap Is that so? Interesting. Ive never used the Nimitz so i dont know but dont the vanilla aircraft work on it? I would assume they also have PhysX enabled, but maybe im wrong. Do you know if theres something i can do to make the plane not explode without disabling PhysX, or is PhysX even worth having for planes? @2rmina2r wow thats a nice video! Really enjoyed watching that. As for more loadouts; technically its not hard to create more loadouts. The loadouts are handled with the init.sqf script, which basically adds weapons and ammo depending on which loadout variable you specify. The problem is the MFD loadout display. It is animated via model config, and 3 loadouts is already stretching the limits of whats possible with one skeleton. Basically you could just completely remove the loadout display and make as many custom loadouts as you wanted, but i like the loadout display so i decided to sacrifice custom loadouts in return. @ICE_AGE0815 Thanks :D

nope sorry no plans for a STOVL

damn you managed to get the animations working. I had animations but i couldnt find a way to play them. I didnt have too much time to spend on it and only tried the "time" animationsource but that seemed to start ticking when the plane spawned, so unless you dropped the bombs instantly the animation phase would already be 1. also by what i said about the textures i just mean that you cant just put a tileable texture map on something and call it finished (which ive seen done way too much in less experienced products). all those examples are good. For a vehicle youll want the smudged/worn paint and handprints around the parts where the operator usually climbs in/out and so on. for planes you can have scratches on the plane but have most of them on the forward facing surfaces, where dirt and stuff in the air will impact. There are all sorts of cool maps you can bake to help you put the detail where it should go. Cavity map is usually a must for me to get the worn paint on sharp edges, dust and dirt in small cracks and stuff like that. For directional detail (dust settling on the top, scratches on the front of an aircraft, etc) you can bake an object space normal map and then mask your detail in to the normal direction you want.

Three things you need to keep in mind when creating topology: The silhouette needs to be smooth from every angle. triangles are relatively cheap on hero props like unique vehicles (props that you only have few of in a scene) and the overall tricount of the whole scene can be something like 7 million tris or more, so using a few extra edge loops to keep a silhouette smooth will maybe cost you a hundred tris or so which is really nothing. (its different for generic env props like trees and fences and so on where you might have a hundred instances in your scene) The surface normals need to be coherent in order for the normal map to be able to do its magic with as few artifacts as possible across all LODs. if your surface normals are intricate, the normal map will have to account for that, and so when you simplify the topology for the next LOD, your surface normals will change a lot and the normal map cant cope with that. This is definitely something i could still work on, and in the end it really just comes to having a lot of foresight in the early stages of the project. Avoiding long thin triangles where possible. This is a little more technical and less common sense as the others, but doing this will definitely help you with the 2 points above. First of all long and thin triangles can fubar your surface normals in certain situations and you dont want that, secondly they dont deform well at all, although my plane is rigid so this doesnt apply here but it does for characters and plants and such that are animated. Youll also run in to stuff like weird lighting artifacts (especially with an engine like arma that still uses vertex shading for some things) as well as more technical stuff like subpixel triangles that you might not notice directly but will definitely hurt your performance. I guess most of these problems are a thing of the past with stuff like per-pixel shading which isnt as reliant on topology but i still like to keep my mesh clean if only by habit. As for the explicit case of the edgeloops on the spine of my plane, id say thats mostly just making sure the shape is there. I might start rambling a bit here but i think what people conceive as real or realistic is pretty interesting. One one hand you have the simple aesthetics of the model. Does it look nice, is the texture high res with lots of photosourced detail to make it look all nice and realistic. But that isnt enough to make it "realistic" if you take a fictional machine for instance, it can look all intricate and detailed with lots of moving parts but the difference between a good design and a great design is if the machine has an apparent function or purpose. You should be able to look at it and see what makes it tick, thats where the immersion comes from. Now of course thats just an abstract example but i think it applies to modeling and texturing pretty well. You can have a really high definition texture with lots of detail and dirt and grime, but it wont be convincing unless it makes sense. There needs to be a reason behind every scratch, a reason why dirt and grime has gathered in a certain part of the texture but not in another. Thats when the texture starts to convince you its real and not just a 2d image on a virtual object. Now to get back to the point, which is my plane. Consider the F-35. thousands of engineers have spent countless man-hours and hundreds of millions of dollars to define the shape. Wind tunnel testing, computer simulations. There is no shape on this plane that does not have a reason for it to be that way. Now if i were to remove an edge loop from the very subtle, but characteristic curve on the top of the aircraft which smoothly slopes the fuselage down as it approaches the engine (the angle is not more than a few degrees and the slope stretches over 5 meters so its hardly noticable right? wrong. Its the kind of thing you dont notice, but the subconscious does, and for some it might be enough to break the immersion. Obviously we still have rendering budgets to worry about and you cant go around adding edgeloops to everything but i decided the spine of the plane is one of the main shapes that define how the f-35 looks (and also when youre flying in 3rd person you look along the spine, which makes the shape all the more apparent and would reveal sharp edges if there were any) so i figured it was worth the extra 50 or so triangles to ensure the shape stays smooth at all angles. I have a rambling problem edit: found some pictures of a very old version of this plane... some history: Originally i started creating an F-35 as a piece for my portfolio back in 2012. Found work shortly after which put the plane on the shelf. Picked it back up in 2013, working on it for a few months pretty aimlessly not knowing what i really wanted to do with it. I was mostly just fiddling around with it in marmoset while also wanting to learn some offline rendering techniques but that never came to be. new contract again took my attention away until around july 2014 when i found out about this MANW contest so i figured what the hell ill give it a shot. Pretty much did 10 hour days from there on out, redoing most of the plane, adjusting it to RV4's needs, texturing and making bombs and so on. most of my time went in to learning this engine because quite frankly its like nothing ive ever used before (i still have nightmares) aaaanyways here's exhibit 1: https://dl.dropboxusercontent.com/u/15275414/F-35C/fuselage_bot.jpg high poly model from 2012. Ill be the first to admit it looks like shit. granted the selection of reference pictures was really bad back then (still is but not as bad) and here's a shot from the current belly: https://dl.dropboxusercontent.com/u/15275414/F-35C/2014-10-31_00004.jpg ignoring the texture, you can see how the shape changed over time. The changes were relatively small but they make a big difference.

I think the "limit" (i.e. when the compiler starts throwing errors) is based on vertices and its around 32-35k verts as far as i can tell from my limited experience. whether or not the model is triangulated has no effect on the vertcount and its more to just make sure the topology stays consistent to what the normal map was baked on

hmm interesting i did indeed forget the GBU-53 fly p3d. I'll have to figure out a way to update the files on armaholic. The fly variant is the same as the proxy p3d except with wings opened so you could just open the wings from the non-fly variant and resave it. JDAMS are set up as laser guided bombs. Similar to the GBU-12's that come with the vanilla jets