Artisanix

It's nothing wrong with using convex hull script, but it's good to know such collision properties and limitations, and how it is different from other types. What I meant there is that in some cases more important is the type of collision than its shape. You can have more complex collision that has far more vertices than much simpler one, and yet it will be more efficient and performance friendly than the latter. And that's because of inaccurate types of collision assigned and not their shapes.

Arthmoor - That's exactly what my tests have shown... luckily such things like inverted normals on collision are easy to test/spot if you have some experience working with them. Though very rarely still there may be other cases of similar behaviors where the culprit is broken collision data or some other obscured and inaccurate settings - then just re-exporting collision may fix that without actually any other changes to it. syscrusher - Glad we had this long though interesting discussion, as it put some things into various perspectives for us ;] And that is always beneficial. And your beginnings wasn't that much different from mine or others. As modding for Oblivion may always surprise you even while you think that you've seen it all ;] For instance I remember an interesting behavior from one of my collision in the past - that was a wooden floor and during the tests everything was fine - player could walk on it with proper sounds, arrow fired at it sticked properly from the floor, etc. great! But everything changed when second arrow was fired ;p Then it just passed through the floor as it had no collision at all, and player and clutter objects on it were starting to sink into the floor then :> Well, can someone try to explain that? ;] Anyway, as this is a thread about optimizations, I can share something that I observed many times but the consequences of it are rarely discussed ;] I mean that I've seen many posts and requests on these and official forums how to convert misc/clutter objects to statics. And most of the time the answer is to change particular collision's settings in NifSkope. While this is the easiest way to have such change to object's behavior done and often the only way for someone who has a zero experience in modeling applications, it is not the best way to do so as it may affect performance greatly in some cases. The main culprit is the convex collision here. While swords and other weapons usually have the simplest of all shapes as collisions (cylinders or boxes), so "converting" them to statics in NifSkope won't hurt the performance much. But it is much different for all other misc objects that have convex type collision (like all pottery, potions,etc.). The same with beginning modders that start their adventure with Blender - I've seen many complex objects (released even as resources used later by others) with convex type of collision. Well, I can only presume that it is caused by a relatively easy way to generate such collision (scripts -> hull -> convex). And the problem with convex collision is that it is not optimized at all for static objects and in same cases it may reduce performance by really significant amounts. That is true especially for very complex models like miniature statues, buildings, ships, etc. if they have convex type collision the performance may drop even by a dozens of FPS when these objects are being viewed from certain angles. To fix this is to either create a new collision from scratch manually or just change draw properties of such convex collision to polyheder type in Blender. This on export will make it as hkPackedNiTriStripsData and generate additional bhkMoppBvTreeShape block which contains optimized data related to this collision. The difference in performance between "pure" convex collision and the collision that has exactly the same shape and which was changed to polyheder type (NiTriStrips/Shape) may be sometimes quite huge, and it gets greater the more complex object and its collision shape are. Well, these are my small 2c to this topic ;]

syscrusher - forgive me to not commenting on your long post now, as it's quite late and I haven't read it carefully yet, but in the meantime I carried out some few simple tests and now need to take some sleep... ;] I created a simple plane, then duplicated it and created collision with exactly the same shape. Double sided button was unchecked for both (plane and its collision) all normals were facing in the same direction. Then I dropped four copies of this plane into the testing hall cell. Two in horizontal and two in vertical position, and the two rotated 180 degrees to face in opposite directions. And here are the results: - this plane is impassable for player no matter in which direction normals are facing - vertical plane acted as wall and horizontal as floor (my character wasn't falling down at all through the normal plane and through the plane with inverted normals), - such plane also acted as a barrier for all the spells - those couldn't pass through no matter from what direction they were fired, - the only exception were arrows - as I set collision's properties to be made of stone, the arrows shot from one side were blocked by the collision and fired from the other they passed through it like nothing was there. Then I imported this plane into the Blender and enabled double sided button for both the plane and its collision and exported that to check the difference. Well... there wasn't any at all. The collision behaved like one sided and there was no difference in file size or collision's properties... So, I'm still quite skeptical here... I understand that you do not want to give away your house mesh so freely ;] but in fact it is not needed that much. What should be enough for me to test is any kind of mesh with such double-sided collision. So if you would be so kind to generate some simple object (even without textures or materials applied) and create such double sided collision for it - that would be perfect. Because as all the examples here show so far, Blender can't generate such double-sided collisions (or at least no one here shared the way how to do so ;]).

nice, but the size of both files you put into that 7z is exactly the same and the content as well ;] edit: see you noticed this :] anyway I was just thinking... Blender uses PyFFI by default on every export, so there will be no any difference in size and content between them. But what about 3DS users? washington, you exported this from 3ds or Blender? :] Maybe try not to PyFFI the meshes from 3DS and test it instead...

