Jump to content

Rend2 - A Modern Renderer


Xycaleth

Recommended Posts

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

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

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

@@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. :D
Link to comment

Ohhh, I was thinking parallax. :P

 

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 :D

nice, i will totally check that out.

Link to comment
  • 2 weeks later...

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

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

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

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

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...