Search results for query: *

Hello Swyter how are you doing? Long time no see! It's so great to see (e.g. on trello) that TLD dev continues to be alive!
I am popping up because I have a super minor suggestion. I'm not sure this is the place for it, but this seems to be the most recently used of the many many many places that are used or have been used for discussing TLD. Anyway, here goes.

A few of the starting-game menus are titled "Select your race". It occurred to me that the wording might be improved. BTW I not suggesting it because of the debate about the political correctness of the term "race" in fantasy settings (which recently resurfaced in different parts of the game-verse).

In menus for bad guys,"breed" may be more savory than "race" (yes, even listing "man" as a breed) . In the various menus for good guys, one of "kin", "folk", "heritage", or "people" could be adopted, depending on the specific menu.

mtarini out!

I've no idea how assets work in BannerLord. Is that info available?
If only minor modifications are needed, then for sure.
Otherwise, I'll think about it.

Actually, it is easy to recenter the mesh in OpenBRF.
Just use the "roto-translate-rescale" tool.

To set the correct translation, just use the icons on the right.
E.g. if you want to center the pivot point horizontally,
use the "center" icon on X and Z (they look like this: [|] ).
If you want the mesh to just touch the ground,
then use the "minimum" icon on Y (it looks like this:  |[ ] ).
You can retouch these choices by pushing the object a bit left/right (X), up/down (Y), near/far (Z), using the arrow or entering values.

Be aware that the center/minimum/maximum are computed with respect to all selected objects. So for example if you have a combined object, select all its part before you "roto-translate-rescale" them.

Too see where the pivot point is, make sure floor is activated (in mod panel) and look for that little gray dot in the center of the grid.

You can but you have to suffer a bit and also prepare the textures themselves yourself.

The tool you are looking is "Transform texture coordinates"
For example, to assemble 4 sheets into one sheet like this:

A B
C D

then all the models should be scaled by 50% (both U and V).
meshes originally using A should not be translated.
meshes originally using B should be translated by 0.5 in U (horizontal)
meshes originally using C should be translated by 0.5 in V (vertical).
meshes originally using D should be translated by 0.5 both in U and in V.

Now, all these meshes must be using the material linked to the new assembled texture.

Yes, apologies for the confusion. I carelessly started using the technically wrong term ("rigging") when OpenBRF was super-tiny, and then felt stuck with it but got increasingly annoyed by it, until at the end I decided to set it right ("skinning").

Yes, debugging is usually hard, even when you have the source code and tons of tools. On a closed box exe, it is hopeless

Leonion said:

So this setting kinda "hates" only particular meshes - like, I dunno, maybe it doesn't like when a mesh has an even number of vertices and an odd number of polygons, or has a vertex that is connected to 11 other vertices

Click to expand...

Who knows, that might well be the case, but let me offer a different hypothesis:
guessing from my interpretation above, this flag only makes sense for static objects, i.e. scene-props and little else. And it is only really profitable for objects which are repeated plenty in a scene, and are individually small (polygon-count wise), like plants and other background elements. So it is may well be that this is the expected case: scene props, and something unexpected goes wrong when it is used on other things, like horses and armors (which do change position with respect to each other all the times).
If that is true, then the vanilla brf should be found using the flag accordingly.

Keep in mind that when "something goes wrong" you are usually not guaranteed a crash: the game just uses a dirty part of the memory and anything can happen, from immediate crashes to nothing at all, or even long delayed crashes. Debugging is hard

Interesting find.

I was notified of this thread so I came here. In case it helps, let me add what that flag might be doing.

It is just a guess really, but, if the flag does what its name suggests (which might be or not be the case, plus, the name could be wrong or outdated) then a likely interpretation is as follows:

Flag set = "Dear game, please activate this optimization for all meshes using this material:
when they are seen from afar, and you would normally use lod (say) 3, then do use it, but, when there's many of them, don't draw them one by one: instead, combine them automatically in a single unified bigger mesh and draw that mesh once instead, in place of all the tiny ones."

