Ok since I know that Collision shapes are impossible to do in 3dsmax and other external tools , ( unless you can tell me I am wrong and point to a tutorial ) how do I do to make collision boxes?

I'm not sure if this is what you're asking for, since I know nothing about meshes myself, but I was just told that the collision problem with meshes seems to be able to be fixed by doing this:
http://niftools.sourceforge.net/forum/viewtopic.php?f=10&t=3562

Thought it couldn't hurt to mention it.

Thats a patch workaround that creates highpoly collisions that are messy and buggy and don't work ... so still no way to create them ...

Darn, too bad. I was hoping it could help...
Guess we'll have to wait for Nifscope?

Might be worth looking at fixing his code, handling errors and such. I'm trying to import collada files form google warehouse right now, and I hadn't even dreamed of getting collision working.

I'd like for ow at least to know how to make the collision boxes in CK ...

You could copy a world object, like a box, and attach a script.

Scriptname Test Extends ObjectReferenceEvent OnLoad()	 SetAlpha(0.0)EndEvent

The little box with a "C" on it... click it, then click in your renderWindow. You'll see a big yellow box show up, which you can then scale, rotate, and move about willy-nilly. I use this quite extensively, as it's a low-poly solution... and the collision boxes can easily be scripted to move.

But if you REEEAAALLY wanted to do custom collision in 3DSMax; I figured out a couple ways to do it; but it's VERY limited. Essentially, you can't do any concave collision, only convex (and/or basic primitives like box & sphere). You have to be aware there is a tricky scaling issue you'll have to work around.. but it IS possible. But since only convex collision is possible, I would suggest (in most cases) to just use collision boxes... unless your object is scripted to move and handling the extra objects would be too much.


Here's the thread I explain it in... if you have more questions, let me know - I have a bunch of notes on this that may not have went into those posts.
http://niftools.sourceforge.net/forum/viewtopic.php?f=38&t=3308&p=22619#p22619

I've been trying out http://niftools.sourceforge.net/forum/viewtopic.php?f=10&t=3562 as well, and so far it's working fine for me. Looking at the collision in the CK, it looks exactly as I created it in max; not highpoly or anything. Checking it out in-game, I'm colliding with it, jumping around and walking on it without any problems. What problems were you having with it?

Primitive collision shapes are possible to create since the latest version of nif exporter for max, which was released over two months ago. And those compresssed collisions can be generated with NifUtils as mentioned by Antistar above. And that's a recent "discovery".

You only need to type proper render scale in collision parameters which is 69.991 then you can create shapes of primitive collisions in max with pin point accuracy. So I'm not so sure that this solution deserves to be addressed as "tricky" :]

Can you be more specific with an example?

As for niftools what I need is make collision for custom meshes not conver falout collision shapes to skyrim or convert other skysrim shapes to collision , unless I understood wrong what this tool is for and how to use ,....

Yeah, making collision for custom meshes is exactly what it's used for. You can ignore the mentions of Fallout in that thread; that was a bit of a tangent, I think.

Say you've got a nif file with working collision stuff in it; for example, you've pasted your custom mesh into an existing Skyrim nif file with collision in it (nif A). You've also created the collision geometry you want and exported that into its own separate nif file (nif B ). The ChunkMerge.exe program takes the geometry from nif B and replaces the collision geometry in nif A with it.

The NifConvert.exe program basically preps a nif file - giving it the right structure, including collision stuff (by copying all that from an existing Skyrim nif) - getting it ready for your custom collision geometry to be pasted into it. So you may not need to use it if you've already got a working nif file. For example I had a bunch of nifs that technically already worked because I had pasted my custom meshes into existing nif files with roughly similar collision so I could test them in-game; so I didn't need NifConvert.exe for most of them.

