SomaZ Posted April 20, 2016 Share Posted April 20, 2016 Another progress video on the refraction shading. Some stuff is still missing, but i think it looks quite nice right now.https://www.youtube.com/watch?v=rLCSrBlEU3Q Maksman, Exmirai, Raz0r and 1 other like this Link to comment
Futuza Posted April 21, 2016 Share Posted April 21, 2016 I think the effect, at least for the bubbles might still be a bit too severe. Force Push/Pull seems fine though. Tempust85 likes this Link to comment
SomaZ Posted April 21, 2016 Share Posted April 21, 2016 I think the effect, at least for the bubbles might still be a bit too severe. Force Push/Pull seems fine though.Hm, problem is, that the vanilla refraction is hard coded for the objects. There are no individual refraction parameters for e.g. the invincibility shpere or the force pull. I will lower the effect strenght and see if thats better. Link to comment
Xycaleth Posted April 21, 2016 Author Share Posted April 21, 2016 There's a few parameters that the game sets. Check tr_main.cpp Link to comment
SomaZ Posted April 21, 2016 Share Posted April 21, 2016 Ok i found what vanilla does. Its in tr_shadows. So game actually sets some stuff, but nothing really useful for an actual refraction. They simply take a part of the rendered picture (the size and middle point of the cut out are defined) and put it on the "refractive" surface. Then they have a variable to strech it. It's basicly zooming in and out with some blend modes. There is one variable which is usefull for my current implementation. It's the alpha of the refraction. But i will add the wobble/stretch effect of the vanilla render. Link to comment
ensiform Posted April 21, 2016 Share Posted April 21, 2016 They also use image or shader "-2" to signify that its something that needs to be refracted, no? Link to comment
minilogoguy18 Posted April 22, 2016 Share Posted April 22, 2016 I check this thread every time I sit at my computer, so glad it's being worked on again. Gonna wait til the next build when supposedly some things are going to be fixed before I download and start testing models that use displacement maps. Archangel35757, Tempust85 and Exmirai like this Link to comment
SomaZ Posted April 22, 2016 Share Posted April 22, 2016 They also use image or shader "-2" to signify that its something that needs to be refracted, no?The only thing i know is that there is an entity flag RF_DISTORTION. And this is manually set in the game aka hardcoded. Also the vanilla renderer rendered stuff refractive only with that flag. I'm not sure what you mean with image or shader "-2". You mean in the old id3 shader files? I will investigate if the renderer sets the flag, but right now i doubt it. Link to comment
Tempust85 Posted April 22, 2016 Share Posted April 22, 2016 @@minilogoguy18 Afaik, displacement maps either aren't supported or do not work correctly on models. The only place they work is maps. Link to comment
SomaZ Posted April 22, 2016 Share Posted April 22, 2016 @@minilogoguy18 Afaik, displacement maps either aren't supported or do not work correctly on models. The only place they work is maps.As far as I know the only engine that implemented parallax displacement on animated models is CryEngine. They called it the secret toad tech in a trailer. Link to comment
Tempust85 Posted April 22, 2016 Share Posted April 22, 2016 Even if player models had displacement maps working, it'd have to be used very carefully or you won't get a decent result. Tbh, normal maps suffice. Archangel35757 likes this Link to comment
AshuraDX Posted April 22, 2016 Share Posted April 22, 2016 As far as I know the only engine that implemented parallax displacement on animated models is CryEngine. They called it the secret toad tech in a trailer. not parallax - actual vertex displacement + ridiculous tesselation Futuza and Tempust85 like this Link to comment
SomaZ Posted April 22, 2016 Share Posted April 22, 2016 not parallax - actual vertex displacement + ridiculous tesselation You are right, they called it the "Top secret tesselated toad tech". Damn, i need to check my facts before i post something here. Link to comment
Tempust85 Posted April 22, 2016 Share Posted April 22, 2016 Ohhh, I was thinking parallax. Also a bug carried from ioquake3's rend2 is parallax textures meeting at a wall join/corner produces a gap in the brushwork. Not sure if this can be fixed at all, but worth mentioning. Link to comment
Xycaleth Posted April 22, 2016 Author Share Posted April 22, 2016 New build with dlights turned back on Link to comment
SomaZ Posted April 23, 2016 Share Posted April 23, 2016 Ohhh, I was thinking parallax. Also a bug carried from ioquake3's rend2 is parallax textures meeting at a wall join/corner produces a gap in the brushwork. Not sure if this can be fixed at all, but worth mentioning.its called parallax occlusion mapping with silhouettes. I guess that would be the problem solver for this particular problem. But it comes quite costly. And i think it never was really usable. The tesselation stuff with displacement replaced that immediately. New build with dlights turned back on nice, i will totally check that out. Link to comment
ensiform Posted April 23, 2016 Share Posted April 23, 2016 Are there any maps etc that have rend2 features to test available? Link to comment
Silverfang Posted April 24, 2016 Share Posted April 24, 2016 Are there any plans for PBR? Link to comment
ensiform Posted April 24, 2016 Share Posted April 24, 2016 I thought there was talk of looking into it but he's not focused on adding any new features right now. Link to comment
Xycaleth Posted April 24, 2016 Author Share Posted April 24, 2016 Are there any plans for PBR?rend2 already supports PBR to an extent. I just need to review it to make sure it's doing everything correctly. Are there any maps etc that have rend2 features to test available?Not at the moment. SomaZ likes this Link to comment
Xycaleth Posted May 6, 2016 Author Share Posted May 6, 2016 Sorry there's not been any updates so far. I've been fixing the fall out from my latest optimizations I'm planning to get back to adding fog/weather system when I've done that. Archangel35757 and Tempust85 like this Link to comment
Xycaleth Posted May 9, 2016 Author Share Posted May 9, 2016 Been doing some research on PBR workflows. As far as I can tell there is a metallic and a specular workflow. Those of you who have experience with both, which do you prefer or think is better? From my point of view, the metallic seems to be better since it's more difficult to get wrong and uses less texture memory. Thoughts anyone? Link to comment
SomaZ Posted May 9, 2016 Share Posted May 9, 2016 I prefer the metal roughness over the gloss specular workflow. You can pack roughness and metal in one texture (only 2 grayscale layers and 2 are still free for eg. height), so its less textures to worry about. Since I work with Substance Painter its kind of irrelevant for me, because you can make custom texture exports. Also you won't need two colored pictures (color & specular) which kind of tells you the same stuff in PBR. Marmoset has a page with pro and contras https://www.marmoset.co/toolbag/learn/pbr-conversion (down at "Metalness Workflow vs Specular Workflow"). I hope that helps a bit. Link to comment
Scerendo Posted May 9, 2016 Share Posted May 9, 2016 Been doing some research on PBR workflows. As far as I can tell there is a metallic and a specular workflow. Those of you who have experience with both, which do you prefer or think is better? From my point of view, the metallic seems to be better since it's more difficult to get wrong and uses less texture memory. Thoughts anyone? I prefer metallic personally, but I use quixel and substance so it doesn't make too much of a difference. Link to comment
Archangel35757 Posted May 9, 2016 Share Posted May 9, 2016 Been doing some research on PBR workflows. As far as I can tell there is a metallic and a specular workflow. Those of you who have experience with both, which do you prefer or think is better? From my point of view, the metallic seems to be better since it's more difficult to get wrong and uses less texture memory. Thoughts anyone?Since this engine and game art used the traditonal Diffuse/Albedo & Specular maps... I think the transition would be easier to maintain a PBR Specular Workflow (with the additional AO, Cavity, and Normal maps). That will also likely produce better results (avoiding edge artifacts at material borders) with existing models/textures when converting them to PBR Specular in your code. Link to comment
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now