Nifs for Lights from Lights, candles, etc. List

[ShadowDancer]

Originally posted by Razorwing
I like the squarish look of LightComCandle02.nif, but I think LightComLamp02.nif looks too squarish. I think the latter would look much nicer if the arms and legs had a soft curver.

No problem, I will rework it. It is one of the more difficult ones to do, in my opinion, and have it come out looking good. I will take another shot at it and see if I can improve it.

BTW, can I get a copy of the Light_Com_Candle_10? I wanted to make Light_Com_Candle_9 but wanted to make sure it was similar to Light_Com_Candle_10 in appearance somewhat since they look nearly identical. My playing around with ideas on it is currently at 217 KB when a added collision to it quickly, updated the tangent space info, added the AttachLight and 3 FlameNode0 nodes just now. I think I went a little overboard on the curves on the 2nd and 3rd stems. See the attached pic below for what it currently looks like in NifSkope.

Originally posted by nick_op
I find the best way of finding out the polycount in 3ds Max is with the Polygon Counter. Check out this image for where to find it. You can drag it onto the utilities list for easy access like I have. This method work better than the one suggested by Razorwing because it works with multiple objects.

That is soooo sweet. I like it a lot. Well, in that case, LightComCandle02 has 615 polygons and LightComCandle02NoCandle has 172 polygons in 3ds Max.

And my playing around with LightComCandle09 has 2961 polygons (ack!) after adding collision quickly to it, although that is less than some lights made by Bethesda (I checked one of the candleabras and it was almost 4997 polygons and weighs in at a hefty 287 KB in size).

@ Rzorwing: I just found out through experimenting that the capsule shape in the LightComCandle02 nif adds polygons to it, at least in 3ds Max, so I redid the collision the other way. It makes it 28.6 KB in size compared to 23.15 KB, but the polygon count drops to 339. Here is the new nif file without the capsule collision shape.

[SACarrow]

Strictly speaking, I don't believe you need to worry about poly count for simple collision shapes like boxes or capsules. If you look at those shapes in NifSkope, it can be seen that the info for those collision shapes is stored in terms of defining geometric data rather than NiTri* nodes. This accounts for the increase in size of the NIF.

Also though poly count must be budgeted for collision as well, that budgetary count is in a separate column. Collision and "regular" poly count should not be lumped together.

Steve

[ShadowDancer]

Originally posted by SACarrow
Strictly speaking, I don't believe you need to worry about poly count for simple collision shapes like boxes or capsules. If you look at those shapes in NifSkope, it can be seen that the info for those collision shapes is stored in terms of defining geometric data rather than NiTri* nodes. This accounts for the increase in size of the NIF.

Also though poly count must be budgeted for collision as well, that budgetary count is in a separate column. Collision and "regular" poly count should not be lumped together.

Steve

You are probably correct. And it probably doesn't make any difference on a file that small to begin with. But I figured its better to be safe than sorry. There is another seperate issue with the collision as well in that with no other way to do it easily, I added the capsule to the bhkrigidbody along with the bhkcollproxy, and that probably shouldn't have been done. It seemed to work fine, but I think we have enough experimentation with the MOPP collision already. I'll let Razorwing decide which he would rather use.

@ Razorwing: I redid some of that LightComLamp02 and attached a pic from 3ds Max. Let me know what you think.

[Razorwing]

Originally posted by ShadowDancer

Originally posted by Razorwing
I like the squarish look of LightComCandle02.nif, but I think LightComLamp02.nif looks too squarish. I think the latter would look much nicer if the arms and legs had a soft curver.

No problem, I will rework it. It is one of the more difficult ones to do, in my opinion, and have it come out looking good. I will take another shot at it and see if I can improve it.

Not sure which method you used to make the metal shape but if it wasn't a spline then perhaps you could try making it as such, with the vertices set as Smooth, and adjust the Interpolation until you get a good ratio between quality and facecount. (I usually use an Interpolation of 3 or 4.)

