hyperion
-
Posts
894 -
Joined
-
Last visited
-
Days Won
2
Posts posted by hyperion
-
-
2 hours ago, DanW58 said:
EDIT: Also, don't forget, this mechanism doesn't prevent you from making your own rust using the normal texture channels; it merely gives you a shortcut way to do it, that is easy to modify, and lessens the amount of work in creating custom materials with delineated rust zones that may not be useful to other objects.
So how are you gonna render it in blender?
2 hours ago, DanW58 said:EDIT2: Yet another advantage is that once the metal textures are created, each with its own Aged_Color, a misled or subversive artist cannot easily call for blue rust on iron, or red rust on gold. Assuming your material textures are organized into larger "album" textures, I imagine there is some protocol to follow before someone can add a new member to the album, right?
Adding such an album to the shader doesn't scale. There are hundreds of materials used.
-
Ageing is an over-definition/redundant, can be expressed by changing albedo, is metal, roughness, etc.
-
11 hours ago, DanW58 said:
So, there is NO difference between specular/gloss and metal/roughness; it is a nomenclature. Pure semantics. Specular and Metal are the same thing. Gloss is the same as roughness, though they sound like opposites, namely specular power.
There is no difference in that both can be used to depict materials realistically, but the difference in implementation and ability is obviously more than just semantics.
11 hours ago, DanW58 said:EDIT: In fact, I think I'm starting to see an even more interesting use of the metal channel. At the middle values, like from .3 to .7, it could represent various types of rocks. The materials used for "stone" and "metal" could come from the .333 and .667 set points of the "metal" channel, in fact...
I wouldn't start assigning random interpretations to channels but stand on the shoulders of giants like Disney, Adobe, etc. Do like the others do.
https://www.khronos.org/blog/art-pipeline-for-gltf
Describes a set of textures and assignment of channels under "texture requirements"
QuoteThe glTF format supports the following textures for the Metallic-Roughness PBR model:
- Base Color
- Metallic
- Roughness
- Normal
- Ambient Occlusion
- Emission
The format does expect the textures in a specific format, however. The Base Color, Normal, and Emission textures are saved as individual files, preferably a PNG as the format is lossless. The Ambient Occlusion, Roughness, and Metallic textures are saved in a single channel-packed texture to reduce the number of texture loads. The textures need to be packed into the channels of your texture as follows:
- Red: Ambient Occlusion
- Green: Roughness
- Blue: Metallic
Going forward, I will refer to this channel-packed texture as the ORM texture for Occlusion, Roughness, and Metallic.
The set is obviously sufficient to depict realistic stone as can be seen in
https://www.turbosquid.com/Search/Index.cfm?file_type=1022&keyword=stone&media_typeid=2
-
23 hours ago, DanW58 said:23 hours ago, hyperion said:
If you hold a leaf towards the sun some light leaks trough, so "transparency" isn't just about glass.
Ah, but that's not "transparency"; it's "translucency". But I get what you mean. If I grab a piece of tinted glass in front of my face and DON'T change the angle, I get constant transparency rate, and therefore something similar to Alpha. But in any case, what I meant is that Alpha is useless in 3D graphics unless you want to model a teleporter.
Khronos calls it transmission,
-
18 hours ago, DanW58 said:
Okay, @hyperion fingers and toes crossed... knocking on wood... this should fix the problem.
Still get the same error.
-
ERROR: Failed to compile shader 'shaders/glsl/model_common.vs': 0:138(2): error: `v_half' undeclared 0:138(21): error: `sunVec' undeclared 0:138(21): error: operands to arithmetic operators must be numeric 0:138(11): error: no matching function for call to `normalize(error)'; candidates are: 0:138(11): error: float normalize(float) 0:138(11): error: vec2 normalize(vec2) 0:138(11): error: vec3 normalize(vec3) 0:138(11): error: vec4 normalize(vec4)
-
1 hour ago, DanW58 said:1 hour ago, hyperion said:
AO baking is also a hack
How?
It's static.
1 hour ago, DanW58 said:I don't understand the part of
2 hours ago, hyperion said:One is specular/gloss, the other metal/roughness.
To me all of that is necessary to describe a material; I don't see where there is a "choice" to make.
basically what can be taken from there metal/roughness model:
- taken from Disney
- more intuitve
- saves two channels
- doesn't permit physically impossible materials
-
1
-
Just had a quick look at the patch uploaded to phab.
If you want ao to always range from 0-1 as mentioned in TODO 1 for any given map you might want to provide a script around imagemagick so you and other users can convert their assets to test this case as well. No need for the shader to take care of it.
ERROR: Failed to link program 'shaders/glsl/model_common.vs'+'shaders/glsl/model_common.fs': error: fragment shader varying v_half not written by vertex shader
-
Lots of text, so I will only pick a few points out.
8 hours ago, DanW58 said:One thing this shader will NOT indulge on:
Screen-space ambient occlusion. These are algorithms that produce a fake hint of ambient occlusion by iterative screen-space blurs of Z depth -tricks. They are HACKS.
AO baking is also a hack, an even older one at that. There is a reason why ssao was developed and why there is even hardware support for it. I agree this is orthogonal to a new shader/stack project and can be tackled later by someone if they feel like it without interfering here. So leaving it out for now seems reasonable.
27 minutes ago, DanW58 said:Alpha? Let me say something about alpha: Alpha is for the birds. Nothing in the real world has "alpha". You don't go to a hardware store or a glass shop and ask for "alpha of 0.7 material, please!" Glass has transparency that changes with view angle by Fresnel law
If you hold a leaf towards the sun some light leaks trough, so "transparency" isn't just about glass. Whether to use alpha channel or something else is another question.
---
So I did a bit of research, there are basically two workflows for pbr. So the first thing to do is to figure which to pick for 0ad. One is specular/gloss, the other metal/roughness. The latter seems to dominate and the former is sort of considered old school. Converting between them is reasonably possible and 3d software sellers seem to support both. I favour metal/roughness for the simple reason that it seems more common in industry and more intuitive for non physicists. I have no strong opinion but this is something that should be discussed with core developers first before jumping into implementing the shader / specifying the stack.
Next is what channels/information is needed.
- AO map seems gone in your list.
- A player_colour bit. If I'm not mistaken alpha is currently used for this.
- You mention glass I mentioned a leaf, there are fantasy mods and you talked about a space mod. So the specification for the stack should handle this sort of materials, whether to implement them now, later or never is not that relevant.
- Materials that emit light, lava for instance or fluorescent paint/engine on a spaceship.
- Clear coating?
- Others?
Encoding/bit-depth: If there is an industry standard for which channels get packaged together and their order as well as their depth this should be picked. Requires some research but will certainly help with tooling / interoperability.
UV: Probably should only ever support 1
-
2 hours ago, DanW58 said:
blue dresses
Supposedly they are player_colour, maybe shouldn't be touched.
-
7 hours ago, wowgetoffyourcellphone said:
A reimagined Lorraine Plain map using new Temperate terrains
Replacing rivers with streets makes this sort of a different map. More like yet another variation of mainland.
The farmland in front of red seems to be a mound. Usually the darker colours are at the lower parts signifying wet while the higher parts already dried after some rain.
I really like the trees in all your screenshots.
-
First of all I'm not part of the project and don't represent it so you can just ignore me all together if you want. Secondly if you already know that you fixed the issue that I might have encountered no need to get upset as you obviously agree with me that there were and still might be pending issues. I have other things to do so reaction time is bound to be slow, if you want me to always use your latest changes clone the git repo and push a branch to github or wherever so I can add your repo as a remote. Then there is no need to copy unversioned files from different threads witch might or might not be part of the same effort around and no need to notify me that there are changes in the first place. Also with proper commit messages I already know what got changed since the last test and I can reference a commit hash when I comment. All I can say is the direction is worthwhile however the version I looked at clearly isn't there yet. That there is a need to touch assets is obviously just a guess, I'm happy if you prove me wrong, but if you have to touch them it's a lot of work. With a new stack right after this all might be in vain. This is also not just about vanilla but also all assets in mods, so even if you fix everything in vanilla others still have to fix the rest.
Collaboration is always more about communication than coding, if you are completely averse to this you better stop earlier than later. This has nothing to do with brown nosing, bashing or the like but is just the nature of it.
As for a new stack, me thinks it's a good thing. If undertaken don't expect it to land within days. Planing, discussion, implementation and finally reviewing will take a lot of time. This is far from a one-liner after all and involves the interests of many.
Perfectionism is a prime source of stress. Nothing will ever be perfect. Anyway take care of your health, that's most important.
-
1
-
-
Well, for A24 it's late anyway, probably a matter of hours till release.
A new set of shaders with an incompatible texture stack sounds like a plan to me. Though I suggest to discuss a proposal at least with @vladislavbelov and @wraitii for the technical aspect and with @Stan` as the artist representative, without their agreement there won't be an inclusion. They might have done some work into that direction already or at least might have some plans or requirements. Also there might be additional needs for mods, like glow or transparency. So consulting major modders like @wowgetoffyourcellphone or @The Undying Nephalim (Hyrule Conquest) might be a good idea as well. Anyway easy import/export and intuitive mapping I think are prime concerns.
I had a deeper look at the result of the shaders in the other thread and there is often an improvement, but sometimes a digression. The reason might be poorly baked ao, interaction of shadows with ao or something else, I can't tell. The most important thing is it introduces a variation of quality in visuals which makes me think it's about as good as doing nothing. Sure this can be fixed by revisiting many assets, but is it worth it considering when there might be a new stack?
Another thing to consider is whether baking ao is still preferable over using some post processing algorithm.
-
Dan,
what I meant is except for metal all others are similar enough to not care. I mean photorealistic rendering can't be done as a 1-2 frames per hour don't allow for a fun game. So we end up with compromises anyway.
As for implementation, as it's 0ad we definitely need a 3rd distinct uv for the metal bit map! More seriously, clever encoding shouldn't be a concern. What is important is to make importing and exporting from lets say blender straight forward. So I downloaded a pbr texture for use in blender. It comes with the following maps: albedo, ao, height, metallic, normal, and roughness. Sure you could substitute metallic and roughness with specular, diffuse and glossiness. I guess blender also supports the latter somehow but the former seems like it's more intuitive for an artist as it's closer to how we perceive materials.
I'm not fond of the approach of detecting material. Let's say the algorithm works for the current assets. Now I would like to add a new model and the algorithm misdetects metal. So how should I know what to change to get the heuristic working. To me it seems this approach is a pain in the neck for artists. I might be wrong ofcourse.
The screenshots at least demonstrate that 0ad may profit from a more realistic render.
-
3
-
-
Roughly it's metal and non metal materials, the rest shouldn't be of much concern in a real time engine, right? So why not simply provide a map where the artist can explicitly state what are metals and what are not. Wouldn't that make it easier for shader and artist alike with no possibility of misidentification?
Btw, I quickly had a look at the patch in the post you linked but need some time to go through more maps and civs to give a somewhat educated answer, haven't ignored you
-
1 hour ago, DanW58 said:
How the ancients used white in architecture it's unreasonable that the ground is "whiter" than the CC. While the ao might have improved I guess it also highlights the need to fix base colour.
To really give an answer whether I share @Stan` fear you claim please provide all your changes as a single patch against trunk or a mod to play with.
-
47 minutes ago, DanW58 said:
But it would be better to get them all done at once, really. Having disagreeing assets is not nice.
But in any case, you can zip the whole thing as a backup, should something really go wrong.
Using a vcs there is no need for zip backups, but using a vcs is probably also the reason why this hack got introduced ...
36 minutes ago, Stan` said:Fourth Option: I make a patch and we merge it along with some other improvements in A25. This way it gets done, no risk for now
As long a releases are not years apart everyone is patient enough to wait for the next release.
Edit: something went wrong when submitting the post
-
2 hours ago, DanW58 said:
I'm willing to put in the work. White is a color that should never be used for materials, really. It doesn't exist in the real world. Nor does black for that matter, though in some situations it may be useful.
If you have to touch a lot of the assets for this it might make sense to go further. Not saying you have to or that what I'm going to throw out is the way to go, just that I think it's worth discussing. Once more I'm not a graphics guy nor artist.
PBR came up earlier in this thread. Maybe it's worth considering adding a prefer spirv option analogue to the existing prefer glsl one. Sticking to glsl 4.6 for the time being is fine. The idea is to reuse this shaders for a future vulkan renderer. This set of "pseudo spirv" shaders can assume modern hardware and drivers supporting opengl 4.6, respectively vulkan, and the goal is PBR. Then while fixing the assets convert them to glTF which lends itself to PBR and has likely better support and for sure better interoperability than the discontinued collada.
If this results in some degradation in visuals for old hardware I think that's fine. If you already run on ultra ugly settings like no shadows and simple water some colour skew hardly matters any more.
The main question probably should be if there is someone/few capable and willing to do this and whether the artists are fine with PBR and glTF
-
The latest shaders actually look like a slight improvement, however, just as you said, whitish textures need fixing now.
-
11 hours ago, Samulis said:
It is the real sound of me cutting a log with an axe actually!
I listened in on it once more with full attention and disabled music this time. There are one or two hack sounds in there that aren't bad actually. Just that those off ones are far more noticeable. I'm not good at describing sounds so I searched for a reference for how it sounds when hitting with an axe actually gives a result, see video at 5 minutes in
12 hours ago, Samulis said:The metal isn't realistic
True, but throwing javelins doesn't make any sound at all either. Artistic freedom it is. The current stone fx sounds like a pike hitting on granite which I like but feel free to change it.
-
2 hours ago, DanW58 said:
My biggest fear was people not noticing it
There was a clear difference, thou it neither looked real before or after. If I had to describe the difference it's moving an arcade landscape from Europe to Africa, less humidity and less distance for light to travel trough the atmosphere.
Will test your latest changes later.
-
13 minutes ago, Samulis said:
There were issues with the sound code which caused levels of some sounds to be massively off, so we are still tweaking levels to get sounds at correct volumes.
Yeah, that would improve things by a lot.
16 minutes ago, Samulis said:For example, the metal and stone sounds were not done by any of us
Stone sounds rather good, metal not that bad either IIRC
-
9 minutes ago, Stan` said:
I think it sounds better than A23B less clickety.
The one for gathering wood is the only one I noticed to be completely off. Like two wooden sticks used as an instrument as a beat in a track. When it sounds like this you certainly wont cut a tree within a decade.
There are sure quite a few sounds to get used to, overall the quality of the sounds seems better.
-
1
-
-
You also need to take out "v_normal.xyz = normal;" of the conditional in the vertex shader for the program to link.
Well, tested on a few maps, still looks ok, can't say better or worse, but then again I'm not a graphics guy.
24 not available on Debian Buster?
in Help & Feedback
Posted
Zero day bump request are discouraged as it may causes unnecessary work for triage and maintainers. If your distro still doesn't have it updated by now filing a bump request is fair game. Make sure there isn't a bug filed already.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983408