Suggestions/requests thread -- post yours here

Users who are viewing this thread

Mandible said:
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?
You know that the game only mirrors the face if there aren't vertices in the other half. Right?
Just move one vertex a bit closer in the x axis and you're done. Prevented.

It makes sense to me.

dia151 said:
Gambino said:
rescaling items

isnt that already in?  right click on a mesh -> roto-translate-rescale
Since the dawn of time. :smile:
 
Hi mtarini, there is one thing I noticed lacking that could come in handy, exporting obj's with preserved hard edges and tangent directions, atm when you export obj's, hard edges and tangent directions get lost. For me this is a big "must be" since often I want to rework something and then basicly I have to work on hard edges over again and every little time consumer is a big nuisance.

 
Hi, a "move to bottom/top" option would be neat after the long hours spent alt + down/up my way in brfs and I also agree with Zimke's suggestion and shall add that exporting vertex colors would help a bit too. Pretty much a bunch of lazy person requests, I know you can copy it all from a brf to another but it would be good if it did it automatically.

[[EDIT:]] in 0.0.82, you can move up/down multiple objects, and move them by leaps with Alt+PgUp, Alt+PgDown, or all the way, with Alt+Home, Alt-End  -- mtarini

Would a "export all meshes with rigging" option be feasible or is it too intensive ?

Anyways it's a great tool, huge thanks for your work.

Edit: Silly me figured there was a copy-paste function after all this time  moving stuff one by one :???:
Nothing to bring on now, it's a great tool.
 
Zimke Zlovoljni said:
Hi mtarini, there is one thing I noticed lacking that could come in handy, exporting obj's with preserved hard edges and tangent directions, atm when you export obj's, hard edges and tangent directions get lost. For me this is a big "must be" since often I want to rework something and then basicly I have to work on hard edges over again and every little time consumer is a big nuisance.
+1

I must have it too....
 
b@rtu$ said:
Zimke Zlovoljni said:
Hi mtarini, there is one thing I noticed lacking that could come in handy, exporting obj's with preserved hard edges and tangent directions, atm when you export obj's, hard edges and tangent directions get lost. For me this is a big "must be" since often I want to rework something and then basicly I have to work on hard edges over again and every little time consumer is a big nuisance.
+1

I must have it too....

Are hard-edges not preserved in exported OBJs? if so, that should be considered a bug.

