Suggestions/requests thread -- post yours here

[Specialist]

i dont know if this was already suggested, but it would be neat to have ability to preview how the mesh would look like on horseback animation(in fact it would be nice if it could be previewed in all animations, on and off horseback, )

+1 Though it may not apply in all situations, that would be a great idea.

 

[mtarini]

it would be neat to have ability to preview how the mesh would look like on horseback animation(in fact it would be nice if it could be previewed in all animations, on and off horseback, )

If I understand your suggestion, it is something you can do already:

1- Locate the animation you want to use in your previews
    (e.g. search for it with CTRL+F).

(note: in native, some of the animations used in the game are all put together in a big animation, e.g. "anim_human".
If your animation is in these, and many mounted animations are, then you have to right-click on it  ==> [split with actions.txt].
This will break the big animations apart into the actual sub-animations. After doing step 2 below on the one(s) you like, you can just discard the modified animation file without saving: you won't need the split animations anymore)

2- Select the animation, right click on it ==> "Add To Reference Animations"

3- From now on, when you preview any rigged mesh, you should be able to pick that animation in the "Animation" drop-down list (inside the View panel)

4- Optional: later on, if you want to remove/change any animation in the list of "reference animations", including changing the ordering or renaming them, you might want to use: [Settings]=>[Edit reference data].

it is possible to have a replace fonction.

Reimport function: yes, actually this would make a lot of sense, and would not clutter the interface at all.

(Even if, sometimes, you want to re-import the mesh, but, before deleting the old one, transfer something from it into the reimported mesh -- e.g. color, rigging, uv-coords. This is because sometimes the imported mesh lacks a few of these data).

Edit: added in 0.0.77 (more info in Update notes)

 

[iggorbb]

Never said thanks for implementing copy/paste vert colors that I suggested earlier- so thank you. I have another one now- would it be much of work to add hexa code to "color uniform" option?

 

[mtarini]

add hexa code to "color uniform" option?

Sure, done (some fun QT gimmick).
While I was at it, I med the alpha channel editable too, and I made OpenBRF remember the last color used.

Will be in next version...

 

[iggorbb]

Great, thanks in advance.

 

[mtarini]

So, done in 0.0.77  -- link to [what's new]

 

[Zimke Zlovoljni]

For me personally what could be useful is computing ambient occlusion when z axis is considered as "above", that way non-rigged helmets could also get some AO love. <3

 

[mtarini]

For me personally what could be useful is computing ambient occlusion when z axis is considered as "above", that way non-rigged helmets could also get some AO love. <3

Right, good suggestion.

Even if, personally, I prefer to add Ambient Occlusion (baked global illumination) to any of my non-fixed object (including helmets) with [Light Coming From All Around] -- not [From Above], (reminder: you can set this under [Settings]=>[On compute Ambient Occlusion]), because otherwise it will look wrong when the object is will be oriented in game differently than expected. For example, consider that helmet models will appear horizontal when wore by dead people lying on the ground.

Regardless, the suggestion makes perfect sense. So included it (for next version), in the following way:

now, AO computation will consider which way is "above" depending on which view-mode is currently active (see buttons on bottom-right of OpenBRF window). Recall "helmet mode" is the mode with Z as above instead of, useful in M&B for visualizing helmets.
So, to have light coming from the Z instead of Y, just make sure you are visualizing the model in "helmet mode" when you compute AO.

Edit: included in 0.0.78!

 

[dia151]

is it just me, or this doesnt have undo option ? if it doesnt, it should have, if possible 

 

[Swyter]

is it just me, or this doesnt have undo options ? if it doesnt, it should have, if possible 

I don't think that is needed or fitting in a resource editor like this.
Apart than that kind of features are hard to make, boring and time consuming.

It takes a lot of time to plan and program the Ctrl+Z thingie.

 

[dia151]

i dont know how time consuming that is, but i belive you 

indeed, its not usually needed, but just a few hours ago, i was trying to rig armor that had 2 rigid part(2 plates that had to be placed on shoulders to be exact). Quick fix rigid parts made them not bend with mesh as intended, but they werent placed properly, they were kinda floating above shoulders. So, i used that make rigging softer/harder function.

When i clicked "make rigging harder" whole mesh was rigged harder and rigid part moved closer to shoulders. But, since it was riged harder, there were some ugly mesh colissions in some animations. Then i clicked make rigging softer and mesh rigging was revert to nice soft form like before but rigid parts stayed at the same spot and didnt revert (That was actually exactly what i needed)

I repeated that step until those rigid plates were in exact position i wanted them to be, but i overdid it and needed to do the procedure over again.  So yeah, thats where i got the idea it would be usefull 

Or if it would be simplier to make some better rigid part handling features. 

 

[mtarini]

It takes a lot of time to plan and program the Ctrl+Z thingie.

Sure, a bit, but the real reason is that I'm a bit lazy. Maybe I should have a closer look...

[succession of automatic re-rigging tools...] (That was actually exactly what i needed)

Glad to hear that.

Another trick you might want to use is to [split the mesh into connected components], so that you separate the shoulder pads etc. Now, you can act on different parts separately, for example by pasting the rigging from another mesh, smoothing/hardening multiple times, etc (or any other thing: assigning an uniform color, translate/rescale...). At the end, you join pieces back. A little tiresome, I know, but quite powerful.

Or if it would be simplier to make some better rigid part handling features. 

Sure, feel free to suggest practical ways.

But keep in mind that, in general, OpenBRF has no chance at becoming a sophisticated, complex, complete editor for rigging.
There are tools which do just that (blender, FragMotion, 3D studio max...).
As usual, OpenBRF just offers a small arsenal of tools which can do the bulk of work (in this case, rigging) quickly, but which give no guarantee that the results are final-quality. The need of manual retouches can never be ruled out (this is what import/exports are for).

(As for myself, I'll confess, I use OpenBRF also in another way. Say I need to fix the riggings only in legs for a number of meshes, or I need whatever specific functionality for just that once. I hack the functionality in the code, use it, then remove it before next release. Or, more precisely: I polish it a bit and then keep it, if it is decently reusable and I can find a way to make it accessible though an understandable interface (*); otherwise, I remove it. In short, I also privately use OpenBRF as a platform for my procedural hacks.)

(*) this is how, for example, the [Fix rigid parts] you mention was introduced, as well as many other features.

 

[mtarini]

is it just me, or this doesnt have undo option ? if it doesnt, it should have, if possible 

That was asked several times... but for some reason I felt too lazy do do that until now.
It is in in 0.0.78. Let's hope there's not too many bugs!

 

[dia151]

nice 

 

[dunde]

My mods have several sizes of races using skin scale. It leads to some bugs so I decide to change the methods to skeleton based. Thanks to  make skeleton-modification mesh and  modify from skeleton-modification mesh , and also reskeletonize armors features of openBRF, the process is much easier. The only problem is that when I reskeletonize the armors, and select to put the result into new vertex-ani frame, it always put the result to frame  #1. I want it to be placed to a new frame after the last frame of the mesh so I don't need to put it into a new mesh and then manually copy-paste the frame back into the original mesh.
And is it possible to batch the reskeletonization?

 

[Mandible]

Here's a request for you. Is there a way for OpenBRF to mimick the (frankly annoying) way that Mount and Blade mirrors the face mesh and applies the second half of the texture to it? I find it really difficult and time consuming to make custom heads when I have to compile and test in-game between each small change of the texture. A function that showed you what the mirrored head would look like would be greatly helpful.

 

[mtarini]

My mods have several sizes of races using skin scale. It leads to some bugs so I decide to change the methods to skeleton based. Thanks to  make skeleton-modification mesh and  modify from skeleton-modification mesh , and also reskeletonize armors features of openBRF, the process is much easier. The only problem is that when I reskeletonize the armors, and select to put the result into new vertex-ani frame, it always put the result to frame  #1. I want it to be placed to a new frame after the last frame of the mesh so I don't need to put it into a new mesh and then manually copy-paste the frame back into the original mesh.
And is it possible to batch the reskeletonization?

That makes perfect sense... done (in next version, that is).

I confess that for the TLD mod (lots of races) I automatized the process much further, for our internal use.
I wonder if a similar option should be allowed for the general case
(also, in TLD, speaking about different skeletons for different races, game-engine mechanisms are hijacked, to achieve the intended purposes, in really fantasious ways... but that's a different story)

Is there a way for OpenBRF to mimick the (frankly annoying) way that Mount and Blade mirrors the face mesh and applies the second half of the texture to it?

I see what you mean.

there is a way to do that in current version of OpenBRF:
1- duplicate the face mesh
2- select the copy you just created, [mirror] it
3- In the copy, also mirror the UV coordinates. Here is how:
    Use [transform texture coords], and...
    ...oops, this part is a bit bugged (in current version)...
    well, in current version, you just need to click on "Flip U", then click OK.
    (When it will be fixed, in next version, this part will be a bit different).
4- Select both original and copy,
    set multi-view mode as "combo" (bottom of window), to see them combined: done
    (or, if you prefer, select the two and do [combine meshes], to merge them into one mesh)

The mesh copy (or the combined mesh) is just for previewing purposes, not to be used by the game.
But, if you save it, it can be used later to preview any retouch of the texture.

Also, remember that with F5 you make OpenBRF reload any texture, after you changed them on disk.
(also, remember that the "helmet" view-mode can be useful to preview the face as standing vertical, instead of laying flat)


PS: I see that the above method (steps 1 to 4) can be a bit time consuming if you want to repeat it several times (e.g. to tune facial shapes). I wonder if a one-click tool should be added. What I fear is to clutter the interface with tools which are useful only in very rare occasions, and potentially confusing at any other time.

 

[Mandible]

No, that's fine, thanks! I haven't used Transform Texture Coords before. That definitely makes it easier. I don't think a new function is needed.

 

[Gambino]

rescaling items

 

[dia151]

rescaling items

isnt that already in?  right click on a mesh -> roto-translate-rescale