creating lods didnt make the brf on modified either (no asterix on the title bar) so if we close the program after we created lods, there won't be a notification about unsaved modification.Lord_Cheap said:Don't know if anyone else has mentioned this, but the Repeat Last Command doesn't work for Compute Lods. No biggie, but I thought you might have wanted to know
Download link and main info! [latest ver 0.0.82e -- 19 Jun 2016]
- Thread starter mtarini
- Start date
Users who are viewing this thread
Fat Hobbit!
Regular
Hey
In one of my Brf's, It can't find all the Textures for all of my trees, just says Texture: <not found> I have the textures, its just not finding them, how can I fix this.. ? Its only got Colisions and Meshes in the Brf.
In one of my Brf's, It can't find all the Textures for all of my trees, just says Texture: <not found> I have the textures, its just not finding them, how can I fix this.. ? Its only got Colisions and Meshes in the Brf.
add "load_mod_resource = rowel" to module.ininewaxekub said:
Import -> New textureFat Hobbit! said:
Also, textures should be in mod Textures folder
Fat Hobbit!
Regular
Fat Hobbit! said:
Yes, they're in the textures folder, and importing a Texture, like you said, doesn't work - it brings the texture in, and shows it,
but it doesn't apply it to the model.
What I'm trying to do is - where it says "Texture:" and it has a box and it says <not found>, I just wanna like type in the name of the texture in there?..
You need to create Material using this texture, and apply this material to the model. And read some tutorials / look how things in vanilla are done.Fat Hobbit! said:
Fat Hobbit!
Regular
GetAssista said:
Ok wait - This brf, when its in its original Mod, finds all the textures itself, it doesn't have any 'Textures' or 'Materials' tab, when I open it in OpenBrf, only 'Meshes' and 'Colisions' Know what I mean? Therefore, me, importing a Material or Texture does nothing...
Because original mod defines these textures and materials somewhere else, in other brf.Fat Hobbit! said:
bull****. importing textures and creating new material with this texture in diffuse field will create Textures and Materials tabs. Just do it, then apply material to meshFat Hobbit! said:
Fat Hobbit!
Regular
I'm so lost, I have to import textures...?
Look, it's like this:
You must have a mesh, material and a texture. The mesh takes a material, which takes a texture.
Code:
Mesh <- Material <- TextureFat Hobbit!
Regular
Yeah, I got that much The mesh isn't textured, even though I have materials, and Textures, and the Textures are in the correct folder. ...
The mesh isn't textured, even though I have materials, and Textures, and the Textures are in the correct folder. ...
Fat Hobbit! said:Yeah, I got that much
Then do Ctrl + C in the desired material entry and paste it (Ctrl + V) into the material box of your currently selected model, you'll see that a texture will appear, that unmodifiable "
Code:
Texture:The procedure is as easy as Lumos says. Don't confuse the hierarchy. You can generate materials directly for every texture imported in OpenBRF activating the proper checkbox in the texture importing dialog. And then using it in every model you want.
Don't forget that materials are mesh independent. And you can reuse the same for various ones.
Also, try to use the same names for the texture filenames and its materials. So you won't be confused.
That's it. Only my two cents
Fat Hobbit!
Regular
Hey thanks very much - I think I got it now
Just needed a bit of an explanation, was a bit confused..
Cheers
Just needed a bit of an explanation, was a bit confused..
Cheers
King Harkinian
Squire
Hi,
I tried looking for an answer, but as I haven't managed to find a solution to my problem, here it is: I've just downloaded the latest version of OpenBRF, I've unzipped into Program Files (I'm running Windows Vista, btw), I try to run OpenBrf.exe, but it doesn't do anything, and, after a while, just tells me that "Openbrf.exe stopped working".
I also tried running it in compatibility mode (Windows XP sp2) but to no avail.
Could anyone please help me out?
I tried looking for an answer, but as I haven't managed to find a solution to my problem, here it is: I've just downloaded the latest version of OpenBRF, I've unzipped into Program Files (I'm running Windows Vista, btw), I try to run OpenBrf.exe, but it doesn't do anything, and, after a while, just tells me that "Openbrf.exe stopped working".
I also tried running it in compatibility mode (Windows XP sp2) but to no avail.
Could anyone please help me out?
King Harkinian said:
Please read quickly some previous posts before writing.
Everything has been explained. In the latest 3 pages. I think.
Summarizing. The 0.0.57 version of OpenBRF doesn't work properly if you don't have a nvidia graphic card. So use the alternative versions.
Try to do it next time.
King Harkinian
Squire
Swyter said:King Harkinian said:
Please read quickly some previous posts before writing.
Everything has been explained. In the latest 3 pages. I think.
Summarizing. The 0.0.57 version of OpenBRF doesn't work properly if you don't have a nvidia graphic card. So use the alternative versions.
Try to do it next time.
Ouch, that's embarrassing -- I used the search function, but I didn't really read the last three pages. Sorry about that, and thanks for the help
Update: Working fine now. Thanks again
New version! From the 1st page:
Point by point details...
Point 1 is supposed to relieve the grief to all these users who experienced catastrophic crashes / hanging / memory voidless.
Hopefully. It's not like I can test it here so let me know!
Basically, it starts in plain OpenGL 1.x mode. That should be harmless. No shaders, standard things only (so, no bumpmapping etc). First time you activate one of them (or you go and select the option under "settings"), OpenBRF ill ask if you want to try the spicy OpenGL 2.0 version. Then it remembers for next times. It should be pretty robust. If it crashes on you, just disable that option again (actually, if it crashes it should not even be able to save that setting). Sooner or later I'll try making a version robust for most computers, but I'm waiting to see if next version of QT helps me in that.
Point 2: specular maps, in WB. Naturally only if you have OpenGL 2.0 enabled.
In M&B, you use the alpha channel of the RGB map for a similar purpose. I've got to admit that bumpmaps looks a lot better with them on.
Point 3: as I said, you need tangent directions to use correct tangent-space bumpmaps maps (the game and OpenBRF alike). Now OpenBRF can compute them for you. Alas, you can save them only in WB file format.
As a test, I computed them a native meshes and I've seen that I must be doing something compatible with what the game expects, because the results I get are very similar to the ones I find in native, as I can see by looking at the at the way bumpmaps get rendered.
(I've an idea hat the small differences between OpenBRF computed and native tangent dirs can be due to, but I like my way a lot better.)
If you are curious, the tangent dirs are computed from the u,v coords.
Point4: small thing, change background, can be useful to preview things better.
(But, "orange" background still means you are editing internal reference, like OpenBRF internal skins or animations).
Point5: a settings to choose how to compute LODs (which lods, how many tris in them).
LOD computations is still what it was, more or less.
Point 6: I thank Vornne for pointing it out
Point by point details...
Point 1 is supposed to relieve the grief to all these users who experienced catastrophic crashes / hanging / memory voidless.
Hopefully. It's not like I can test it here so let me know!
Basically, it starts in plain OpenGL 1.x mode. That should be harmless. No shaders, standard things only (so, no bumpmapping etc). First time you activate one of them (or you go and select the option under "settings"), OpenBRF ill ask if you want to try the spicy OpenGL 2.0 version. Then it remembers for next times. It should be pretty robust. If it crashes on you, just disable that option again (actually, if it crashes it should not even be able to save that setting). Sooner or later I'll try making a version robust for most computers, but I'm waiting to see if next version of QT helps me in that.
Point 2: specular maps, in WB. Naturally only if you have OpenGL 2.0 enabled.
In M&B, you use the alpha channel of the RGB map for a similar purpose. I've got to admit that bumpmaps looks a lot better with them on.
Point 3: as I said, you need tangent directions to use correct tangent-space bumpmaps maps (the game and OpenBRF alike). Now OpenBRF can compute them for you. Alas, you can save them only in WB file format.
As a test, I computed them a native meshes and I've seen that I must be doing something compatible with what the game expects, because the results I get are very similar to the ones I find in native, as I can see by looking at the at the way bumpmaps get rendered.
(I've an idea hat the small differences between OpenBRF computed and native tangent dirs can be due to, but I like my way a lot better.)
If you are curious, the tangent dirs are computed from the u,v coords.
Point4: small thing, change background, can be useful to preview things better.
(But, "orange" background still means you are editing internal reference, like OpenBRF internal skins or animations).
Point5: a settings to choose how to compute LODs (which lods, how many tris in them).
LOD computations is still what it was, more or less.
Point 6: I thank Vornne for pointing it out
The Shadow
Recruit
Can you make an option to use a picture as a background? I'm guessing it's not too hard. (At least in C# anyways.) Anyways, testing it out now, great job with implementing new features, you sir, are amazing.
EDIT:
Capital job, sirrah. It works with ATI!
Anti-aliasing seems extraordinarily lower without 2.0 though. Nothing big, I'll just take preview shots in something else. Or maybe CCC can force higher AA. Also, you say "Older" graphics cards, but I don't think that's an issue, as I'm running a fairly new 5650.
2nd EDIT: I get random "This program has stopped working" on Windows 7 64-Bit. Not a bid deal because I save frequently, but still, there's no error messages or anything.
Also, after each crash it resets my LoD settings. I think it may be because I already have 1 or 2 LoDs for the items, at least, the same item crashed twice and it did.
-Note: It did it on the same item 3 times, but I then tried it on a different item that had OpenBRF generated LoDs, and it simply duplicated them no crashing. I also did testing with LoDs I made on different items, and no problem. So it appears to be specific to this particular helm.
3rd EDIT (w/error message!)
I caught the bugger! Well, one of them anyways.
Upon ignoring the error:
It was avar_cav_helm that was guilty, rendering on OpenGL...1.2? (Whatever the non-2.0 version you're using is.) Obviously, it happened when making LoDs for a model. (Uploaded here.) Upon retrying, it crashed with no further message. (I think I have a jitter enabled, though I was unaware that C++ had this feature.) Also, avar_inf_helm is the one I kept getting unexplained crashes for.
So the final verdict is:
Some random crashes when making LoDs. Not consistent, re-dos seem to work.
Some consistent crashes with the same model. (avar_inf_helm)
Crash with error message. (avar_cav_helm)(Consistent to mesh as well.)
EDIT:
Capital job, sirrah. It works with ATI!
Anti-aliasing seems extraordinarily lower without 2.0 though. Nothing big, I'll just take preview shots in something else. Or maybe CCC can force higher AA. Also, you say "Older" graphics cards, but I don't think that's an issue, as I'm running a fairly new 5650.
2nd EDIT: I get random "This program has stopped working" on Windows 7 64-Bit. Not a bid deal because I save frequently, but still, there's no error messages or anything.
Also, after each crash it resets my LoD settings.
I think it may be because I already have 1 or 2 LoDs for the items, at least, the same item crashed twice and it did. -Note: It did it on the same item 3 times, but I then tried it on a different item that had OpenBRF generated LoDs, and it simply duplicated them no crashing. I also did testing with LoDs I made on different items, and no problem. So it appears to be specific to this particular helm.
3rd EDIT (w/error message!)
I caught the bugger! Well, one of them anyways.
Upon ignoring the error:
It was avar_cav_helm that was guilty, rendering on OpenGL...1.2? (Whatever the non-2.0 version you're using is.) Obviously, it happened when making LoDs for a model. (Uploaded here.) Upon retrying, it crashed with no further message. (I think I have a jitter enabled, though I was unaware that C++ had this feature.) Also, avar_inf_helm is the one I kept getting unexplained crashes for.
So the final verdict is:
Some random crashes when making LoDs. Not consistent, re-dos seem to work.
Some consistent crashes with the same model. (avar_inf_helm)
Crash with error message. (avar_cav_helm)(Consistent to mesh as well.)
me too got a lot of LOD related crashes. this was not happening with the original verion that introduced LOD pyramid. I used to have like 3 meshes that didn't like it and now it's a LOT more.
nice to be able to change the reduction % though (when it works)
keep up good works!
nice to be able to change the reduction % though (when it works
)keep up good works!
Crash on lods making? mmm I guess is has nothing to do ith OpenGL. Probably it depends on some un-handled "inconsistent" configuration, like for example three faces shading one edge... I'll have a closer look. If so, I could make it not crash (give up instead, saying "I cannot compute LODs") but it would be a tough one make it work on that one
I've changed the way lods are done a little... I'll put lod making as it was before, in a "b" new version.
----------------------------
Wow, OpenBRF running on Linux, that's great! I'll try fixing the compilers errors you reported when I have time, if not else for general code hygiene.
----------------------------
So you don't want any of the new larger faces to span across "seams", that is, the lines of UV discontinuities (for example, you cannot have a triangle span over different texture atlas regions).
To separate vertices among UV-seams was just a way to avoid that. Unfortunately, yes, it creates that artifact you mention. I'm well aware of it, it is already a lot better than what I got in my first attempts. The problem could be described as having two initially overlapping borders which should in theory be simplified in sync, but are not, so a gap opens between and, because simplification generally tends to shrink stuff, it widens. I'm well aware of the problem, it tries very hard to limit its effect already, I might work on it some more later but there are no trivial solutions. (I've tried freezing both borders, but this hinders simplifications far too much, and I've tried merging it after all, but it just gives very poor results in terms of textures, as I feared).
------------------------------
edit:
I see... I don't think it will ever be much robust, but try redonloading the newly re-uploaded "0.0.58b" version (I not even make an update in the 1st page for it) and see if it works any better for you
I've changed the way lods are done a little... I'll put lod making as it was before, in a "b" new version.
It saves them on exit. Just exit once, so that it saves it.Bolkonsky said:
----------------------------
Vornne said:Swyter talking about compiling was enough to get me to have another go at building it on linux (the last time I tried you fixed the bug so quickly I forgot about it
Wow, OpenBRF running on Linux, that's great! I'll try fixing the compilers errors you reported when I have time, if not else for general code hygiene.
----------------------------
It would be quite messy to make it work that way. Simplification does not remove faces: it merges them into larger faces.GetAssista said:
So you don't want any of the new larger faces to span across "seams", that is, the lines of UV discontinuities (for example, you cannot have a triangle span over different texture atlas regions).
To separate vertices among UV-seams was just a way to avoid that. Unfortunately, yes, it creates that artifact you mention. I'm well aware of it, it is already a lot better than what I got in my first attempts. The problem could be described as having two initially overlapping borders which should in theory be simplified in sync, but are not, so a gap opens between and, because simplification generally tends to shrink stuff, it widens. I'm well aware of the problem, it tries very hard to limit its effect already, I might work on it some more later but there are no trivial solutions. (I've tried freezing both borders, but this hinders simplifications far too much, and I've tried merging it after all, but it just gives very poor results in terms of textures, as I feared).
------------------------------
edit:
Red River said:me too got a lot of LOD related crashes. this was not happening with the original verion that introduced LOD pyramid. I used to have like 3 meshes that didn't like it and now it's a LOT more.
nice to be able to change the reduction % though (when it works
keep up good works!
I see... I don't think it will ever be much robust, but try redonloading the newly re-uploaded "0.0.58b" version (I not even make an update in the 1st page for it) and see if it works any better for you
