🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

OpenGL 4 reflections

Started by
110 comments, last by taby 1 year, 7 months ago
Advertisement

taby said:
I'm working on using procedural methods to generate the base of the level. Of course, I'm having trouble. ?

A good book about traditional procedural building blocks is ‘Texturing and Modeling: A Procedural Approach’.
It introduces things like Perlin Noise, voronoi cell patterns, etc.
Most of those things are on Inigo Quilez website too.

Gives stuff like this (procedural 3D textures):

It's fun. But while it gives us patterns we see in nature, it exists in a vacuum. It does not adapt to the surface we apply it to. It does not model any natural processes like erosion or propagating cracks. For such things we want actual simulation instead, which can generate the same patterns.

So maybe we want to use procedural patterns for realtime generation, where simulation would be too slow. But for realtime this is very costly too, as you likely want to combine multiple patterns at different scales.
So we end up baking the stuff to textures, which is offline. So we could just use proper simulations instead.

For those reasons, i see those procedural patterns mostly as a relict of the 90's or earlier. Noise remains useful, ofc. And i got detailed displacements which did look a bit like rock. But i associate it with a synthetic ‘retro computer geek artstyle’, reminding me on tools like Bryce or games like Myst.

Here's what I came up with. There's some serious lighting problems. As for reflections, scale(1, -1, 1) works perfectly. No need to translate or anything.

taby said:
As for reflections, scale(1, -1, 1) works perfectly. No need to translate or anything.

Not sure what you do, but i'd like to see it using multiple characters at different heights. Can't believe it works. ; )

Those stripe artifacts come from your toon lines rendering i guess? Maybe slight depth discontinuities trigger this for some reason?

I had to adjust the bias in the shadow calculation.

taby said:
I had to adjust the bias in the shadow calculation.

Do you render back faces to the SM? I guess this should work very well for voxel scenes, reducing sensibility on bias.

I end up skipping back facing triangles altogether in the OBJ loader. So no rendering tricks required. P.S. Of course I only do this for the game board. P.P.S. There is also the option of storing 6 triangle vectors, one for each normal, then only draw those that are front-facing.

Here you are. Multiple knights. ?

taby said:

I end up skipping back facing triangles altogether in the OBJ loader. So no rendering tricks required. P.S. Of course I only do this for the game board. P.P.S. There is also the option of storing 6 triangle vectors, one for each normal, then only draw those that are front-facing.

Makes little sense in context of the back face SM ‘trick’. But i just realize i should say front face, not back face. Here's what i mean:

If we render back faces to the SM (bad), the distance from caster to receiver is small, so we get peter panning due to bias.
If we render front faces (good), the distance is big, so no peter panning at the spot where the thin lines cast shadow to the ground.

But ofc. everybody usually renders front faces anyway, so not worth to mention i guess. I was confused.

taby said:
Here you are. Multiple knights. ?

But you made it much easier now by showing best case. The ground height variance was much higher in the other picture, and the camera angle was almost tangent to the reflection plane.
If you use same scene and camera as before, it should show real issues? I'd like to see those failure cases… ; )

What is SM?

This topic is closed to new replies.

Advertisement