ps: but, mmm,  it seems they are! If I export a OBJ in OpenBRF, then directly re-import it, it has exactly the same hard edges it originally had.
(for example, try this: take a model and "recompute normals" multiple times, with different amount of hard edges, and export it in different OBJ every time; now re-import each model, and you'll see each has the correct amount of hard edges).

I think the problem might be with the other application you are using to retouch the models (blender, maya, wings3D... whatever). Either it is failing to load the hard edges from the OBJ, or it fails to store them when it exports it back.



As for tangent directions, it is a different issue: OBJ cannot store them, so there's no way to preserve them in a OBJ file.

Digression: on the other hand, I think I remember that the situation with tangent directions is a bit different that what OpenBRF would lead you to think, and what I originally assumed when I wrote support for tangent dirs (I think my source is the usual Cmpxchg8b).
In short, I think the game will recompute them if they are not present in a mesh. The way OpenBRF computes them might be a bit different, but not really much (there's not mush space for interpretation when it comes to defining tangent dirs, given a UV map).

If that's correct, it means that even if, within OpenBRF, absence of tangent directions will cause bumpmapping to go horribly wrong, in the game it won't.

If that's confirmed (anyone?), it would mean:
(1) that you can save yourself the hassle to restore them after reimporting a OBJ, except for previewing purposes inside (current versions of) OpenBRF'
(2) that future versions of openBRF (if there will be any) should, probably, silently compute and use tangent dir every time they are needed, for previewing purposes (recall openBRF preview has the only objective to be as similar as possible as the game);
(3) that I don't really understand why TW has chosen to include tangent directions in the BRF format in the first place -- if it is only to save the time to recompute them: then my bet is that loading them is more time consuming than computing them anyway.
 
When I export dxt5 files photoshop always includes alpha channel even if I choose explicit alpha. Is it possible to ignore alpha channels in the editor? The texture is black thus the model cannot be seen with normal map, only if I uncheck the bump map box  and see it without normal map. But checking it on and off constantly is boring.
I tried to use converters but they save output dds like I would save as dxt1. And it is ugly in the case of normal maps.
 
I think you want to use dxt1, not dxt5, for your ("blue-based") normal maps.
So that, at the same time: it will optimal for that texture, **and** it will make openBRF understand which kind of normal map it is ("blue-based", not "green-based"). It is that misunderstanding which is causing bumpmap to go black.
 
Hey Mtarini!

I'd like to request a small change to the UI of Openbrf, if possible. Currently, if I want to look up all meshes using a certain material or all materials using a certain textures, this shows up:

0ca1821b98458c085c5cb0c03e24b36a.png

This works great, but it's only limited to a certain amount of options. The amount of references shown in the image is as many as it will ever show, even if there's more references in the module. I'd like to ask if you could change the "Used By:" option to a button that opens a window like this:

e865ef9da4c03094fe6a9d0a934b5f91.png


This is a quick mock-up I made in Photoshop, but you get the gist.
Would such a thing be doable? This would be a great way to see all references while not having to hover over the options with the mouse constantly. The mesh/material names would be clickable to navigate to them, of course.

Thanks, and keep up the great work!
 
mtarini said:
I'm not sure I understood. If I rose the limit of shown meshes considerably, would that help?

I mean that the current UI only shows the first 50 uses of a texture or material, while not showing the rest. I think changing the UI to a window like the one I showed would be able to show more of a texture's or material's uses, while also making the navigation of these uses easier.
 
2 things.

1) Editing suffixes would be particularly useful with 'mount on one bone', because it adds _on_head after every name, including LODs (about 40 selected), and I have to manually rename them one by one...

2) I wish I could see how many meshes are currently selected (at the bottom, like itunes)
 
1) I see.  That is a suggestion, and ALSO a reported bug.
  Name composition should be smarter than that.
  (But editing suffixes will be useful even then, as a general tool)

It there are other cases of names being composed by openBRF in a silly way, let me know.

2) I see, makes sense, I'll find a way. (the bottom bar is crowded... I was thinking next to "Data", in the middle)
 
-IMO, suffixes should be editable with or without ".lod1", because when you have different parts in a mesh, ".0", ".1", ".2"... is placed AFTER lods. For example, the other day, I was combining meshes on which LODs had been done already. So I was adding ".1" to several meshes.
But When you want to change the general name of the mesh, you want to ignore LODs. (I don't know if there are situations where you want to change the LOD part of the name in bulk).

-A detail: first choice when saving a new BRF should be warband format, not old mnb format (induced me in error before)

-Konrad has done feminized frames for all his ~60 armors by hand, based on the difference between male and female models. But then I discovered you could make Openbrf LEARN from existing feminized frame to reproduce it. So I took all Konrad's armors and used that as a basis for auto-feminization. It gives us a much more realistic result than the default one.
So I asked Konrad if he's OK to share his work with you if you want to make it the default auto-feminization, and he has no problem with that.
Sending you the file with 58 armors done by hand in PM. Just in case you want to. It works particularly well with plate armors,
 
Double post because I just got an idea (and use for it)

05ZkDLu.png


I just realized how useful it would be to sort all meshes to see which ones are too resource intensive. And another option to put all lods in order of lods, to put them all at the end.

_________


And a minor annoyance of mine: when I press play on an animation, but I have a feminized frame, it automatically goes to the last frame (feminine) and plays the animation.
 
Could you in a future version change the default shader for materials from simple_shader to standart_shader_nobump_nospec? The vast majority of new materials being added are made for new items, which use that shader if it doesn't have a bump or specular map.
 
I hope you will do an install program for this, my open with list is broke and i cant select openbrf to open .brf files. That's happening ever year. :meh:

If anyone gets that annoying problem, here is a fix;

Open Regedit and find this address:

Make sure the key value in the following location contains the correct path.
Code:
HKEY_CLASSES_ROOT\Applications\openBrf.exe\shell\open\command

Mine was corrupted so I fixed the address of exe then worked fine.
 
Back
Top Bottom