(the results is that the the same set of triangles are drawn, but as a single "draw call", not many. Reducing the number of "draw calls" can save a lot of time and so it is a good thing. But, it also imposes limitations: you now have to draw all the objects or none; for example you cannot skip the ones which happens to be offscreen anymore; plus, the objects cannot move any longer with respect to each other.)

Here is a scenario where this kind of optimization is almost a necessity: say you have a mesh for some vegetation. At LOD0, it is fairly detailed, but at LOD4 it is maybe just a few polygons, maybe as few as one or two. Does this mean that you can afford to have like hundreds of them, or even thousands, far away in the background? Well, drawing a few thousands triangles is certainly not a problem, but making thousands calls (each wasted to draw a few triangles) is. Most of the GPU time is lost in overheads. To fix this, that flag (from what I can be inferred by its name) would create a single mesh featuring a few thousands one-or-two-polygon plants, for the entire vegetation of the current scene.

The unification process is done by the game and many things might go wrong with it, hence the crashes  (maybe). Maybe that flag is not supposed to be used in conjunction with something else, eg. maybe it shouldn't be used with skinned mesh, or who knows. It certainly cannot be used with meshes that are supposed to be moved independently from each other inside the scene.

I'm sorry, I have no idea what might be going on in this case.
I can only offer standard attempt like "try updating your video card drivers".

Older versions of OpenBRF work?

<...checks the code...>

Oh, I see.

I'll make a smarter version, but for now it is enough that you remove (or rename) the file "customPreviewShaders.xml", a file which sits next to openBrf.exe.
Or substitute it with this fixed one: [customPreviewShaders.xml] (right click, save as).

Thank you for reporting!

((  longer explanation: that file is the place for any custom shaders which some users might want to write so to preview their meshes with it. OpenBRF comes with an example of one such shader, given just as a guide to help people write their own. But, this example shader currently happen to have a very minor error which is ignored by many OpenGL drivers, but not all of them. Even if the shader is not used by any material and serves no immediate purpose, openBRF still reads it, and reports the error. The next update will (1) come with the fixed example shader (2) make openBRF not lose time to read and compile it anyway, because it is just one example  )).

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)

thanks 72amadia, but, ...
how are you trying to open a module (from steam workshop), and what does it do instead?

That's exactly right. Let me add a detail or two.
It all depends on what you want to achieve...



[WAY 1: completely rigid helmet]

If you are happy with the entire helm moving rigidly with the head, as opposed to having some part deforming according to the position of, say, the shoulders, then, as snouz says, you want your helmet to be (a) "non-skinned" and (b) around the origin.

Instead, your helmet is around the head region and maybe it is skinned to (to the head bone). So, here's what to do.

Is your helmet already skinned? (look at the middle panel, it will tell you).
If it is, skip to step 4.
If not, first you need to temporary add skinning (gluing all the model to the head bone):

1) Select the hemlet
2) [Selected] => [mount on one bone...]
    This open a dialog...
3) Select human skeleton, then head bone, and check "Piece currently centered: in the correct final position"
    And hit ok.

Now, place the hemlet on the origin while removing the skinning:

4) Select the helmet alone.
5) In the middle panel, pick any animation + human-skeleton 
  (this is just to let openBRF know which skeleton to assume, that is, "human")
6)  [Selected] => [Discard] => [Rigging (unmount from bone)]

Now, follow snouz advice about what to put in the py file: only one mesh.



[WAY 2: NON completely rigid helmet]

If you want your helm to deform, e.g. with the shoulder, then you need to have it skinned and positioned around the head.
Yours is already correctly positioned.
You just need to add the skinning (not all to the head bone: some part to the head, some part to the shoulders or spine, etc)

A possible way to to this:
1) select a skinned helm AND armour, or possibly multiple such things.
    (multiple selection)
2) copy (ctrl+C)
3) select your helm (already in the final position, i.e. where the head is)
4) [edit] --> [paste rigging]
5) test an animation and see how it looks!