Originally posted by ShadowDancer
And my playing around with LightComCandle09 has 2961 polygons (ack!) after adding collision quickly to it, although that is less than some lights made by Bethesda (I checked one of the candleabras and it was almost 4997 polygons and weighs in at a hefty 287 KB in size).

I could chip in that indoor/outdoor use is a factor when it comes to facecount in the sense that models intended only for interior cells can have drastically higher facecount, like the candle you mentioned. Outdoors you have to moderate yourself (as a modder) and keep a watchful eye on the cell's facecount level while often enough indoors it's a challenge to come anywhere near the max facecount.

Originally posted by ShadowDancer
@ Rzorwing: I just found out through experimenting that the capsule shape in the LightComCandle02 nif adds polygons to it, at least in 3ds Max, so I redid the collision the other way. It makes it 28.6 KB in size compared to 23.15 KB, but the polygon count drops to 339. Here is the new nif file without the capsule collision shape.

I agree with what SACarrow said. The facecount of primitive collision is meaningless because it's not saved in the way faces of a visual model is. With a sphere primitive for instance the game just checks the radius of the sphere, not whether anything touches the faces of that sphere or not (unlike meshbased collision where the game does indeed check if the player bumps into the faces of it). The nif's filesize isn't important either.

I checked out the LightComCandle02.nif with mopp collision and saw that the collision you made has 230 faces. (If anyone's curious it's the Num Triangles value on the block details of the hkPackedNiTriStripsData block at the end of the mopp tree.) This is way too high. If you check out a comparable Bethesda model, like meshes > lights > middlecandlestickfloor02.nif for instance, it uses much less; in that particular case, 20 faces.

I don't understand why tazpn used bhkCollProxy helpers in his tutorial. Personally I think it's better to create a new mesh for the collision, like Bethesda probably did with that candlestick, and then give it a bhkRigidBody modifier with packed strips shape option and add it to the main helper like tazpn did with the bhkCollProxy helpers. I made a model with that method last night and it worked okay except it was a bit picky about the visual model being centered to origin otherwise the collision came out misaligned.

[ShadowDancer]

Originally posted by Razorwing

I decided not to answer each individual item, but overall, I am going to redo the collision then, using simple shapes and add them into a bhkRigidBody.

Did you look at the pic of the redo of LightComCandle02? I didn't see a reply about that. I think the top still needs work, but I like how the bottom came out. I was thinking about trying something similar for the top.

BTW, I think I have a lead on the Doors-Not-Working issue. Has anyone come up with a good reason for it yet? I am waiting for a reply from Seniosh to see if my guesses are correct.

[Razorwing]

Well, don't get me wrong I'm not saying that a long list of primitives is better than Mopp shapes. I don't believe that is the case. But mopp shapes are still mesh collision and it has to be heavily optimized, like Bethesda's is. 230 faces on a candle's mopp collision wouldn't work too well in my opinion. It would on an object the size of, say, a horse stables.

Originally posted by ShadowDancer
Did you look at the pic of the redo of LightComCandle02? I didn't see a reply about that.

Do you mean -this- image? I think it looks okay.

[ShadowDancer]

Originally posted by Razorwing
Well, don't get me wrong I'm not saying that a long list of primitives is better than Mopp shapes. I don't believe that is the case. But mopp shapes are still mesh collision and it has to be heavily optimized, like Bethesda's is. 230 faces on a candle's mopp collision wouldn't work too well in my opinion. It would on an object the size of, say, a horse stables.

Originally posted by ShadowDancer
Did you look at the pic of the redo of LightComCandle02? I didn't see a reply about that.

Do you mean -this- image? I think it looks okay.

No, I agree with you that a long list of primitives wouldn't be any better. But on the other hand, making some simple meshes with many fewer faces (I think my highest is ~36 and thats with multiple materials) isn't too hard to do. Honestly they worked fine for me, but thats not to say that with a lot more of those objects strewn around a cell there wouldn't have been an issue.

OK, I will get it in game when I get a chance, get a better image of it and UL the nif. Maybe even try a redesign of the top part as well - I still am not too satisfied with it for some reason and I can't really explain why.