There will probably be a bit of tidying to do after using ChunkMerge.exe - setting NumUVSets (which I'm pretty sure is mis-labeled) to 4097 on your NiTriShapes and then updating tangent space, at least.


It's not really explained very well in that thread. I think there were some language barriers there; some stuff lost in translation. I think that when Macaron3 said it only gives 'high-poly collision', he/she meant that for his/her purposes (since for him/her that was converting Fallout 3 nifs, for whatever reason - maybe just a test), it wasn't getting the actual collision from those Fallout nif files, but using the normal, visible geometry instead. So that would be a downside for using it for that purpose. However, since we want to create our own (low-poly of course) collision geometry from scratch, these tools work just fine for that.

ok so I

1 take my custom mesh export to nif with no collision
2 take another mesh and make as a collision and export to nif
3 get any random static with a collision from skyrim
4 use the random static the mesh exported as collision and merg
5 put that thing into my custommesh nif?

Okay, you've got your visible geometry and collision geometry in 3dsmax or whatever. Typical workflow would be:


1) Export visible geometry to nif A (using default exporter settings, probably).

2) Export collision geometry to nif B (NifUtilits contains a jpg with exporter settings for this; I didn't try anything besides what it recommended).

3) Prepare nif A so it will work in-game. Vertex shading may need to be enabled on NiTriShapeData nodes. Basically look at the structure/settings of a nif that works and see what needs to be done.

4) It needs a bhkCollisionObject (this is the collision that works in-game in Skyrim), so paste your visible geometry into an existing nif with collision, and/or (sometimes this will be needed, sometimes not) do the next step.

5) Run NifConvert. It will want 'In-File' (nif A), 'Template' (existing nif with collision, just give it Temp.nif included with NifUtilits), and a filename/location to save the output, which will be nif C (or you can consider the result of the above step to be Nif C if you don't use NifConvert; it's not always necessary).

6) Run ChunkMerge. First it will want a 'source' nif file (give it nif C), then a 'collision' nif file (give it nif B ). It will output a nif file with nif C's filename with 'mod' on the end to the directory nif C is in. This is nif D, containing both your visible geometry, plus collision geometry in required bhkCollisionObject/bhkMoppBvTreeShape/whatever form.

