Jump to content
Bohemia Interactive Forums

olli_

Member
 View Profile  See their activity

  • Content Count

    102

  • Joined

  • Last visited

  • Medals

  • Medals

Posts posted by olli_

  2. Posted

    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

  4. Posted · Edited by Olli_

    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.

  7. Posted

    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.

  9. Posted

    @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 :)

  10. Posted

    @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

  12. Posted

    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.

  13. Posted · Edited by Olli_

    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.

  14. Posted

    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

  15. Posted

    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

  16. Posted

    not sure i understand your questions. Originally i was going to have a dedicated decal sheet applied through a second set of UV so you could easily swap out the markings but that didnt end up working out since the macro texture slot in the rvmat is needed for the destruction material and it didnt look good with the decals disappearing when you got hit. I had to triangulate the model to split the secondary UV in places where there isnt usually an edge, so thats the reason i originally triangulated the lod0 viewmesh. Although i do have backups of the untriangulated mesh in my other .max files I had already done some other work on the mesh which i wasnt keen on redoing so i just kept the triangulated topology since i wasnt planning on editing the mesh too much anymore in any case (deadline was approaching)

    As for Nightmare515, I cant do much about that. The psd files were made with photoshop CS6. I wasnt even aware gimp had psd support. Cant really do much unless you can get your hands on a copy of Photoshop, extracting the .paa files from the main releasing and editing those would be the only way but you wont get the layers with that.

    My dropbox has been shut down now so ill be removing the files before i get IP banned. Ill try go around and replace all my links with Foxhounds mirrors

  20. Posted

    yes lemme just list stuff ill include in the source files:

    all unbinarized configs and scripts

    unbinarized p3d's for everything

    .max file for the plane, this includes all LODs that i have (some were made in OB) youll need 3ds max to open this though.

    .psd file for f_35c_ext_1 . This texture contains the main fuselage, and is useful for creating different paint themes. The psd files are massive (multiple gigs) so im only releasing this one. Feel free to convert the rest of the .paa files from the main release to tga and edit them that way.

  21. Posted

    Ive just release a sort of statement to address the confusion in my workshop submission comments. Ill copy paste it over here just for continuity

    Hey guys Ive been taking a break from this for a few days now and thought id give a sitrep to manage some expectations. First of all, im not a coder, and i dont intend to become one. This plane started off as a purely cosmetic piece for my portfolio until a kind fellow over at polycount.com tipped me off about this MANW contest, so i figured it'd be a piece of cake to port the plane over to RV4 (oh how wrong i was).

    I wont go in to detail but I have to say the Arma engine is the least user friendly piece of software i have ever used. ever.

    As I said, im not a coder, and although a part of me wants to keep working on this, the rest (90%) of me needs to get back to the world of 3d game art and current-gen engines.

    Now as some of you might have noticed, Ive released this asset under the by-nc-sa license, which basically means you can do whatever you like with the release (add on to it, remove stuff from it, change the name back to F-35) as long as its non-commercial and you give credit where its due. The reason Im doing this is although I may not be able to work on this full time anymore I want to enable others to add on to it and carry the project on if they so wish. To enable this better, ill be releasing all the necessary source files and ill try to hang around to help if anyone has any questions regarding my sloppy code or backwards implementations. Ill be releasing this source file pack once I finish compiling my .max files in to a redistributable package.

    Basically what im trying to do is sort of make this a community addon, rather than my addon, and hopefully inspire others to do the same. A lot of talented people around here more capable of creating advanced features like afterburners or GPS targeting systems, and likewise maybe someone can learn something from the stuff that ive done.

  24. Posted

    Alright so ive done something now. This isnt an F-35C Lightning II anymore. Its an FC-37 Thunder. Catchy eh? Ive also adjusted textures and configs to rename a bunch of stuff.

    Basically this is all to avoid any lawyers getting their nickers in a twist over me using some copyrighted combination of letters (better safe than sorry). The plane is still exactly the same. Ive only renamed some specific things that may or may not breach copyright.

    As i noted earlier ill be releasing full source once im done so you can go ahead and rename it back to whatever tickles your fancy if "FC-37 Thunder" isnt good enough for you.

    With that said, the new PBO is up:

    http://steamcommunity.com/sharedfiles/filedetails/?id=330990595

    Its a new workshop entry (apparently there is some bug with the steamworks SDK and i had to recreate the submission) so you'll have to resub even if you subscribed to the old one (i removed it so you shouldnt have to resub... or then you do. I have no idea how the workshop works)

  25. Posted

    Any chance you could implement something along the lines of a weapon service menu, like how John Spartan and Saul implemented a service menu for their F-18's it would be much greater than having a bunch of variants that take up load space.

    What do you mean by take up load space?

    currently there are 2 variants, one with the external weapon stations (totalling 11 stations) and one "stealth" version without the external weapons (so just 4 internal stations). 3 Different loadouts can be selected via a variable you enter when you place the vehicle, and the optional gunpod can also be placed via a variable. So basically there are 12 permutations in total.. It would have been nice to be able to select each stations weapon seperately but with the weapon selector MFD setup i have it would be too complicated. I already have around 3000 lines of code in model.cfg just to handle the current 3 loadout system, so having 4^11 loadouts would be more or less impossible unless BI introduce some better MFD/HMD/HUD implementation (which would be long overdue i think)

    I think with 3 loadouts and the optional cannon you can sufficiently perform all the various roles you would expect from a JSF. Its definitely a workaround but its the best alternative i could come up with.

    You can read a more detailed description of the loadout system on my workshop page: http://steamcommunity.com/sharedfiles/filedetails/?id=306002630

    Dont bother trying to download that.. I botched the upload yesterday but ill be doing another one today which will hopefully work better. Ill post the new link when i have it.

    also thanks guys for all the kind words :)

×