The Harvest Moon Consortium

[Helvene]

Estelindis, I'm sorry for responding here on your post on NWVault, but I'm having a strange bug that doesn't let me log into it from any other PC that the one I use at home.

1. Relinking all semi-transparent elements to a model a-node doesn't always work. Most likely you'll need to do both: remove all semi-transparent parts from the texture and link all semi-transparent elements to an animation node.

2. I'm not adding your fix into the pack until I'm able to check it today or tomorrow evening. No offence, but a 50% reduction in size means a 50% loss of data, and I simply must see with my own eyes that everything still works and looks fine. I hope you'll understand that.

[lord rosenkrantz]

2. I'm not adding your fix into the pack until I'm able to check it today or tomorrow evening. No offence, but a 50% reduction in size means a 50% loss of data, and I simply must see with my own eyes that everything still works and looks fine. I hope you'll understand that.

The bulk of it usually is unused and welded tverts (which 3dsmax keeps multiplying every time you attach/detach polygons), and other clutter data that both the engine and external compilers discard when converting the ASCII code to binary. CM3 also uses a slightly more compact ASCII formatting, which also partially explains the loss of size.

Overall, CM3 does to the models what NWMax is supposed to do but is unable to, I never encountered any loss of significant data after running any models through CM3.

[edit]

Oh, and in case connection issues prevent you from getting my gtalk message:

1. Relinking all semi-transparent elements to a model a-node doesn't always work. Most likely you'll need to do both: remove all semi-transparent parts from the texture and link all semi-transparent elements to an animation node.

The best solution (although not always fitting aesthetically) is to associate a txi file to the texture and add the line "blending punchthrough", which forces the engine to consider 100% opaque everything that isn't 100% transparent. That will fully get rid of any borders, and allows you to link the meshes directly to the aurorabase instead of the a-node.

The transparency issue does not go away if you up the contrast between the black and white areas in the texture alpha, contrary to what logic would tell. Even alpha channels with no semitransparent areas cause the bug in game.
From the behaviour shown in game, my guess is that the rendering engine calculates all texture transparencies first, decided what parts of the background objects show through the alpha, and only after that resamples the image accordingly to the camera. Since the resampling algorytm causes the texture to blur, it also blurs the alpha channel edges, creating that semi-transparent border regardles sof the alpha channel sharpness.
Since the transparency calculations have been done already, the engine ends up rendering a semi-transparent border that doesn't show through the objects in the background (except fog and lighting apparently, causing the bug to really stand out).

Or at least, that's the theory I constructed after all the time wasted trying to fix the bug without using punchthrough, but I switched long ago

[Estelindis]

Estelindis, I'm sorry for responding here on your post on NWVault, but I'm having a strange bug that doesn't let me log into it from any other PC that the one I use at home.

No problem!

1. Relinking all semi-transparent elements to a model a-node doesn't always work. Most likely you'll need to do both: remove all semi-transparent parts from the texture and link all semi-transparent elements to an animation node.

Funny, but I actually tried removing all semi-transparent parts from the texture as well, and it didn't seem to work. I mean, I selected the edges of the leaves that were fuzzy, expanded the selection by a pixel to make sure I got everything, sharpened the selection to make sure it wasn't fuzzy at all, and then cut it all from the pic... Yet, when I checked that in the toolset, it still showed the odd border (plus, the more sharply pixelated edges combined with the bright border gave a very unpleasant look). I'm really confused, because we used a *lot* of transparent textures in the CTP sets I've worked on, and the problem's gone away when I linked to the a-nodes. Oh well! Mysteries of NWN...

2. I'm not adding your fix into the pack until I'm able to check it today or tomorrow evening. No offence, but a 50% reduction in size means a 50% loss of data, and I simply must see with my own eyes that everything still works and looks fine. I hope you'll understand that.

Of course I do! I think no one who has any pride in their own work would add a "fix" that someone else had performed before testing it themselves.
Regarding the nature of the CM3 fixes, I will just agree with Rosenkrantz's explanation: on a typical run, it's mostly t-vert info that CM3 cleans up. I disabled some CM3 options, like object splitting, because I'm not always a fan of the results if they're applied haphazardly, with no regard for the particulars of a model - it's the job of the modeller to judge when to use such a function, not a problem of OMB's work. All I enabled for the CM3 run on these tiles was decimal snap, repivoting of objects (top) if needed, and the animation of any objects using textures with "fol" in the title.

I really do recommend using CM3, by the way. I find it immensely useful. However, one does have to know which options to enable or disable, based on the particular model. When I use it to clean up head models, for instance, I have to disable nearly everything, otherwise it turns the heads into horrid, square monstrosities. :icon_eek: But it does clean up the t-verts, still, for those of us (like me) whose UVW mapping is not as elegant as Rosenkrantz's.

[Dragonstar]

Although a month late, I must add to what the others have said: Great work to spruce up the old Bioware trees! I love it.