[Razorwing]

One of my favourite anecdotes is from the time in autumn 2006 when I modelled a hundred or so original objects to fill out the whole order for new Dunmer misc items building on the desings of the old game. Back then non-packed strips collision was the only collision one could create in Max. Anyway I went about the job with good enough enthusiasm and filled a test cell with more and more objects. Finally the day come when I wanted to playtest my work in all it's glory. I fired up the game, coc'ed to my test cell... and nearly had a heart attack. The game literally crawled at maybe one frame every three seconds. It was a humbling experience to say the least and from that point on I had a healthy respect (if not downright fear) for meshbased collision. I almost always steered clear of that kind of collision after that incident, just because I didn't want to have to redo collision on my models again. I guess the jist of what I wanted to say is that the effect of meshbased collision builds up quicker than one might realize. It certainly did for me back then; one by one I'm sure any one of those models would have worked without a hitch but when they all come together in the same cell hell broke loose. Moppshapes might very well make meshbased collision 100% more effective but the danger of overshooting is still there in my opinion. (I'm not adressing this to you in particular by the way, I just felt like saying it)

If I could offer critisizm of the floorlamp it would be that the foot branches look somewhat too oval and the shape still feels too squarish. Perhaps a curved S-shape could work? I would also say that the curve of the top branches look unnatural, but I can't put my finger on exactly why. I think a smaller radius could lessen the effect, i.e. making the branches hug the base area of the body tighter. I also think the lamp would look even nicer with vertex color.

[ShadowDancer]

Originally posted by Razorwing
If I could offer critisizm of the floorlamp it would be that the foot branches look somewhat too oval and the shape still feels too squarish. Perhaps a curved S-shape could work? I would also say that the curve of the top branches look unnatural, but I can't put my finger on exactly why. I think a smaller radius could lessen the effect, i.e. making the branches hug the base area of the body tighter. I also think the lamp would look even nicer with vertex color.

I still am not sure how to tell which block to add NiVertexColorProperty to? Aside from that, I figured some in-game shots would make the lamp stand out better as to what is bothering me about it, but I still haven't gotten a clear idea on it. Here are some screenshots of it at any rate.

The curved S shape might work. Which leads to my next question being how many triangles am I shooting to stay under for this? S shapes don't come cheap if they look halfway decent in my opinion. Currently the top branches are cylinders and 3ds Max says the triangle count is 1365 (no collision involved, just what you currently see), but removing that little point on the bottom of the candle holders would free some triangles up towards the S shape.

[Razorwing]

Vertex color is applied in 3D Studio Max, by first adding a VertexPaint modifier and then selecting the vertices you want to color. You can either select vertices and then floodfill them, or select vertices and then paint by freehand on them; I almost always flood fill because I want exact control. When I want to make a fake shadow for instance I usually use pitch black at 50% opacity. It's possible to paint faces instead of vertices but it looks really bad if you do.

The only problems are that the exporter 1) doesn't add NiVertexColorProperty and 2) gives the whole model vertex paint info when perhaps only part of it needs it.
[indent][/indent]To fix the first problem, select the NiTriStrips/NiTriShape block and choose Node > Attach Property and in the new popup menu you get, choose NiVertexColorProperty. Vertex mode should be VERT_MODE_SRC_AMB_DIF and Lighting mode should be VERT_MODE_SRC_AMB_DIF, or in other words, doubleclick both data snippets in sequence and just hit the down arrow as far as it goes.
[indent][/indent]To fix the second problem, select the NiTriStripsData/NiTriShapeData block of the mesh you want to remove vertex color info for. In the Block Details window, find the entry called Has Vertex Colors which should have a 'yes' to the right of it. Doubleclick the word 'yes' to change it. If the mesh had vertex color you'll notice the change in the viewport, if it doesn't then you can't tell anything happened. Once you save the nif again the redundant vertex color info will be cleaned out.

I wrote an old tutorial on the subject which still has some useful info in it.