I wasn't so precise there I admit ;] I put everything to the same bucket to make post shorter, but it doesn't change that much anyway. Of course the direction of normals is important for arrows or particles (and is recorded in collision data), and it changes nothing for the player (he still is blocked from both sides). But the double sided feature does exactly nothing - the collision is exported and works as it has only one side enabled.

err, guys, what you're saying is true but for normal meshes. If double sided button is pressed for particular mesh (plane for instance) then it "tells" the engine to draw texture on both sides of each surface and it adds NiStencilProperty to the nif file on export. That is perfectly clear. The point is though, that collisions are just different animals. That's why they are usually represented and treated as wireframes. Because such things like direction of normals, double sided feature, or other tricks that are related to normal meshes don't work for them (and are just omitted). Every single plane of collision in game just blocks from both sides, and it doesn't matter whether the mesh you had previously to make this collision from, had normals pointed inside or outside, solid or smooth faces, or double sided property - the exported data of such collision is always the same (just a very simple "list" of vertices and triangles and nothing more. That's why I fail to see (so far) how this can improve performance by such relatively huge amounts. So I can only suspect that syscrusher has something different in mind ;] - well, I really do hope for some nice discovery here (some kind of breakthrough) that could allow us to improve performance of collision more - unlucky not enough specific data from syscrusher so far, so I would like to see those meshes he uses and inspect the subject by myself to eventually confirm such good results he describes ;]

syscrusher - Thank you very much for your info, but... it's something missing there I think :] You haven't explained what exactly one-sided or two-sided collision means :] Well, I'm asking because I work with various collisions for years now, and read a lot of things about them in the past but never ever I've encountered such terms anywhere. This is the first time when I can read about one- or two-sided collisions. So without an understanding of the key element your posts about it aren't as valuable as they may be ;] So, please post two pictures - one with one sided collision and another with two-sided, or even better (if you want) - upload those two nifs with different collisions somewhere, so others could check them and learn something in the process :]

The point is that there may be no such problem as "two-sided collision". Because from my point of view, with all the respect, syscrusher rather complicated things than explained them in his post ;] First he needs to explain what exactly the "dual-sided collision" means :] Because if he refers to just a simple shape like plane, then well, there are legions of these in meshes - every regular wall has them, every interior floor and ceiling, etc. Besides, in his post in pt.2 he mentioned some 35% performance improvement and made a conclusion that those "two-sided meshes" are responsible for this :] Yet he uses collision that has 400 polys to test this and original one had 3400 polys - so to me it looks like that gain in FPS was because of much less detailed collision overall than an any influence of those "two-sided meshes" ;] Really this case needs to be explained better as you may suspect the specific problem where there's no any ;]

You mean collision? Well, PYFFI or any automated tool can't correct badly made collisions properly. As the best collisions are still those made "manually" by a human, who decides which portion should be detailed and accurate and which can have a simpler shape (that all depends on context in which model will be used). As for such meshes there are a few, some ayleid roots come to mind which have collisions exactly the same as models - and that really puts some strain on performance if you use them in great numbers.

Not really, that's the message I got many times when working with particles like will 'o wisps and others. It started to show after I upgraded NifSkope to some newer version, but never bothered with that as everything is saved fine and works in game later.

DsoS - it's easy, you can do that yourself faster ;] - just open up fxdustfall02.nif in Nifskope, - search for NiControllerManager branch and expand it, - search for NiControllerSequence block and change its name from Forward to Idle - with NiControllerSequence block still selected look at its details window and change value of Cycle Type there from CYCLE_CLAMP to CYCLE_LOOP - save the changes and there you have it ;]

Why don't try and change settings of animation in NIF file instead? It's possible to make animation loop by itself, so there's no any coding needed then and such solution is more efficient and optimized than any of scripts...

try this one: scn SwordScript ref MySelf Begin GameMode set MySelf to DivineBlade If player.GetItemCount MySelf > 0 If getPCInfamy > 0 If player.GetEquipped MySelf == 0 Messagebox "You are no longer worthy of wielding this blade." DivBladeActRef.enable RemoveMe Endif If player.GetEquipped MySelf player.UnequipItem MySelf Endif Endif Endif End

QTP3 is a pure texture replacer so no esp there. And Natural Vegetation just increases the size of foliage, trees in particular. So no any conflicts between the two as they do completely different things.

