Suggestions/requests thread -- post yours here

[Barf]

Awesome!, I just tried it out and it works perfectly.
I had assumed the re-normalization feature was only for removing or adding hard-edges, but it did in seconds what would have taken
me twenty or thirty minutes on a mesh as heavy as the skeleton.

 

[xenoargh]

Kudos, Barf, that is 100% awesome!

 

[Lumos]

About the dumping feature: the informative error messages helped me trace my erorrs, everything is working as normal. OpenBRF really is invaluable.

 

[mr.master]

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.

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

Would be wonderful if you could

 

[The Shadow]

Since With Fire and Sword uses green bump maps, is there any possibility of detecting if it's in the With Fire and Sword/CommonRes and changing the way it renders them?  Or at least allowing an auto-disable of them if it's from the With Fire and Sword/CommonRes? 

 

[mtarini]

Good suggestions are stacking up and still I need to postpone any work on OpenBRF due to RL... it will be in a week or two.

Since With Fire and Sword uses green bump maps, is there any possibility of detecting if it's in the With Fire and Sword/CommonRes and changing the way it renders them?  Or at least allowing an auto-disable of them if it's from the With Fire and Sword/CommonRes? 

The ideal would be to find a simple way to let OpenBRF tell "BLUE" and "GREEN" bump-maps apart, that was robust for them all: for M&B 1.01, WB and wFaS. For example, a flag in the shader, maybe? Or shader names? (I don't have wFaS here, so I cannot tell)

More info: the game itself displays blue/green bumpmaps correctly simply because different materials uses different shaders. Some shader assumes the bump is "GREEN", some that it is "BLUE". For example, it seems to me that...

...[mtarini has a quick look]...

...in WB, shader bumpmap_interior_new assumes BLUE bump, but shader  bumpmap_interior assumes GREEN.
Now if there was a simple set of rules so that openBRF looks at the shader name, and acts accordingly...

Plus, if this simple set of rules worked in WB, M&N, and wFaS alike, that would be real fine.
If anybody  feels like it, it would be great if you can find one such rule, by browsing native datasets.
Feel free to suggest!


((For example, currently, if the word "iron" is to be found inside the shader name of the current material, then OpenBRF assumes that "alpha" of rgba texture stands for shininess (unless there is a shininess map defined, in which case that is assumed to encode the shininess). It would be cool to find a simple rule of this kind to tell blue and green bumpmaps.))

 

[xenoargh]

WFaS is using the same shaders, so far as I can tell.

If you're going to add that rule, then I'd like a rule for the following:

specular_shader_noskin_bump_high:  texture 3 is providing the specular value.

 

[The Shadow]

Good suggestions are stacking up and still I need to postpone any work on OpenBRF due to RL... it will be in a week or two.

Since With Fire and Sword uses green bump maps, is there any possibility of detecting if it's in the With Fire and Sword/CommonRes and changing the way it renders them?  Or at least allowing an auto-disable of them if it's from the With Fire and Sword/CommonRes? 

The ideal would be to find a simple way to let OpenBRF tell "BLUE" and "GREEN" bump-maps apart, that was robust for them all: for M&B 1.01, WB and wFaS. For example, a flag in the shader, maybe? Or shader names? (I don't have wFaS here, so I cannot tell)

More info: the game itself displays blue/green bumpmaps correctly simply because different materials uses different shaders. Some shader assumes the bump is "GREEN", some that it is "BLUE". For example, it seems to me that...

...[mtarini has a quick look]...

...in WB, shader bumpmap_interior_new assumes BLUE bump, but shader  bumpmap_interior assumes GREEN.
Now if there was a simple set of rules so that openBRF looks at the shader name, and acts accordingly...

Plus, if this simple set of rules worked in WB, M&N, and wFaS alike, that would be real fine.
If anybody  feels like it, it would be great if you can find one such rule, by browsing native datasets.
Feel free to suggest!


((For example, currently, if the word "iron" is to be found inside the shader name of the current material, then OpenBRF assumes that "alpha" of rgba texture stands for shininess (unless there is a shininess map defined, in which case that is assumed to encode the shininess). It would be cool to find a simple rule of this kind to tell blue and green bumpmaps.))

I'm not graphics savvy, but if I get time, I'll take a look and see if I can figure this out.  I need to learn more about this stuff anyways. 

 

[mtarini]

I started a new thread about how to help OpenBRF guess which shader and effects it should be using to better imitate what the game will do (including type of bumpmap, transparency, alpha shininess etc)...

 

[Swyter]

A good idea is to allow Level of Details to be replaceable, instead of duplicate when you're LoDing massively.
As you're currently doing with armor feminization. 

Instead of that, it could be cool some command to delete duplicate meshes (by fewer/more polys). Or a dialog with options to delete directly all the unused meshes/textures/texture references/materials. Sort of CCleaner for the module. If you know what I mean.

That's all what I can think, the program has already surpassed the "complete" adjective, and now we're going for the "imprescindible" one
I'm learning a lot, Marco.

 

[xenoargh]

I think this has been noted before, but could OpenBRF export SMDs using the horse skeleton... with the horse skeleton?  It currently exports with the human skeleton, which means that you have to rig from start, which takes a lot more time than doing minor fixes.  Just thought I'd ask, since I just got done with 3 hours of rig on Barf's little 'pony'

 

[mtarini]

It should export SMDs using whatever skeleton is currently used to preview the rigged mesh (pick it in in the "View" panel, in the middle of the screen, after you picked an animation). If it does not, it is a bug.

(edit PS: OpenBRF can't pick the skeleton automatically for you, or at least it can't do so reliably, because that there is no link between a rigged mesh and a skeleton. It could try to guess by looking at the number of bones, but then it would often pick the wrong one. Hence, you the user have to tell it, in the way above).

 

[xenoargh]

If you select a horse, then select anim_horse, it selects the horse skeleton for animation preview (although, I should note, it doesn't work completely correctly- watch the animations play and you'll see what I mean), but when exported, it uses the human skeleton.  Am I just doing it wrong?  That seems like the way it should work, but maybe that's just me.  I would like to know if it's just User Error; maybe I'll finally make the Rhodok Fighting Bears

 

[Swyter]

Just found that the texture zoom mouse wheel binding is inverted.

Rolling it up to enlarge and down to decrease.
That's how it should be.

[plain]
  [+]
   _
  / \
_| | |_
 | | |
  \_/

  [-]

--old school graphix[/plain]

 

[mtarini]

If you select a horse, then select anim_horse, it selects the horse skeleton for animation preview
[... ] but when exported, it uses the human skeleton. 

Then it is a bug. I'll see to fix it.

(Right now I cannot afford the time to fix and release a new version, but this bugfix adds to a tons of others.
Next week probebly)

(although, I should note, it doesn't work completely correctly- watch the animations play and you'll see what I mean),

On this note: nono, everything is correct there. The horse animations in M&B does contain intervals of pure rubbish.
Only, these intervals are not used by the game (they are not listed in actions.txt). To make a test, you can see
that if you split the horse animation "with action.txt": it will keep all the intervals that are actually used, and the rubbish segments will be gone.

(my understanding of why rubbish frames are there is that, at TW, at some point they interpolated between any consecutive frame, including between the last frame of an used animation interval all the way to the first frame of the next used interval.)

Just found that the texture zoom mouse wheel binding is inverted.

Well, that's a matter of tastes. To me, rolling the wheel toward oneself means dragging the object closer, so it becomes larger.

One could prefer the same movement to mean "moving you-the-observer away from the objects" (it becomes smaller), but then why, when you slide the mouse leftward, the object turns leftward? (and not: you-the-observer move to your left, i.e. the objects turns right?)

 

[xenoargh]

The horse animations in M&B does contain intervals of pure rubbish.

Ah.  Hmm.  If it wouldn't bother you terribly or take forever, could it show the rubbish-free by default, then?  It makes it much, much harder to judge when vertex weighting in the rig is not quite right when viewing it running and it hits the junk frames.

 

[mtarini]

No, it is actually very easy to do, good idea.

But you don't have to wait for me, you can do that yourself:
[1] "settings"->"edit reference data". (background turns orange)
[2] Anim tab, pick the horse animation.
[3] Right click, "split using action.txt". It will ask you which action.txt to use.
      Attention! You need to pick a M&B (e.g. 1.011) version. not WB, or OpenBRF will crash. I'll see to fix this too later.
[4] You now have some dozen small horse animations (the gallop, the jump, the walk, etc).
[5] Group select them all. Right click, "merge animations".
[6] It produced one more animation with all the good intervals in it. Maybe rename it (F2) to something that makes sense.
[7] Delete the original horse animation, as well as the other spit animations.
    Maybe keep (and rename) the few ones you are most interested in, like the gallop.
[8] Save (ctrl+S).
[9] "settings"->"stop editing reference data". (background turns gray again)

Et voila, you can now test your horse rigged models with the rubbish free animations, as well as "continuos gallop" ones.

Anyway, in the next version I'll include the reference data with the rubbish free animation. But following the above you can isolate and loop the bits that are more useful for you (e.g. the jump or the trot).


PS: I tried testing the SMD export. It seems to work fine here. Sure it is broken?
Pick the rigged mesh, select the ani, select the skeleton if needed, export.

 

[xenoargh]

<tests>

Oh snap, you are right!  I must not have selected the animation first

Oh well, it probably wouldn't have saved all that much time on that anyhow, it needed a lot of careful tweaking.

 

[Swyter]

Just found that the texture zoom mouse wheel binding is inverted.

Well, that's a matter of tastes. To me, rolling the wheel toward oneself means dragging the object closer, so it becomes larger.

One could prefer the same movement to mean "moving you-the-observer away from the objects" (it becomes smaller), but then why, when you slide the mouse leftward, the object turns leftward? (and not: you-the-observer move to your left, i.e. the objects turns right?)

Sure, you have a point here, but I discovered the zooming almost by error (scrolling out of the material list).
I'm accustomed to the standard "de facto" and it looks more straight-forward. Of course, is your software.

So I don't have any rights over it. Was only a simple suggestion.
Thanks again for your reply.

 

[Sayd Ûthman]

Would be nice (if possible) to have normalmap and specular shown in the preview screen also , an undo command could be useful