Suggestions/requests thread -- post yours here

Users who are viewing this thread

mtarini

Sergeant Knight
This is the suggestions/requests thread.

OpenBRF is used by different modders in different ways. Often possible features of great potential usefulness are very easy to add, only I didn't know or didn't think about them.  So just post your ideas here.
 
Speaking of which... a while ago, a recurring suggestion was the addition of a embedded vertex painter. Is that still useful?

Longer digression:

In M&B, meshes can come with per vertex color. This can be a very powerful thing to have.

A embedded vertex painter interface is a little tiresome to implement, plus it would encumber the OpenBRF interface (which I try to keep lean) a bit. Also, a drawback would be that if you import a mesh, then paint it in OpenBRF, then change the 3D (e.g. move a vertex or a UV coord), you would have to reimport it and lost the handpainted colors.

This is why I imagined that a better way to get colored meshes would be: you color the mesh in an external 3D modelling application (e.g. meshLab), then save the mesh in a format that included per-vertex color (that is, currently, only .ply), and then import that file in OpenBRF.

Notwithstanding these costs and disadvantages, maybe a vertex painter would still be useful, until recently.
But the main reason one wanted to paint vertex color is to paint "baked" global lighting on the meshes. Now, Ambient Occlusion computation can do that for you in one click, so I wonder if a painter would still be useful.

I'm asking because maybe there's a volunteer to implement that.
 
My thought on vertex painting:  no, because you can do the equivalent very easily through other methods.  The AO burns currently in OpenBRF are a useful and powerful feature that extended the software in a useful way; the other possible uses are things that are best left to manipulation via Photoshop, etc., imho.
 
At least a way to merge uniform color into existing vpaint is needed. Currently it overwrites.

Basic vertex painter is needed too, if only for correcting specific vertices colors or quickly add your own shadows to a not-so-good initial AO. Also for quick color variations of meshes. Meshlab is pretty cumbersome in this reagrd, and its vertex-selection algo for v-painting is outright dumb (it fails to detect vertices inside brush circle like 1/2 of a time, you need to reposition a mesh and generally waste a lot of time ot make damn program paint a color on a specific vertex)).

mentioning Photoshop as alternative = not understanding the issue :smile:
 
At least a way to merge uniform color into existing vpaint is needed. Currently it overwrites.
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.

On the vertex thing.... it really would be a non-trivial feature to add, and it'd be very difficult to get it to work really well; granted, mtarini has already got some raycasting code built, but it's still not exactly simple to build it in a way that would both be easy to use and actually useful.  The problem with any vertex-based solution is that you're going to hit limits based on resolution of the mesh; it's all right for AO, but it wouldn't work to recolor most armor, for example, because the armor's not 100% modeled detail, a lot of it's done in the skin.

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?
 
xenoargh 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.
There is a thing called optimization and texture economy. It matters
 
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.
 
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.
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.
 
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 am fine with vertex painting my objects in Meshlab, Mount & Blade blends any vertex color as a multiply pass anyway which doesn't leave much room for altering color unless you desaturate and really boost the contrast of your underlying texture.
 
Exactly my point.  Moreover, at least with armors and weapons and such, it gets overridden by the engine when it handles "blood".  And for buildings, it's just not that useful- who wants their RGB skewed like that, when throwing another skin in is reasonably cheap in most scenarios, compared to other factors?
 
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 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.

Simple enough example is scene screenshots from TLD thread, with Gondor cities using one hi-res normalmapped brick sheet for all of the AO vpainted buildings. I don't want a new sheet for a slightly different color tone, it's subpar. Is this convincing enough?
 
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?

I don't want a new sheet for a slightly different color tone, it's subpar. Is this convincing enough?
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.
 
xenoargh 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...
We were discussing color merging fix, not v-painter

...  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
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.
Also, you are welcome to try pinpointing needed RGB with hue sliders. It's not that easy
 
With almost any given option, most people will never find an use for it, while a few will use it, even heavily.
In this case (vertex painter), I was just curious to know whether the latter set of user was more-or-less empty, or not. It seems it is not, but I give it for granted most users would not need or actually use it.

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
 
A very basic vertex-oriented shadow intensity tuner would be enough for a v-painter. 95% of time I want to quickly tweak shadows on a meshes inside brf. 5% of time I can afford struggling with Meshlab, for all other vpainting needs :smile:

Since there are only 2 types of operations needed for shadow tweaker (decrease/increase shadow intensity), a usage of left/right click (and click-and-hold) seem to be enough for an interface. With a cursor dragging a preset small circle to see paintable proximity.
 
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
Very true- it's all been very useful thus far, and it's equally awesome that people are using it in unexpected ways.

Anyhow, I'd certainly support something that allowed for shadow tweaking with a mix of RGB values as described.  It'd make GetAssista happy and it wouldn't be a giant pain in the neck to implement the UI.  My thought on how to do it- have a slider, where middle is RGB * AO shadow value, left pushes the AO values towards 1.0 RGB (i.e., increases the vertex color value) right does the opposite.  Simple, easy to use, and it'd probably prove quite useful for that specific situation, as well as letting me do stuff like emphasize the blue slightly in AO burns.

Oh, and it's all right, GetAssista; I'm familiar with the "not in good mood" scenario.  I usually don't let myself post about things like this after a certain hour :wink:
 
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. Then when pasting, you would get everything related to that mesh.

If possible, Id like it to be configurable that does the user want the future on or off.
 
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).
Something like this could be used to improve the shading on a massive amount of models.
Here is a skeletalized horse I am working on, notice how the shading on the ribs gets pulled toward the tips of the bones.
skeletonhorse2.jpg

I sometimes manually edit my vertex normals to remove shading problems and it can take a decent amount of time.
From what I can see not many people even bother with this step, but it can be really worth it.
Also afaik this technique as a tool doesn't exist outside of proprietary workflow, ie Doom3, Crysis, and can't be found in any modelling packages
or as a plugin...oddly enough.

 
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).

Terrific model!

I'm well aware of normal computations... unless I'm mistaken, OpenBRF already does face-area weighting in normal computations.

(tech-detail for the tech-curious: weighting normals with face-areas is actually easier than doing otherwise, because area weighted face normal is what you get if you don't re-normalize the normal computed as the cross product of the two edge vectors of a face).

I confess that I didn't add angle weighting just because I'm lazy.
I see now it can be important to perfectionist (prise to them!). Ok, will do that.

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.

I could add a special "Copy Mesh+Material+Texture" command inside the "Edit" pop down menu, maybe with ctrl+shift+c as a shortcut.

(is this needed even if textures/materials are to be found inside another file?)


 
Back
Top Bottom