7) Do any necessary clean-up in nif D. Using NifConvert will apply any material (ie/eg: BSLightingShaderProperty) settings/flags in (presumably) the Template file to your file, so you might need to change those. ChunkMerge seems to clear the tangent space data, so set NumUVSets (which again I'm pretty sure is mis-labeled) to 4097 on your NiTriShapes and then update tangent space. Add in furniture nodes or whatever else you might need.



I hope that makes sense. Nif files are complicated. I said that NifConvert might not be needed; some nifs didn't, for me. Others had oddly offset collision - or crashed the CK - unless I had run them through NifConvert. I don't know why; due to the particulars of the nif in question, I guess.

I labelled it as tricky because the workaround I use is different from your 69.991. I found that primitive collision shapes were scaled down 15x, exported, then the radius of the bhkShape/whatever is always set to .1 - while not precise, it was close enough not to notice any discrepencies over 75ft worth of collision on a single mesh. I stopped doing this and just use CK's collision boxes though; basicallythe same thing and the game is very comfortable with them.

Using a 3rd party tool which is known to be buggy and incomplete may not be the best approach. I'd wait until that app is updated further. Have you tested it in-game with an FPS counter to see if the structure causes system stress? (don't forget to check during an onCellAttach/load, as that's when it would spike the lowest) NIFs having wrong data aren't as damaging as wrong data in the actual plugin, so it's not as GREAT a concern... but it could potentially cause problems under certain circumstances.

An example of a NIF-related issue which kills the game... if you use a texture which doesn't have the correct increments used in the resolution causes either crashing or load-screen freezing. Also, multiple nodes sharing the SAME bsLightingShaderProperty node; there must be copies of the node made and each mesh pointing to a different one or the game crashes. I'm sure you'd notice something as severe as that, but there could be other, more minor, issuesis my point.

Personally, I'm going to wait until the people at NifTools create a solution... unless someone else (like the one you suggest) creates something which is proven to be bug-free and capable of everything I need it for. Not for nothin, but I use the 3.7.2 max plugin - the one(s?) since then never worked for me... destroyed my meshes.

Yep, nif files are complicated. There's a lot of scope for things to go wrong - and not just with the NifUtilits stuff - but by the same token, there's also a lot of scope to check nifs over and fix them up in Nifskope.

I've tested them in-game without problems; not with an FPS counter, though.

I'm also hoping that this is just a stop-gap solution, and that Nifskope plus the various importers/exporters are updated to support the new Skyrim stuff properly. This seems to work for now, though.

The NifTools people are working on it; but the problem (from what I understand) is that the new collision requires a new plugin for 3DSMax. This should work in tandem with the havok plugin; which currently does NOT export collision, only animation data. I have no idea if anyone is still working on the Max plugin; that was being done by someone other than NifTools I believe.

I doubt a real solution will be any time soon. Until then, we just have to make sure things are tested for what we already know. I haven't seen that new app you guys were talking about before.. NifUtil is it? Maybe that'll help. But getting concave collision to work should prove to be whoever's greatest challenge... anything not in the MOPP format crashes the game; and using the OLD plugins for Max doesn't work because the rest of the NIF structure has since changed... maybe someone should try hacking the old plugins for the MOPP code and chunk it into the new plugin somehow (I think it was removed as unnecessary in recent versions).

well no max plugin no possibility for the collisions then ... is it possible that no one cares to give a fix to the 3dsmax plugin?

Someone tried to, and it's on the Nex.. but I tried it early on and it destroyed my meshes. Since then I think a newer version came out, but I haven't tried it. I'm not sure WHY noone wants to work on that; it seems that without IT, much OTHER work with NIFs is kinda senseless. Splicing collision from one NIF to another only gets one so far (and bloats the file size). And using the CK's collBoxes can get kinda ridiculous if using them for an elaborate interior or some sort of large, detailed object.

I'm not a programmer, and I don't currently have the time to learn any languages in order to do this either.. heheheh. So until then, I just wait patiently and try to work around it.

The NifUtilits tools allow concave collision.



I've been using v3.7.3 (http://skyrim.nexusmods.com/downloads/file.php?id=5622) for reference. It does have problems - which have been widely commented on - like not exporting vertex colours, but it's what there is at the moment.

I'm not sure where you're getting the filesize bloat thing from; I haven't seen anything like that. If the placeholder collision is more complicated than the custom collision I replace it with, the filesize shrinks - and if my custom collision is more complicated, the filesize grows a little; about what you'd expect, overall.

The ONLY feature I use in 373 is to create accurate shapes of primitive collisions. For everything else I stick with 371, as it has no that UV sets issue, and exports vertex colors data properly. If not for that partial collision support I wouldn't have bothered myself with 373 at all, as it introduces more bugs than fixes or new features.

I am using it and I have no issues with vertex color exporting why you say that? the only issue I have is that the exported items do not have enabled the normal maps and I need to set manually all times setting to 4097 the has uv number so that gets binormals and tangents as well ...

I had carried out simple test and 373 exported vertex colors correctly. And that UV sets issue is not present in 371, so that's one less thing to worry about in the workflow if you constantly create plenty of various meshes.

v3.7.2 is the plugin I use; while 373 is the one that I had problems with and abandoned. I think 371 is actually still the old one for FO/Obliv isn't it? Using FO settings, then changing some of the data in NifSkope allows it to work though. Nothing I've tried or used gives a 100% usable product though... there's ALWAYS some tweaking or hacking that needs to be done in NifSkope.

I haven't tried that NifUtil thing, but it sounds like I should bump that up near the top of my list. I was referring to file bloat because the only way I know to get concave collision in a custom NIF is to splice it over from a Vanilla NIF. This requires ALL the geometry data to be copied over though... as the MOPPtree collision is dependent on the geometry. This means that there's an extra mesh in the NIF... even when the tex data is removed (and it's set to be 'inivisible'). I suppose I could be mistaken, as I didn't really delve into this too deeply. I never actually used this technique, because of the bloat.. and having to piece together a super-franken-mesh to get the various pieces of collision to represent my object accurately.

But if that NifUtil app allows you to create the MOPP data from your custom geometry, then no... there shouldn't be any file bloat, as it would already be in the format intended; without having that extra geometry present.

[EDIT: type-o]

What you mean for concave collisions?