nifskope/GECK problem!

[Monticapone]

OK...this one is weird:

I made a weapon with niftools. Now I want to put it into GECK (like I did several times before). It starts with getting a first person model in (static). I make a new one and I select my nif file. But my weapon just wont appear! I try all this with 3 other models and it works. But not with this model (and not with the silenced version).

When I just ignore this and save the static model, and I preview it in GECK, GECK crashes....

What can I do about this?!

[mechine]

Bare with me I had to chop up this message after I wrote it.

 

The process of moving a mesh from textureing an 3d preview, into the geck is pretty simple, an also the same kind of think can be achived as with shrinking texture sizes down. Nifscope, for one thing will auto sanitize the mesh when saved, which is about a 5 step process done automaticly at save, so really all you do is perform the spell Stripifiy all shapes, then update all tangent spaces on all the different shapes then save. Stripifiy or triangulate might make the mesh work better one or the other depending, but I tend to lean toward stripifiy. Then so long as the mesh is built following the rules of what a known good vanilla mesh looks like in the block list, then update all tangent spaces on each of the shapes just to be sure takes care of things when it crashes when you load it as a model in GECK. Update Tanget spaces can be performed by right clicking the parts of the shape, then batch, UATS. There are rare cases where you are making the kind of item that was never meant to be made which will crash geck even then, but it's rare, you're more likely to have problems once in game than have problems in GECK with something like that.

 

 

But I mean if you have your method and like the bethesda way of having simple models and then complex active models then by all means, keep up the good work, as it's good practice, but at the end of the day it means more work. So some thought should be put into which items the method would better be suited for. Like say meshs an textures with huge file sizes, because it's really only a way to fine tune. Most of the raw data in a mesh is the triangles anyway, can't really get rid of those.

 

 

 

Another little trick is to use nifscope to set the textures a mesh uses rather than GECK, because GECK takes too long, it's more work, after you get good at it, you can do it without having to write down the folder path. The GECK alternate texture method is really only good if you have one mesh with 30 different textures and versions, then it's faster.

 

 

Update those tangent spaces then do a little happy dance when it doesn't crash the all powerful GECK!

 

 

 

Well what do you mean by static? To my knowlege static means it doesn't move. If you get killed the weapon flies off most times in havok. So it's not really static, but I digress. I never even bother creating "statics" (world models) Or 1stpersontextures for the matter.

 

While true they are a performance based issue, in the form of either freeing up video card memory, in game Cell memory, and making 1stperson weapon models look higher res because they are larger (since you are close up)

 

However I fear that the gains you get from these are minimal at best, you really would only need it in cells where you have 8 or more lights shining on 50 weapons or so. You can fit a whole lot of weapons inside a cell before it will drag the system down, which mostly depends on the lighting. Plus you can always put 25 in one cell then 25 more in another sell or set half to be culled with walls an portals.

 

 

Hence saving half the work by just making one model an texture set. You can take a 4096X4096 texture map, then reduce it in steps, saving each time, then reloading, in best quality super sampling, At 96 pixels per inch, which brings that super huge high res map down to 1024X1024 1/4 the raw data's file size, then encode it with DXT-1 which will bring it down to 1/8 the size because most of our textures don't need a alpha map or even have one DXT-1 ignores alpha, hence the 1:8 compression, which DXT is special compression for video cards, so that we don't eat up a bunch of GPU RAM (video memory) A map of 4096X4096 @ 96 pixels per inch looks just like a 1024X1024 map @ 96 pixels per inch. You only lose maybe 4% of the detail 95%-99%, which by all means you would be hard pressed to tell the difference when on a 3D preview of the item or ingame. Then the DXT-1 isn't like Jpeg, the file which is now half the size is identical. One of the files is 5Mb in size the other is 600Kb. Figured it out last week, and wrote a article on it. But the savings you get performance wise while keeping the detail is an order of magnatude larger than messing about with different models.

 

There's a article I wrote on it @ http://www.fallout3nexus.com/articles/article.php?id=208

 

But the important thing isn't my chaos performance article, there's a whole article section on Nexus downloads, which deal with complex issues which help You an I get better at making stuff, which means more fun for us right? Check out the articles, woot.

[Monticapone]

I already figured the problem (together with some guys at Bethesda Forums), it was the laser pointer that somehow caused all of this to crash :)

 

But thanks for your huge article and all the advices, I will try to follow them in future :)