These are problems with weights. Each vertice in cloth meshes has data that determines to which bones this vertice should be assigned and how far it should be located from them. What you see in NifSkope or Blender is the basic shape of clothing/armour in it's "resting position" without any weights to the vertices applied. And the game calculates all those weights of all vertices and changes the shape accordingly. In your case to fix this in blender in quite a simple way, would be to copy bone weights from arms to those arm wraps. Just select you arm wraps and switch to edit mode, and select all vertices there. Then switch back to object mode and with SHIFT pressed down select arms of you character. Then from menu chose Object -> Scripts -> Bone Weight Copy. Set quality to 3, press Update Selected button and hit OK and wait for a while until Blender finishes to copy weights. Then check object in game...

I think that dds are stored inside of NIF files (it was quite a time I checked this, as NifSkope didn't support D2 files back then) - I extracted all archives from Divinity II and there were no signs of any dds, just NIFs that had bigger file sizes than usually. And there were only NIF files in folders named Textures as well. >> Also, I understand that the new Dragon Knight's Saga is a significant improvement to Divinity II. I'm not so sure whether we can use "significant" word in this context ;] DKS is just the same engine but most of textures have been converted to high res ones. Besides in many places some FX effects were added or changed (like additional particles, lights, re-colours of those, etc. and in previously too empty places (floating islands) some structures have been build like towers, walls, etc. To make a simple comparison: Dininity II = Oblivion DKS = Oblivion + QTP3 + Unofficial patch + some other minor visual improvements + of course add-on like SI ;]

Actually when I think about this some more, the nif file can also store textures ;] Such solution is present in nif files for Divinity II game... but for Morrowind and Oblivion that's not the case of course ;]

Vince, thanks for providing more advanced yet far more accurate way of handling those light issues... in such a case Facing Normals should not be used in NifSkope I think... and I didn't propose to convert the whole sword to solid faces but only the blade, but anyway, well... ;] and one more thing comes to mind when I think about "improving" this sword - the hilt. In comparison to blade or guard it has too many geometric details, you may want to merge some of those vertices to make it simpler without sacrificing the quality that much.

You sword is bright not because of one but few things ;] alpha channel of normal map defines how shiny the objects is (how much light it reflects) - and most of it is too light in your texture glow map defines how strong certain areas of object glow, and you have set those to pure white update tangent space should always be used after you do some work in 3D app, as it does no harm to the mesh but fixes some texture distortions (in nifskope: spells - batch - update all tangent spaces) face normals command in nifskope (R-click on mesh and from menu: mesh -> face normals) should not be used most of the time, but in some situation on certain areas when there are troubles with light reflections from some triangles (visible as dark patches) it is quite often very helpful and eliminates those issues (like on your's sword handle) your sword's blade has faces set to smooth mode, so this makes it round and doesn't look as sharp as it could - in Blender in edit mode just select the whole blade and from menu chose Mesh -> Faces - Set Solid - this should improve blade's edges and it will look more sharp.

During system installation usually there's a chance (at the beginning) to repartition HDD, and install OS on one of the partitions. After system has been installed the only way to repartition a drive is to use a special kind of application that should be run (booted) either from CD or another drive or USB. In your case GParted should do the trick if you want to have more partitions than just C:

all is rather fine with your weapon, you only need to darken your textures and channels some more, and do couple of other things... - update tangent space for model, - make solid faces on blade instead of the smooth ones, - darken colour map texture slightly, - darken glow map texture and provide some details for it, - darken a bit alpha of normal map - set emissive color to white - face normals option in Nifskope can fix reflections on handle also this is very trivial mistake, but make sure you do not test your weapons on character that has some enchantments on apparel or armor as it makes the whole character (with weapons included) to glow with a cheap reflective plastic effect... of course if you have the mod that removes such glow, then all should be fine...

I could ask many question, but to save the time you could upload a mesh somewhere and your textures - just quick look and all will be known ;] Anyway: If you have emissive colour set to something else than black you should use a glow map file _g that defines areas which should glow, otherwise the whole object will be emitting the light.

In fact that's most about one specific feature it offers. Fishtanks with lava material property for water are animated because they have waves which can be controlled via settings in CS. Of course for small fishtanks this makes little difference as usually these are supposed to be filled with still water, so greater waves are rather unrealistic there. But if you want to have bigger fishtank it's a nice feature to have a possibility to animate the surface of the water in easy and configurable way. And don't misunderstand me - I'm not arguing which concept is better or else, I only try to explain things... ;]

Actually there's no that much of difference between Phitt's and Korana's fishtanks in the game for the player. Only testing requires clean save because of water's behavior. But notice that every player after download of your mod will be visiting that cell for the first time. Well, Korana's mod has thousands of downloads so far, and many comments - I browsed through some of them in the past but haven't seen any complains about the fishtanks at all :]