Jump to content

DOWNLOAD MODS

Are you looking for something shiny for your load order? We have many exclusive mods and resources you won't find anywhere else. Start your search now...

LEARN MODDING

Ready to try your hand at making your own mod creations? Visit the Enclave, the original ES/FO modding school, and learn the tricks of the trade from veteran modders...

JOIN THE ALLIANCE

Membership is free and registering unlocks image galleries, project hosting, live chat, unlimited downloads, & more...

Artisanix

Allies
  • Posts

    210
  • Joined

  • Last visited

  • Days Won

    8

Posts posted by Artisanix

  1. They still have a finite number of Read/Write cycles before they stop working...... certain functions also will not work with SSD's in a raid configuration. (something to do with self defragmenting, don't remember the keyword/tricky phrase for it.)

    HY - please do not create urban legends about SSD to scare people away from them ;D

    Let me clarify some things... ;]

    It's not like SSD has finite number of reads - it only has finite number of writes. You can read from it infinite number of times without any degradation of the drive. So, let's say, after those five or more years of using it there will be no possible to write anything on some of its cells, but still those cells will be possible to read - in other words it will become a read-only medium over time ;]

    To prolong the life of current SSDs, companies install some additional unused cells in them, and in case of any basic cells degradation these will be replaced by those unused ones. Besides in normal use shear amount of activities on drives are reads and not writes - you usually install system, game, program once and later these are usually read from the drive and loaded into memory. Thus some additional system optimizations are recommended in case of SSD - like moving swap file to other drive or even delete it if your system has a lot of memory, turn off indexing files service under windows, move system folder locations for temporary files to conventional drive, etc.

    And as for that "self defragmenting" thing I can only say that any defrag- word should never be used in case of SSD - ever ;D

    Defragmentation can improve things a bit on conventional HDD drive, but its completely pointless for SSD, and even degrades SSD by unnecessary writes.

    The word you seek here is TRIM function ;]

    Without TRIM command the SSD needs to empty the content of previously written cell (even while such a cell is no longer used) each time when it needs to write something there and only after that it can write data to it. And TRIM command just empties such unused cells in background and in advance before they will be overwritten, so it speeds up the write process by various amounts (10% or sometimes even much more).

    Well, anyway, with or without TRIM command, in RAID config or else, SSD is always an improvement in speed over traditional HDD.

    Even while it is supposed to degrade its write capability over time - such period is still so long for casual user (many years - at least 5, 10, more?) that the whole system spec may change once or twice during this time until any replacement will be needed for such SDD ;]

    And those who install their systems on SDD never want to turn back to HDD anymore ;]

  2. Also it is worth to check the name of NiMaterialProperty. If it set to something else than EnvMap2 then the reflection map Oblivion uses is the same everywhere for particular object no matter where it is placed - in exterior or in interior. But if that material property name is set to EnvMap2, then engine will be using different reflection map for interiors - and that's that cheap plastic foil effect which looks acceptable for only specific kinds of objects, imho. So I try to avoid it for all costs on most of my reflective objects ;]

  3. And if you want to mirror a whole mesh along one of the axis and not only the part of it (good for cloning any kind of clothes or armor - boots, gloves, pauldrons, etc.), then you may want to use mirror modifier in object mode as it doesn't make the normals inverted, and you do not need to move your mesh later to that opposite symmetrical position.

  4. Have no idea what it was, but probably some inaccurate yet obscured and not so well documented collision settings... anyway, I made a new convex collision for the pot in Blender, and tested it in game - worked fine after few hard loads.

    Try to test it yourself - here - but make sure to use a clean save from the time until you tested it before!

    • Upvote 1
  5. some other things worth of checking...

    You can easily check whether item has been added to that chest by opening it. If the item is there and the merchant doesn't sell it still, then:

    Is that container has an ownership assigned to that merchant? As vendors don't sell objects from containers which are other than their own.

    Is this merchants sells such category the item belongs to? You can check this in merchant's AI settings windows.

  6. Did you make sure your motherboard will allow an 'un-even' number of memory chips?

    Witty wants i7 processor and these support triple channel memory architecture and so like motherboards for them such as that asus mentioned in spec.

  7. 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.

    Second, I'd like to hear more about the draw properties being set to Polyhedr in Blender. I have always done that with convex hull meshes, because when I use the script the default draw type leaves that dropdown empty.
    • Upvote 1
  8. 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 ;]

  9. 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 ;]).

  10. 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...

  11. 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.

  12. 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 ;]

  13. 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 :]

  14. I was referring to being able to fix the two-sided collision problem syscrucser was talking about. Where there is one mesh doing it, there are probably others.

    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 ;]

  15. 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.

  16. 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.

  17. 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 ;]

  18. 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

  19. 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...

×
×
  • Create New...