That might be useful for a few cases, but in most, why not just make a new version of the skin and alter it's RGB values quickly? I mean, it's just the diffuse that needs to be changed, and if you have it layered properly, it's trivial to do it at that stage.At least a way to merge uniform color into existing vpaint is needed. Currently it overwrites.
There is a thing called optimization and texture economy. It mattersxenoargh said:That might be useful for a few cases, but in most, why not just make a new version of the skin and alter it's RGB values quickly? I mean, it's just the diffuse that needs to be changed, and if you have it layered properly, it's trivial to do it at that stage.
Don't worry. I have heaps of experience both with what should an optimized mod look like, both texture-size and vertex-count wise, and what v-painting is capable of.xenoargh said:Huh. I thought what I was doing was already pretty optimal- I have more items using less space than any of the other major projects.
But more to the point, it simply won't let you do what you think it will. Colorizing armor variations that way looks pretty bad, because of the way the RGB values get skewed, and because it's vertex values, you'd have to start modeling in a lot more details into your armor to see much benefit, which would totally hose performance- texture throughput is not the killer, it's vertex count.
I did not see you asking about the example. Instead I saw you doubting this feature as needed, suggesting new texture sheet for every color variation. The latter thing in turn made me doubt you understand how it works with large mods, where texture space is hitting the upper limit.xenoargh said:Then show us an example of a use case, instead of being rude, please. All I asked for was a legitimate use case. I really don't see why you want this feature so bad, and nothing you've said thus far indicates that you understand how it works.
I guess what I'm trying to say here is that I'd like to hear a lot more about the possible use case- I'm unconvinced that this would greatly improve the tool, and while the AO's wonderful for stuff that didn't have it before, largely because we don't have to go back and do AO passes on the skin, it's not something that we couldn't do in Photoshop, with help from Meshlab. What could you do with a vertex painter that would make it really powerful and worth the effort spent developing the UI for it?
Well, if that's what you want, then allowing a combination of AO + color skew would get you there the vast majority of the time, and mtarini could do that by simply multiplying the RGB value by the AO (if the RGB < 1.0). But it's hard to see how that's not going to occasionally look pretty awful, unless the skins are basically grayscale or pretty close; you can probably get a better effect by being more careful about developing the skins and using atlas techniques for detail areas, so that you're using as few materials as possible per rendering pass.I don't want a new sheet for a slightly different color tone, it's subpar. Is this convincing enough?
We were discussing color merging fix, not v-painterxenoargh said:I guess what I'm trying to say here is that I'd like to hear a lot more about the possible use case...
I was tempted to reply with "Thank you, Captain Obvious", but then, you are obviously giving good-natured advice, and I'm in a pretty bad mood today.... allowing a combination of AO + color skew would get you there the vast majority of the time, and mtarini could do that by simply multiplying the RGB value by the AO (if the RGB < 1.0).
... unless the skins are basically grayscale or pretty close;
... developing the skins and using atlas techniques for detail areas
Very true- it's all been very useful thus far, and it's equally awesome that people are using it in unexpected ways.Everybody has a different modding style and different purposes, and I've been often surprised at the ways some feature gets actually used (*) (for example, I've heard someone employing the feature to customize background---which was implemented just because it is so plain to do so, but I believed to be of next to zero practical usefulness---in order to make screenshots and use them as alpha-cutouts textures).
(*) and also at which non-existing, unexpected but totally sensible feature gets requested
Barf said:Do you think something like this is feasible within OpenBrf http://www.bytehazard.com/code/vertnorm.html (re-evaluation of vertex normals based on surface area).
mr.master said:Would it be possible to add a feature that copies everything that is tied to a mesh? Basically, you could configure so that when you example copy a mesh and want to paste it to another instance of open brf or another brf file, it would copy the materials and textures too which were tied to the mesh.