rocket

I'm not quite sure what the link to google sketchup is supposed to represent. Â And I think the issue here is now largely a moot point mate. Colonel Well was describing above the difficulty lies in transferring the materials from OFP to ArmA, suggesting that there was alot of work involved : Also, two links were posted above to the OFP addon in progress. I don't know, seems fairly conclusive to me, considering Colonel Well admitted as such and then stated he would be keeping his work private. These "witch hunts" might not be important to you, but ownership of an addon makers work, regardless of how old it is, is kind of important. Â Addon makers don't get paid in money, they get paid in recognition through credit where credit is due. There are those folks who do not care of the origins of an addon, or the ownership. But there are others that appreciate the importance of credit to an addon maker.

I have been experimenting a lot with large objects, and I had a rear gun turret on the back of a large ship. Â Now the front turret was closer to the center of the object, and showed up fine. Â However, in the rear turret all the resolution geometry would disappear until you moved it around so it was seeing geometry near the center. I solved this by simply moving the model ten meters forward, thus about 3/5 of the model are forward of the center point, and the turret renders the resolution geometry in all its glory. It would appear that when rendering turret views, the engine always renders what's forward of a model, but behind, it culls faces based on distance from the center of a model. Edit: clarified I was talking about resolution geometry, and not the Geometry LOD.

Sorry Gnat, yes - one has to remember though that the rest of the game's industry calls vertex information "geometry" generally. On most game's I've worked on we called the Geometry LOD a collision mesh. I'm still trying to find exactly why the engine decides to cull resolution geometry. For example, if I place my ship in specific locations on the map - you can see all the resolution geometry when in the front turret. But placing it in certain places, it culls the resolution geometry until you turn the turret right back towards the center of the object. Does anyone have a good handle on exactly how the engine decides to cull resolution geometry? I suspect its based on the center of a model, but it appears to be dependent on everything else it is rendering.

*sigh* Mate, you're totally missing the point yet again. Â The issue is not that nobody is saying its not hard work to port something from OFP to ArmA, its that you need permission and to properly credit where credit is due. For goodness sake, Placebo even offers to help addon makers get in contact with those who make the mod to gain permission - and if you do get permission (and particularly if you aren't able to contact them), you should state where you sourced them from.

If you follow cam's advice above, the similarity is striking. In fact, to use the word "similarity" is an understatement. I want to give the benefit of the doubt to the 75th, but if you follow Cam's instructions below its clear that the 75th version borrows significantly from Cam's. Having had similar things happen to my work before, all I can say Cam is that I know how you feel. I really do. And to be honest, its the shittiest feeling in the world. In the end, in my situation, it all got sorted out and now I even help the team that was involved - we're all good mates. So I'm sure this will get sorted out.

Hi mate, you need the earlier release of Oxygen. The earlier release allowed the export of *.obj files. I managed to find it for download at several places, if I can find the link I will post it here.

Alternatively, try painting the Mip Maps yourself. I haven't done this, but the "real" game developers hardly ever let automatically generated mip-maps remain untouched up. Just open them up in photoshop with the mip maps, and then paint some thicker edges, make the color more blocky. Might be worth a shot and quick hit, otherwise you'll have too look at UV layout as per the above poster's comment.

