News:

Rings of Reznor!

Main Menu

Pink Gloss issue

Started by SickAlice, November 18, 2019, 11:11:32 PM

Previous topic - Next topic

SickAlice

Not to be confused with pink texture where the entire texture is pink (usually do to an incorrect texture assignment in Nif container). The texture properly is displayed however there is an obnoxious gloss of pink over the objects. This may be a nifskope issue or the model itself, I'm not sure.

- original 3d models where given the proper texture assignments before being imported.
- different models, see pic, that share the texture assignments do not have the issue.
- I attempted to assign some of the models directly to the ones that don't have the issue but the result is the same.
- Tried both tga and dds without resolve.
- Tried new and copy of models/nodes without resolve.
- Triple checked all assignments and all are proper.
- There's two different texture sets in play here having the issue.

What am I missing.



daglob

Have you checked the materials block? It may have a pink emissive color.

Cyber Burn

I would love to check it out just out of curiosity.

SickAlice

Quote from: daglob on November 19, 2019, 12:13:32 AM
Have you checked the materials block? It may have a pink emissive color.

Yeah, good call. But no. Several different ones as well some shared. I did manage to apply the issue to everything by adjusting the texture effect property. Noticed the scene root is broken so I'm going to try a fresh nif and transfer.

SickAlice

I fixed it though I don't actually know how. I figure it has something to do with a lightmap assignment. First when the nif is converted no matter how the Scene Root gets messed up. The children and effects where wrong. So I opened the unconverted in Skope and manually matched the correct values. Next my static transfer piece became broken at some point or another, I did a lot of copy and pasting so I dunno where. Anyways I had a similar piece I made awhile ago and used that one in place and it works.

detourne_me

Glad you got it sorted. I was just going to comment that it was definitely a lightmap issue. Sometimes parent nodes will have a lightmap, so even if the mesh pieces don't have one assigned, the game/ctool/rendering is looking for an associated lightmap.

I ran into this a lot when I was importing meshes, and had to go through node by node deleting lightmap data if I just wanted a simple mesh without effects (refl/glow/lightmap)

SickAlice

Ugh, more times than I count. Not specifically but one thing was off and I was rapid fire working and not checking my results, same as here. As it was the work had at least a piece for every standard node, then add some. So wherever the fault happened I copied it over too many times to find it. Reluctantly I recalled the old trick of bringing in a different donar that I already know is good. Still took a lot of rebuilding. I'm guessing a node had an incorrect lighting assignment. Then again as said all of the values for the Scene Root were also a mess so it's too hard to tell what happened here.

SickAlice

I figured out a better way to do all this using an old 16-bit game programming trick. I establish a "controller" for values. In my example I made a tiny box and weighted it then tossed it right in the basic meshes node. I figure the main models node has everything in order. Then assigned the properties of anything using the textures the box does to the box itself. Then another controller for the next texture set and so forth. Also makes the nifs pretty small since there isn't a bunch of texture info packed in them and instead everything just shares a couple properties.

SickAlice

I figured out what happened, the nodes in question had a TextureEffect property that was conflicting with the Scene Root TextureEffect property. Generally the nif should only have the one TextureEffect as both child and effect of Scene Root then every node points to that value.