Jump to content


  • Content Count

  • Joined

  • Last visited

  • Medals

  • Medals

Everything posted by Synide

  1. Yeah, the CfgSkeleton + CfgModel is slightly different, but not overly different. However, there is a disparity 'tween the .p3d's provided selection names and the example .rtm provided. As I can't see the 3DSMax stuff I'm not sure if the .rtm was produced from that end or through O2. If it was produced from the 3DSMax end then the Skeleton structure used there is slightly different to the example .p3d's. If the .rtm was produced from O2 then I suspect the example.p3d's weren't used to produced this particular .rtm cause it has the following joints. It's probably better if you wait a little for Vespa to provide a properly constructed model.cfg that's being used with all A3 bodies rather than faffing around with a cobbled together one. -Sy PS: So, just to clarify the above list is not the Skeleton but just a listing of the joints in the example .rtm provided. As you'll note there's a disjoint 'tween the example .p3d's selection names and the contents of the .rtm. That's why I'd suggest waiting for Vespa to clarify. You could try something like this though... it may work...
  2. Hi, Detailing a new skeleton and joints through a model.cfg would be easy for your new animal. If your developing your model in another 3D application like Maya, 3DSMax, Lightwave, modo etc. and then animating it you need to get those animations over to the Tools Suite. This is a bit difficult to do but not to bad if you know what your up too. At this point you may think that's all... but, then you've still got to do the config.cpp which usually aren't to bad, but since you're doing .rtm's you'll need to properly define & setup all the CfgMoves for the animal. Which essentially describes how all the .rtm's interpolate 'tween each other in certain game situations. This isn't a trivial task. On top of that you've got to do 'geom' .p3d's for the CfgMoves 'states'... Then at that point you might be getting close to having a working animal. But, you'd also probably want to do 1 or more .fsm's to provide arbitrary behaviour during simulation... Never really got into .fsm's tbh, not pretty things to get running properly imo. Maybe, but a bit on the ichy side... Do you know what the skeleton/joint structure that those .rtms for the goat were made with? I suspect not. You'd have to acquire that information through use of community tools. Then, depending on how good you are you may have a few niggle issues with weighting your moose to the expection of the .rtm's. Also, the .rtm's are sized specific so when you moose moved it's leg forward using the goat .rtm it would only move the distance that a goat's leg would move... So, all up I'd say this isn't a feasible idea. The only reason you'd want to do that is because you weren't confident in creating a new model.cfg skeleton/joints definition file. This would be one of the less difficult things to do for your moose. Unless you're well versed in all this stuff I'd suggest you've got a great deal of heavy work in front of you. -Sy
  3. That would have been me... See Multimaterial. It can take _smdi textures too and the Shader just uses default values. The majority of default BIS content uses _dtsmdi's in the 'multi' shader .rvmats. -Sy
  4. That's quite true... if he was using a '_smdi'. However, he's using a '_dtsmdi'. Multi shader .rvmats use 'dtsmdi' maps in the specular stages. They can take an 'smdi' as well and the Shader uses default values. And, although he doesn't mention it that's what he's using his spec maps for at the moment. See Multimaterial on the biki for details. Also, as for the color variation he mentions in his first post. One should keep in mind that the filter he was running that comes as part of the tools installation is used for creating '_sm' textures. Then, when TexView2 saves it out it processes based on TexConvert.cfg and writes out a different result to the one you see after running the filter. Not a big deal, but can cause a little confusion I guess. -Sy
  5. Synide

    Supershader no _CO input?

    If you so desire you can specify your main '_co' color texture that you would normally put in the 'texture' field of face properties in a 'stage 0' in the 'super' .rvmat. That's fine. But, most modellers who use the 'super' .rvmat specify this 'primary' color texture in face properties so that they can 'see' it in the O2 viewport when DirectX shading is enabled. It's not uncommon though for people to specify the 'primary' in 'stage 0' only and not have anything specified in the 'texture' field of Face Props. Also, you can have two '_co' color textures if you desire... You can have one specified in the 'texture' field of face properties and another specified in a 'stage 0' of the .rvmat. IF the 'super' shader happens to find a 'stage 0' specified it just 'blends' the pixels found in that image with whatever pixels happen to be specified for the 'primary' texture in face properties. It's rare though that people make use of this two color texture capability. Simple really. -Sy
  6. Synide

    Help Oxygen 2 Load Error

    In theory, this shouldn't happen... because the model you have open in O2 has already been read into O2 and then the file handle is closed. The only thing you should loose is the latest edits you've made to your model since you last pressed ctrl-s. However, in saying that obviously something's gone wrong somewhere along the track. Send me the broken .p3d you're trying to open and if you've happened to have made a .pbo of the model recently send that too. You'll find my email in my signature. I'll have a squizzy at it and see what I can do... no promises though... It sounds like in all likelihood it's screwed so you may have to start over. -Sy
  7. Synide


    Perhaps a bit of a case of 'lost in translation'. I shouldn't use 'slang' in my text as you've appeared to get the completely wrong intention. I don't think I typed anything there that gives the impression I'm assuming you've made no effort. But, I apologize if you've interpreted it that way. In principal though because you're talking V4 you really should be talking about it over in the VBS2 forums, even if, unfortunately you don't get the responses you're hoping for. It's unlikely your posts would get 'locked' over there whereas it's a higher percentage chance they will here. I understand you're frustration though as essentially you're wanting to use V4 in a non-standard usage scenario so you're unlikely to get a lot of help over in the VBS2 forums from support staff as it's really outside their scope to do so. This then means you're reliant on VBS2 end users that may have a foot in both camps to pass on information. I hope this response hasn't dampened you're enthusiasm or annoyed you. -Sy
  8. Synide


    You expressed a desire to use the output map from your work in V4 over in A2OA and he was commenting that you'd need to use one of Mikero's tools (or know what to change manually) on the .wrp that is pumped out by V4 to change it into a .wrp that binarize.exe in the A2OA tools will recognize and then process properly so it can be used in A2OA. Perhaps if you posted the details of the error you were having in the VBS2 forums you might get a solution. I can't imagine V4's buldozer would have difficulty displaying A2OA binarized .p3d's and I know it'd have no problem with mlod's so it may be just a pathing problem. If it does have problems rendering OA binarized .p3d's then yeah, it's a simple task to replace the VBS2 buldozer.exe with A2OA's game.exe temporarily so you can view the OA content when you're working in V4... mmmm... but then you might have trouble viewing some of the VBS2 tools supplied .p3d's if you use those in your map. I guess it's just a suck-it-an-see task. Anyhoo, wrong forums for this subject matter anyway. -Sy
  9. Synide

    Standard LADDER dimension ref..?

    I did a doc a long time ago about ladder dimensions but can't lay my hands on it atm... so from memory... i think i used to make the 'rungs' about 225mm - 250mm apart and about 40mm thick and about 400mm wide. There was I remember a sweet spot though in the size... Hopefully, I'll track down that document, but if not trial & error on your part is your best bet. Also, you wanna have the ladder extend about 800mm I think above the point where the character gets off the ladder so it doesn't look like he's climbing in mid-air. Don't take those dimensions as accurate though, my memory is not what it used to be. However, there is a good'ish way of you getting it fairly accurate. And, that is slap a character model temporarily into your building model and apply the climbing ladder .rtm to it. Scrubed it through and adjust your ladder topo appropriately. It's not the quickest method in the book, but making all your models relative to the anims that will eventually run on them is pretty accurate. Don't ask me to remember the name of the climb ladder .rtm... you can track that down I'm sure, or someone else can let you know it.
  10. New info as at Oct 31st, 2012 Version - 2.3 MBytes through... MediaFire, Box, DropBox. SnakeMan found a discrepency (nee: bug) in how Shader Tree masks were being created. The plugin was setting 'Apply to Sub-Group' when it didn't need too. Fixed, and corrected spelling mistakes in help docs. Added note about naming of UV Maps for export to saving.html. Installation Instructions Most people have the 601 Content installed with their application. In the root folder of the Content is a new 'Kits' folder. Extract this .7z file into this folder and start modo. Done. Cheers, Sy. New info as at June 2nd, 2012 Oh, I've a 601 variant... it's still just the loader/saver, still no .rtm... I've included .html help files. So, it's a little more polished. And, as it's a code re-write I may or may not have introduce bugs... Probably the main thing to note is that by default pick-maps drive point/vertex selection. If you want weight-maps to drive point/vertex selection you have to add a locator to the mesh. See the help documentation under Help menu. Installation:- It's probably a good idea to 'blow away' your modo601.cfg and let the application create a 'new' one... thus clearing out any 'old' p3d plugin info. Most people have the 601 Content installed with their application. In the root folder of the Content is a new 'Kits' folder. Extract this .7z file into this folder and start modo. Done. modo 601 p3d file i/o plugin 2.2 Mbytes mirrored via kellys-heros.eu Cheers, Sy. Old info prior to June 2nd, 2012 Hi, After a lot of deliberation I have decided to release this modo c++ plugin to both the ArmA & VBS2 communities. It allows you to read & write mlod p3dm .p3d's from directly within Luxology modo. This version is essentially still beta as there maybe still bug's or flaws in it's operation. Please let me know if you have any problems with it. It is for the x86 or x64 windows version of modo 401 only at this point. Also, this version is free to use for the modding community supporting the ArmA franchise and is free to use for the VBS2/Serious Gamers community as well and in a commercial setting if you wish. The link includes the necessary files plus a couple of quick video's for setup and general usage. The video's unfortunately contribute to the majority of the size of the download. Please read the readme.txt file included. As a side note I will may make a 'pro' version in the early part of next year with more features that will probably not be 'free' and aimed more at commercial users but that's a story for another time & place. Please note the following link is not available 24/7. modo_p3d_plugin_v0. 60 MBytes. including installation/setup & basic usage vids. or modo_p3d_plugin_v0.0.0.5_novid.7z 594 Kbytes without videos. Cheers, Sy. PS. Also, as an aside. If you are intending too or are using modo and you use this plugin it would be nice if you dropped me a quick pm just saying that you are using it so I can gauge how much potential usage is out there in the world. Thanks. ALTERNATE DOWNLOADS Via Kelly's Hero's c/o pufu. modo_p3d_plugin_v0. or modo_p3d_plugin_v0.0.0.5_novid.7z c/o DaSquade. modo_p3d_plugin_v0. or modo_p3d_plugin_v0.0.0.5_novid.7z
  11. Synide

    Texture efficency question...

    As Max Power said, it'll do at least 3 drawcalls for the 3 different groups of polygons that represents your 3 different models irrespective of whether they carried completely different sets of textures or not. However, if you can share or reduce the number of different textures used by all three models this would be more optimal I'd imagine than say having 3 different (but similar) models and 3 different but similar sets of textures. What i mean is... if you had say 1 model with 3 different texture 'sets' which may (or may not) end as say 3 drawcalls & you had 3 models with 1 texture 'set' also ending up as say 3 drawcalls, both these scenario's are better than having 3 models with 3 different texture 'sets' if ya get my meaning. -Sy
  12. Yes I did manage to have a wee test. Log a CIT report. It's a bug in the in-built 'destrType' code for the 'DestructWreck' functionality I'd guess and you can't fix or alter that functionality. The settings I described previously are the req'd minimum settings so leave them as is in your model. When the bug report is resolved it should work as prescribed. That's of course if during bug fixing the functional requirements don't change. If, and only if, you really can't stand it, you could develop a workaround in the form of attaching a killed eventhandler to 'air vehicles' in general and have the ensuing scripts remove and create a static variant of the destroyed model for the various air vehicles. -Sy
  13. mmm, maybe that's a bug. I'll test it here too and see if i get the same result. In your wreck model you really only need several Resolution LoD's, 1-2 ShadowVolume LoD's, a Geo LoD and a LandContact LoD. The Geo LoD should have the typical autocenter=0, prefershadowvolume=1, sbsource=shadowvolume. Make your LandContact last by selecting 3-4 points from your GeoLoD and copy-n-paste them into your LandContact LoD. Then copy those same 3-4 points over to your 'wreck' LoD in your original model. And, finally place a proxy from the original model wreck LoD to the wreck model. Once you have the config class attribute setup too it should just work. Btw, which version of the game.exe are you using? -Sy
  14. yeah, what thromp said... just put 3-4 un-named points in the wreck lod along with the proxy triangle. situate them along the belly of your chinook as your wreck model probably doesn't have any wheels right?
  15. Synide

    modo p3d plugin

    Hi, Updated first post to version Cheers, Sy.
  16. Synide

    TexView 2 woes...

    You should be able to do a google search for 'how to center my image in Gimp'. I just did a search and it appeared to come up with some useful info. I just downloaded Gimp 2.8.2. Opened a .tga converted from .paa by TexView2. Exported as a .tga as another filename and specified... RLE Compression = OFF Origin = Bottom Left ... It opens in TexView2 fine. -Sy
  17. Synide

    TexView 2 woes...

    Directly after converting to .tga from .paa can you open this .tga in TexView2? Why would you need to convert the .tga to .jpg? Can't Gimp modify .tga? This is unclear. So, you're trying to open the modified .jpg in TexView2 or the modified .tga? I'd suspect, without seeing a .tga you've saved out of Gimp that this program is saving a variation of the .tga format that TexView2 doesn't like. It only eats a particular type of .tga. So, if after converting from .paa to .tga if you can immediately open this .tga in TexView2 and then later once you save a modified .tga from Gimp you can no longer open this .tga then I'd suggest it's a problem with Gimp. At a guess. Could be completely of the mark there. -Sy.
  18. mmm... perhaps also try adding 'mala vrtule blur' & 'velka vrtule blur'... -Sy
  19. try adding 'mala vrtule staticka' (for the tail rotor) & 'velka vrtule staticka' (for the main rotor) to the hiddenSelections in your new config class for this model. then try the 'setObjectTexture'... -Sy
  20. Synide

    STALKERGB's Weighting overview

    Probably. It depends on how much your new character model is different in size, shape and volume. The majority of the animation files (.rtm's) have been created to work with a standard sized character model. If you then apply these .rtm animations to a new model that is too different it's going to look odd. Here's an extreme example. Imagine you have a current .rtm that moves the standard sized characters left arm across the front of his body and replaces a mag in a weapon being held by his right hand. Now imagine your new character has an enlarged stomach, chest area and you apply the same animation. It'll end up looking like the left arm/hand is now moving through the new characters stomach/chest on it's way over to the right-hand side. Not, very good eh? The anims are size specific. Generally, people have not made characters dramatically different in size and shape because they'd have to go ahead and create an additional set of animation .rtm's to cover all the moves this new character would be performing. While it is feasible to do this, in practice it's takes time and alot of patience and technical ability. If you have a mocap setup and a refined workflow to move the data into .rtm format then it's not so much of a hardship to have a different sized character. But, most modders don't have this sort of workflow available to them. So, they'd have to create each required .rtm by hand essentially. A rather daunting process. -Sy.
  21. Probably because he has his O2 viewport in DirectX mode... never fear... it'll be there, you just can't see it in that screenshot atm. @Myke... Do you have a proxy in the GeoLoD yet for the 'driver' or is it just hidden in the screenshot. If not, try defining one and rebuilding. Although it won't be hurting your model.cfg in the CfgModel section you have it inheriting from class Default which you have defined just above. You don't really need to do that because your class Default basically defines nothing at all. Was there anything interesting in the build.log? When you're testing it in-game is there anything in the runtime.log? -Sy. PS. Oh, and where is the CoG of the model atm?
  22. This is a super shader .rvmat correct? Try just pointing the AS map from the .rvmat at a 'new' UV map, one without the poly's for the wheels in it and leave the other textures for normalmap, dt, spec, etc., pointing at the current uvmap with the wheel poly's in it. Give it a go. Should be fine. -Sy
  23. Synide

    Source Filmmaker & ARMA ?

    No, it will not.
  24. Yeah, sorry true... memory isn't the best nowadays... was having a senior moment 'tween vbs2 functionality & oa functionality. -Sy
  25. Since when? It used too' date=' has something changed? I mean some 'eventhandlers' are ofcourse meaningless in certain 'simulation' types but for instance a 'fired' eventhandler in a CfgWeapons.YourWhizzyClass.EventHandlers should work fine. But sticking a 'fired' eventhandler into a 'building' simulation would obviously be incorrect. Perhaps if you post your excerpt from your config someone might suggest what the problem is... -Sy.