FireMage on 28/10/2013 at 18:04
Don't worry! No pressure! :)
Let's do this slowly and peacefuly!
Renzatic on 28/10/2013 at 18:58
It's no problem now. I've got everything working 100%, and I'm ready to start.
The first thing I plan on doing is showing the various results of all the blends modes with nice examples posted next to them. I'm using both two text patterns using primary colors and letters, and two real world examples.
FireMage on 28/10/2013 at 19:47
The most interesting to test are all the stuff with the render_pass. The rest is quite easy to understand and use with the couple of explainations joined with the line in the txt, just a few comments more accurate are needed. ;)
Renzatic on 28/10/2013 at 20:09
I figured if I'm gonna do it, I might as well go all out with it. Have a nice reference for every single thing you can do with the material files, along with multiple examples thereof. If someone wants to find out how to do something, all they have to do is click the appropriate link to the chapter, look at what it says there, then see it ingame via the map.
It won't be all that hard, really. Easier than that brick wall tut I did awhile back, since the material files tend to be more specific, less nebulous than "paint a crack here".
LarryG on 29/10/2013 at 06:46
:thumb::thumb::thumb::thumb::thumb:
Renzatic on 8/11/2013 at 19:32
To show you all I haven't forgotten about you, (
https://dl.dropboxusercontent.com/u/3018396/Mat_Tut_Preview.png) here's a preview of what's up and coming.
I was wrong when I said it wouldn't be as hard to do as my brick wall tutorial. As far as pure facts go, it is easier. If I were being sloppy about it, all I'd have to do is say "here's what this does", then leave it at that. Explaining those facts in terms that are concise and easy to understand, plus providing pictures that explain the process is what's difficult, and what takes the most time. I have to understand it inside and out myself before I can attempt to do that.
If I have the time, I'll hopefully have the blends tutorial up by tonight.
R Soul on 8/11/2013 at 19:37
That looks very good. Thanks :thumb:
FireMage on 8/11/2013 at 20:44
Wow! Congrats!
Me I have done soooo leeesss things due to my studies! XD
So, what have you tested and shown in your PDF already? Everything? The half? Oo!
PinkDot on 8/11/2013 at 23:45
Renzatic - you're definitely on the right track! I like the way you're selling this tutorial to the Thief community on a parchment texture! :)
If you're open for suggestions (which are questions at the some time...):
1) I think you could give a visual example of what you're talking about on the first page, about the alpha channel. It seems to be a concept deserving more thorough explanation.
2) I'm not sure if the definition of the source is clear. I always thought that SRC meant colour of a pixel currently on screen. DST would be a colour of a pixel from the texture you're overlaying it with. But again - these blend modes were always difficult for me to understand...
Keep up the good work - you're putting a lot of thought and effort into this and I'm sure it will pay off!!!
ZylonBane on 9/11/2013 at 00:36
A note about material folders. The sample material mods that come with NewDark use the following folder structure:
tex
+-LUTs
+-envmaps
With all respect to the NewDark author(s), I'm not a fan of this setup. First (if most trivially), "tex" isn't very descriptive. Tex, presumably standing for "texture", could refer to any texture resource-- terrain, object, particle, material, whatever. Second (and most actually problematic), having a separate folder for each type of material resource causes two issues-- It's a nuisance to bounce between multiple folders when developing a material effect, and it multiplies the chance of filename collisions when multiple material-using mods are installed. For all these reasons, I've been using the following folder structure for my own material experiments:
material
+-shtup
+-scp
+-etc
This setup adopts the organizational concept of the FAM folder, with each mod confining all its support files to a single folder, so multiple mods can have files of the same name without overwriting each other (in programmer-speak you'd say that this gives each mod its own namespace). The only chance of conflict this way is if two mods use the same folder name. Not much we can do about that other than to be careful and pick properly unique and descriptive names for your resource folders, but still, the filename conflict problem is massively reduced. Also the root folder name is now "material" instead of "tex", which is descriptive while also fitting neatly into 8 characters.
Another recommendation is the placement of INC (include) files. The NewDark sample material mods place their INC files in the same place as the MTL files-- directly in the FAM or OBJ folders. This offends my sense of organizational purity (har har), since IMHO all support files for a material should be together in the resource folder. But there's also a real problem that this requires duplication of otherwise identical INC files if they're used by materials in multiple FAM folders.
Fortunately, after much hair-pulling, I worked out that NewDark's inclusion syntax support relative folder paths. So instead of, say:
include reflec.inc
...for a reflection effect, with the INC file duplicated in every folder that uses it, you can do this:
include ../../material/shinymod/reflec.inc
Allowing just a single copy of the INC to reside in the mod's resource folder.
Finally, I'm not a fan of PDF documents that use fancy bitmap backgrounds. This makes them a) harder to read, and b) use a shitload more ink when printed.