I suppose a bit more of a description is warranted. To get around the maximum roadway size, the object is broken up into five different objects (although some of those objects are just roadway and geometry). Most of the leaders at USEC (all bar one of our generals) are ex-military, including one of our team who served aboard LHA-1 and is providing me technical advice. Â There are "consoles" for "Tactical Air Command Control" (a radar centered on the ship), and the "Debarkation Control Center" (a screen that allows you to spawn aircraft on each of the bays). The Debarkation control center (DCC) can be used when close to the island (edit: Island means the big metal building in the middle :P) to issue and return aircraft. Â The aircraft spawn on the deck (and not in mid air - that was quite a feat!. Â Currently the LHA has the following: - 1 x mk13 Launch with Sea Sparrow - 2 x CIWS Phalanx - 2 x Deck guns The entire deck is walkable and we have not had anyone fall through deck anywhere in at least the last three updates. Â Performance is fine with no framerate issues. Â Texture is two 2048x2048 textures, one for the "Island" and one for the Hull. As noted above the ship is made out of five components. Â I have tested a script that allows the movement of the entire collection of objects, however I had problems with the replacements of my turrets. Â Basically any object that had landed on the deck, would be added to the collection of the ship objects, and therefore moved in accordance with the object. This can be achieved either by using the "setpos" method or (better) making the object a floatable HMMWV class and then simply having the server take over its velocity management by getting it to set the velocity of them every few frames. Â One thing ArmA does really well (as of 1.14 anyway) is handle lag situations using its velocity settings. Â Its physics is fairly predictable so catchup between positions has not been a problem with me, even when updating even 0.1 seconds. Placement of turrets requires the modeltoworld method, followed by either: - Placing them first - Offseting their center so they are not placed ON the ship (necessary to move the carrier) All interaction with the ship is done through console screens, which are dialog screens. Â I had terrible trouble with animations and getting actions working, so the console screens are added to the player as an addaction fired by a trigger. The ship can be placed easily in any map, simply by placing a single unit. Â This invisible unit is then replaced by all the required pieces. Â Only one LHA can be present on a map at this stage. I have not tested a multiplayer variant of the moving LHA, nor moving and landing. Â However I have previously done testing with other objects using the server-take-over-physics method in multiplayer with no problem.

USEC has been operating PROJECT SHAKER for the past few months, with the details classified to those within USEC. The culimation of this was a final weapon systems test tonight. Videos and images speak for themselves. I will be releasing many of the components, but the main package is for USEC. If there are any credible maritime makers out there who need the Phalanx or MK13 launcher, they can contact me. I made a Mk21 but due to proxy limitations with static objects I didn't like the result, so made a MK13 instead. The B-1B has been a longterm project and is nearing maturity. I've decided to make it public as I accidentally mentioned it in a few posts anyway. I've reached my photo limit so B-1B photos will come later. Enjoy -------------------------- Youtube Videos - - -------------------------- Maritime

No problem, she's fully lod'ed, maximum polys in LOD is 2580. No scripts used at all. Normal mapped and Specular mapped on 1k textures. Should be fairly easy to integrate on anything, can change the colors of the metal to suit different ships if needed.

Be sure to check out the and its pretty self explaintory there what its functions are. Same goes for the .

Does anyone know if this is possible? I haven't been able to get proxy based missiles to work correctly on a static object (such as inside a turret). When i fire the weapon, the proxy disappears but it wants to fire the missile for the weapon firing point (e.g. "usti hlavne") Hell, even getting it working on a vehicle seems to be problematic. Am I doing something wrong, or is this a known limitation?

Checked the BDRM as well... every land vehicle seems to use the "Konec rakety" and "Spice rakety" memory points to define the exit points of missiles and rockets. There's not the capability to fire from L or R, just from one central point. Shame because I've decked out a rather nice MK21 Sea Sparrow launcher! Might just have to make it a MK13 instead.

I gave that a go, and yeah - no joy! The engine does move any memory points that are moved on the basis of the turret animations (x & y) but doesn't alter their location based on user animations. Shame, but I've definitely tried everything! Only other solutions I can think of are: 1. Script the placement (I don't like this solution, rather have it firing from one default position in fact). 2. Make the model a "static helicopter" and see if the turret works on that. Or, for that matter, the vehicle or boat classes. I do suspect that proxy weapon launches may be restricted to plane (and possibly helicopter?) classes only though.

The "air" pbo contains the helicopters. Why not hunt down how BIS did the seagull, that might be more appropriate for what you're trying to do.

Yes if you want just *one* I want to fire several missiles, that can be seen as proxies. Unfortunately, it always fires the weapon from the defined "gun" point no matter what values I change or add (such as "memoryPointLMissile" etc...). The proxies disappear as the weapon fires, but the weapons don't fire from the proxy point. I suspect this is a class limitation on anything except planes and helicopters.

This is BIG BIG news. I tried it out, and its fantastic. I have about FOUR big projects on hold at the moment because I couldnt get my RTM's properly working out of 3ds Max. Thank you very much sir!

Lots of progress today... PLEASE my username these days is "rocket" (my dev team named me it, long story). BIS can't change my forum name, please if you're going to name me in your news posts - use Rocket to avoid any confusion. Thanks heaps! She starts folded up, and then unfolds when you first start the engine: Also, I have added the cargo sling underneath, and it can be deployed. Tested tonight, works great! No scripting used at all, clean and smooth transitions in multiplayer. Will be applying the technology for a side winch also. And last but not least, a still frame capture of the HH60H unfolding...

Depends largely what shader you're using with your material file. I find if you're using 512x512 or 1024x1024 textures, you're okay because they can be swapped in and out easy. ArmA is going base lighting calculations on your textures anyway, so essentially the normal map is almost a "freebee". Personally, 9000+ faces is not necessarily a problem for an aircraft in ArmA. My B1B Lancer is ~13k faces, but then, its pretty darn big! And use your face count as the default un-triangulated... only triangulate what you need too, the engine will triangulate it all before processing anyway I believe. Rather than using a formula, I've tried be really critical once I've made my model. I did that with my B1B landing gear, posted the wireframes on the forum, and I got great constructive feedback that allowed me to reduce it from a whopping 3500 faces down to 320, with and INCREASE in detail through the normal map! Keep up the great work!

By geometry I mean, geometry in the general sense. Â All the vertex data is called the "geometry" of the object. Game developers call all this vertex/face data "geometry" collectively. Â BIS just happen to also have a Geo LOD, which is one kind of "geometry" data stored there, so I wasn't meaning that. And your assumption about faces and textures isn't necessarily correct. Â If you have a small texture, and its repeated over many, many textures... that is no problem. Â If you have several massive textures, used on many different objects, thats no problem either. These days, ANY PC that can run arma, has a pretty major supply of graphics memory (holds the textures in memory). Â What tends to run in short supply is graphics bandwidth (swapping the textures in and out of memory). Â People that buy poor graphics cards notice this lack of bandwidth (bus speed). Flying across sahrani and noticing stalls? thats when you're computer is swapping texture files in and out of your video card... and the hard disc & video card bus are going crazy. What you need to aim for... is normal mapping. Â It has a VERY low cost compared with replicating the detail in the mesh and/or (particular) the diffuse bake. Â Looking at the BIS UH60, I noticed they have baked their ambient lighting into the diffuse - but that does result in the model requiring ~ four 1024x1024 textures. As I said, the function over form approach is one I think is great. Â If you've made sure the models are well UV mapped, someone can easily knock up a new normal map and additional shader details for it later anyway.

"You'll never make it over that ramp, fonzi!" "Eeeeeeeey... I gotta try, richie!" I guess most here would be too young to remember "happy days"... Love the leather jacket! Really nice texturing work there as always.

Have you tried selecting all faces, and then clicking F5 to recalculate normals?

To clarify, detail should not be in the polys, it should be in the normal/spec/shadow texture. Â I make/beg/borrow/buy extremely high resolution models and then "bake" them down into textures, tidy them up, and place them on a low poly model that I have made. I would consider that the models you have made have plenty enough detail in poly's, and probably all they would need would be a quick texture pass. Â An ambient occlusion render-to-texture would make all the difference. I was under the opinion that anything over 7000 polys (in the highest lod) was a pretty high polygon model? Â Remember also that GEOMETRY is actually pretty easy for a modern PC to handle (even in quantities). Â Also, ArmA instances geometry as well. Â I've had ArmA handling massive amounts of polygons (by breaking objects into many parts) without it batting an eyelid. Â The key is achieving a nice balance between the geometry and the texture. I'd argue (and really, its hard for me to back this up) that we're not limited so much by geometry with our addons (you can break models up) but by texture memory. High resolution textures can really cause the engine to chug! In your examples above. If you texture it with flat color it will look "weird" because the lighting will be poor. Â But if you bake some detail/shadow it really brings it out. Â Good work on focusing on function over form, I'm sure there's plenty of folks waiting for this to come out!

Designed to work with an LHA, in an anti-surface/sub and CSAR role. So dependant on other addons which are not released. But it looks pretty. And I'll include a hellfire variant, and one with the single MG mounted. I'm having some drama with the winching system, but should have that sorted tomorrow and I'll post a pick of that. Also the landing gear are much stirdier than the standard ingame blackhawk, useful with rolling decks in game esp with lag. I'll be releasing the entire source work for the project, as I used the BIS MLOD for my base (thanks BIS!

Hi guys, I have an alpha'd texture I am using on a face to model the blurred propellers of my C130. Â I found that the face had a shadow cast on it from other aircraft components, so I edited the RVMAT as follows: <table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE"> ambient[] = {1, 1, 1, 1}; diffuse[] = {1, 1, 1, 1}; forcedDiffuse[] = {0, 0,0,0}; emmisive[] = {0, 0, 0, 1}; specular[] = {0, 0, 0, 1}; PixelShaderID = "Normal"; VertexShaderID = "Basic"; renderFlags[] = {NoZWrite}; The result looks great, except that against water it does not show up (see below). Â Does anyone have any suggestions how to prevent a shadow being cast on a material without using the render flag NoZWrite?