Suggestions/requests thread -- post yours here

[xenoargh]

Silly idea maybe, but was thinking the other day that 99% of scabbard animations are exactly the same process:

1.  Frame 0,0:  base mesh.
2.  Frame 1,0:  base mesh (must fix tangent dirs).
3.  Frame 2,10:  shrink to 1%, move forward 10 cm or thereabouts.
4.  Frame 3,20:  base mesh (must fix tangent dirs).

It'd be nice if that was something automated, I suspect those numbers would cover the vast majority of use cases, saving time... and it's one of those things that's probably a stumper for newbies.

 

[Computica]

Silly idea maybe, but was thinking the other day that 99% of scabbard animations are exactly the same process:

1.  Frame 0,0:  base mesh.
2.  Frame 1,0:  base mesh (must fix tangent dirs).
3.  Frame 2,10:  shrink to 1%, move forward 10 cm or thereabouts.
4.  Frame 3,20:  base mesh (must fix tangent dirs).

It'd be nice if that was something automated, I suspect those numbers would cover the vast majority of use cases, saving time... and it's one of those things that's probably a stumper for newbies.

Nah, that depends on the models used. Some people use a whole sword w/scabbard. I used just the hilt w/scabbard. It seems to me that OpenBRF doesn't move meshes individually unless separated.

 

[Vincenzo]

You don't need frame 3.
Also I never do the 1% shrink and moving it forwards and they fit perfectly for me?

Only annoyance is applying the right frame numbers. but not the worst thing.

 

[xenoargh]

Are you saying that on frame 2, the engine quits drawing them?  So we don't need to bother with the vertex animation at all?

That would be nice, if true

 

[Vincenzo]

No, You need frame [0.0], [1.0] , [2,10]  but not frame [3,20]

[3,20] seems to be included in old native swords but I cannot find it in new swords and all mine work fine with just frame 0-2.

 

[mtarini]

No, You need frame [0.0], [1.0] , [2,10]  but not frame [3,20]

Also, as far as I could see, the 1st frame (frame [0,*]) of a vertex animation is never, ever used by the game.
(in animated map icons, hands, scabbards, quivers, armors, face-morphs... anything that uses a vertex animation)

I think it that frame is there only for "historical" reason and the game BRF-loader doesn't even "see" it.

Fro this reason I've always been even tempted to hide it in openBRF, and make only frames starting from the N.1 visible, but again, the data about frame 0, although apparently unused by the game, is there so I didn't want to hide it.

(naturally the fact that it is unused doesn't mean you can remove it: if you do, frame 1 becomes frame 0, thus becoming unused)

Only annoyance is applying the right frame numbers. but not the worst thing.

To help the annoyance, remember that "timings" (e.g. the 0,0,10 numbers of frames [0,"0"], [1,"0"], [2,"10"]) can be pasted from another existing animation into your new animation, even in groups (see under "edit" menu).

 

[Vincenzo]

Another feature request:

When you generate LOD's with the Openbrf tool it will create meshes with the face count as seen in the % value.
However it will create meshes with still loads of vertices that do not have any face... (for instance a mesh generated a LOD of 50 faces and 600 vertices just now.....)
I know in blender you have a tool to remove all vertices that are not attached to any face and this works, but just building this into the LOD tool would be great.

You can do it manually in openbrf by using the split tool and then selecting the actual faces and combining them leaving the random vertices without faces.

Also I see lots of "pos" objects after spliting not tied to any face or verticle... puzzled about those.

 

[xenoargh]

It's also leaving a lot of geometry with orphaned surfaces, at least with weapons; triangles just floating by themselves, instead of being connected to something. 

I think it needs a rule where if the result of the reduction is less than a tri-gon, then it needs to build a tri-gon that meets the boundaries of the object it's LOD'ing.  Either a trigon or a cube (cube may be easier from the standpoint of uvs) would also give us something easier to do final re-adjustments with.

 

[Vincenzo]

Actually thinking about this, how about besides adding this inside the LOD tool a new mesh function: "Clean mesh"

That removes unused vertices etc etc. this way I wont have to generate new LOD's for all kinds of stuff and in theory it could clean other things from your meshes.

 

[MadocComadrin]

Nah, that depends on the models used. Some people use a whole sword w/scabbard. I used just the hilt w/scabbard. It seems to me that OpenBRF doesn't move meshes individually unless separated.

Aye, my scabbard meshes are a single mesh comprised of the hilt from the sword mesh and the scabbard or two meshes-the hilt and the scabbard. What would be nice would would be some way to mark the verts that need to "disappear", then automate the process.

 

[Vincenzo]

Another suggestion/request:
- Having the ability to resize objects with decimals in the percent field.

 

[Vincenzo]

Sorry to double post,

Another request:
- Remove normals, or a recompute normals function that only computes normals for one direction of the mesh.

Reason for this is flora, flora completely ignores any normals, and when you recompute normals for double faced meshes it will compute a lot of un-needed verticles.

 

[mtarini]

Double posts like these are very useful!

Both suggestions are totally sensible, and very quick to add.
I'm supposedly very busy with RL but I'm tempted to do them and release a micro-release.

 

[Vincenzo]

Hah, We are all busy sometimes

Don't forget to look at the suggestion of page 6; That clean mesh thing.

I checked the openbrf code and already found you have a function for it;
RemoveUnreferenced();

Just making a call to that will do the magic.

Only problem with it that I found when hacking it in myself was that your rigging can get screwed up. but I fixed it by copy pasting rigging to the cleaned mesh.

 

[mtarini]

True, that and the bounding box.

Too many small feature request making sense...

Will do an update.

Edit: done!
Bounding box, mesh cleaning, decimals in resize, and "clean mesh".
(plus the custom user-editable preview shaders, as from another thread).

Actually, the "clean mesh" tool proposed above I've put together with the already present "unify vertices" tool, which I rename "remove redundant vert/pos". But yes, it is also done automatically on LOD computation.

Thanks Vincenzo for pointing it the potential "rigging" problem with that, fixed now!


Edit: it is taking forever to upload, but the new version should be there real soon.

Edit: oh, and the "discard" -> "normals" tool added.
But don't be fooled by that name: normals will still be there and they will be loaded by the game
(no disk space savings, for example)... it's only that vertices are merged disregarding normal differences,
saving a few vertices , as Vincenzo suggested.

 

[Vincenzo]

Thanks a lot!

Don't forget to upload the source mate. 

  you're right: done -- mtarini

 

[mtarini]

I forgot to mention that the invert selection tool is now there as well (under tools, or with ctrl+I).

 

[orangeknite1]

I think a good tool would be a tool to convert PSD/PNG to DDS in OpenBRF. So pretty much be able to Import PNG/PSD into OpenBRF and it will convert it (if possible of course).

 

[Vincenzo]

... why? there are a dozen of tools available for that...

 

[Specialist]

Impossible in an app like this.... (well, not completely, but there will be about 400 exceptions and errors if you try to convert a non power of 2 texture. Hence, if you save a 119x512 texture from PSD to DDS DXT1, it will crash)

... why? there are a dozen of tools available for that...

And that too.