LuxCoreRender / LuxCore

LuxCore source repository
Apache License 2.0
1.15k stars 144 forks source link

Parallax bump mapping #501

Open Nicknroll opened 3 years ago

Nicknroll commented 3 years ago

Hello! I found a topic at forum about Parallax bump, but there i can't find clarification if it possible for LuxCore. parallaxbump

So here is a link at some code for Cycles: https://developer.blender.org/D9198

Please check possibility to implement it for Lux.

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/96585533-parallax-bump-mapping?utm_campaign=plugin&utm_content=tracker%2F79505306&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F79505306&utm_medium=issues&utm_source=github).
Theverat commented 3 years ago

See https://devtalk.blender.org/t/parallax-occlusion-mapping/15774/12

I don’t think this should be implemented in Cycles. It’s not a technique that’s great for path tracing, and it complicates the Cycles kernel. Especially when it comes to further improvements like better shadows or shell geometry, it’s not a direction I want to go in, but rather focus on improving the adaptive subdivision and displacement system rather than adopting game engine techniques.

The same probably applies to LuxCore. Parallax occlusion mapping makes more sense for realtime engines than for offline renderers.

juangea commented 3 years ago

To be honest... I disagree with that comment, IMHO that kind of "discard" comment has been repeated along the years, but no alternative has been developed, some of the things we have in BoneMaster (like LightGroups) are functional and working, and they are from 2018 for example, however there is always some thing like "better don't do this, but this" or "better not use this but that", but the alternative takes years to be implemented if it is implemented, in the case of lightgroups it's a matter of changing a little thing according to the discussion that was there, and they are perfectly working right now, yet never happened for the time being.

On the other hand, Corona has evolved a lot and provided alternatives, I'm not sure how 2.5D displacement works, I suspect it's a mixture of displacement and parallax mapping where only the borders on the camera are actually displaced and the rest is parallax in sync with the real displacement.

https://forum.corona-renderer.com/index.php?topic=26764.15

Also there are some interesting tests there, so while I understand what Brecht says there of no using game techniques, the idea behind is to be smart and use "game techniques" where they are useful in conjunction with offline render techniques, and avoid stagnation in general, render engines survive out of evolution and if no new things are done or tested nothing will evolve, LuxCore is a super great example of that, the evolution done here in comparison with other engines is astonishing and amazing.

Maybe parallax has some problems, but anyways, personally I try to stay away from that type of comments/thinking because the experience told me that in general they are wrong, and usually the time demonstrates it, think of normal mapping... it was a game technique to avoid high poly meshes for example, it was not thought for offline rendering, and it has all kind of benefits :)

Nicknroll commented 3 years ago

Yeah that what I'd like to say If it possible why not? Since normal maps initially game engine technique too. In Fstorm it works great: https://youtu.be/REds4YTjn1A?t=1724

juangea commented 3 years ago

Yep, it's an amazing feature, it just lacks the ability to displace in the edges seen by the camera, I think that's how 2.5D displacement works in Corona.

Anyways, parallax alone it's already a good feature to have.

14AUDDIN commented 3 years ago

It was disscussed in the LuxCore forums: https://forums.luxcorerender.org/viewtopic.php?f=12&t=2288&hilit=parallax There's a chance that it might not work with Bidirectional Path-tracing, Light Tracing or Photon Mapping.

Theverat commented 3 years ago

What we need first before evaluating this any further is an exact description of the algorithm to use.