Now, you need to edit the py file as snouz says: two meshes: one for the helmet, one for the inventory item.

that's actually a very good idea

thank you for the info, then I'll include the two dlls m in the official release.

Oh boy I hate DLLs.

Mike56, does it work for you if you unzip these two DLLs to whichever folder OpenBRF 0.0.82 is in?
http://vcg.isti.cnr.it/~tarini/tmp/missing_dlls_maybe.zip

I'm not sure I understood. If I rose the limit of shown meshes considerably, would that help?

Glad that the problem is fixed, but for future reference, another way to do that is :

1) SELECT both weapons, in this order:
    first the existing, working weapon and then your new one
    (keep ctrl pressed for multiple selections)

2) make sure the "View mode" is set to "Combo", so that you see the two things combined
    (at the bottom of OpenBrf windows),

3) now "Selected"--> "roto-translate-rescale...".
    This open a dialog.
   
4) check "apply to Last selected object only" (at the bottom of the dialog window)
    so that your rotation-translation will be applied only to the new weapon
    and the other one is kept where it is, for reference.

5) fiddle with the angles etc until the HANDLES of the two weapon match and the two weapons match in orientation

6) accept what you have done with OK

So, had a look... there are a few issues going on all at once here.

One, as you correctly report, that version of 3DS max for some reason seems to be changing the internal order of bones. However, the names are maintained, so I can use them to make openBRF restore the original order.  But, it would be a lot easier if 3DS max learnt not to change the order in the first place, if possible. It seems it is sorting them in alphabetical order. If your first screenshot I read "Bones (sorted alphabetically)": maybe there's a way no make it not do that?

Two, as it was noted, there's these comment in the SMD file produced by 3DSmax what that otta be ignored, but OpenBRF doesn't know about that. This, you fixed manually removing the offending line, but I want to fix for good making OpenBRF aware of that pitfall. So maybe just send me the file just as produced by 3DS Max so I can test it.

Three, and here there's little I can do form the OpenBRF, that SMD file you sent me contains no animation at all, but only a single frame (a single pose). Is that what you wanted, a single pose?
(an animation is usually a sequence of poses)

Now, if you wanted to export a sequence instead, then you need to convince 3DS Max to actually export that and not a single pose. But also read the note below.
If instead you actually wanted to export a single pose, then you need to read the note below.

So, here's the problem: when importing an animation, OpenBRF uses the first pose of an sequence as a reference for the other poses.
Unfortunately, there is no other way to know the global positioning of the animation without this.
The 1st pose of the sequence is assumed to be the T pose; it is used for this and then discarded.

You SMD file consists of only that one pose. So when OpenBRF imports it, it ends up with an animation with 0 frames (as you can see in the frame box). That's why you don't anything.
Even if you want to export a single pose, you need to export two frames: T pose, your pose.
If you want to export an actual animation, you'll need T pose first, followed by the sequence of poses.
Not sure how to convince 3DS max to do so.

(when you'll fix this, there will still be point One above making a mess out of it, I think)

I wrote the SMD importer in OpenBRF by hand.

It worked with any SMD files I tested so far, but it may well be that you are using a SMD which, while perfectly compliant, uses a feature or another which confuses OpenBRF.

If you send me an example of the SMD you are trying to import, I'll see what the issue might be.

Don't fix it manually, just gimme the file straight as 3ds max 2017 produces it: when I'll have the time, I'll see to it that OpenBRF learns to cope with it.


ps: @moderators: maybe move this thread into the OpenBRF sub-forum?
I wouldn't have seen this if good old Khamukkamu didn't warn me.

Does it open vanilla files for you?
Which other file gives you the problem?

Are you using, by any chance, custom preview glsl shaders for OpenBRF in that mod?

Whichever the reason of the problem, I hope you can bypass the problem by unselecting "using preview shaders" under settings
(but this will disable normal maps and other similar things in the OpenBRF previews).