Announcement

Collapse
No announcement yet.

UE4 still does not have any proper way to do tinted glass

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • replied
    I believe what was meant by provide a solution is "write shader code to do this". If you can not, you have absolutely 0 right to say anything is "simple", otherwise you should just go do it.

    Oh and regarding the glass, that's hardly a tinted car window.
    it works slightly differently with blown glass, but the idea is the same. You pigment silica with different colors/dies. Just because melting it makes it appear as one surface it does not mean you have just one surface.
    and you may or may not use coatings on blown glass too. It depends on what kind of finish gets put on it, so you should probably refrain from generalizing it in the first place.
    Last edited by MostHost LA; 10-16-2019, 09:42 PM.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post

    I already did, few posts above. All I'd want would be modulate blend mode which is compatible with Surface TranslucencyVolume model.
    Click image for larger version

Name:	Translucency.jpg
Views:	310
Size:	208.9 KB
ID:	1674431
    Even if it comes with some limitations, such as inability to stack modulate materials, it would still cover most of the use cases.
    How exactly modulate blend would help you here? Modulate blend multiplies source by destination.

    Leave a comment:


  • replied
    Originally posted by Deathrey View Post

    If you know, that it is simple, how about you offer a solution or propose an approach instead?
    I already did, few posts above. All I'd want would be modulate blend mode which is compatible with Surface TranslucencyVolume model.
    Click image for larger version

Name:	Translucency.jpg
Views:	310
Size:	208.9 KB
ID:	1674431
    Even if it comes with some limitations, such as inability to stack modulate materials, it would still cover most of the use cases.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post
    This is where you are very wrong. Unreal's renderer is one of a very few rasterizers where rendering a tinted refraction/translucency has to be a workaround. This is another one of the common, fallacious arguments - that the tinted refraction is commonly a complicated thing to do.

    Originally posted by Rawalanche View Post
    What's sad is that most of people here have a perspective so deformed by a decades using a hacky way rasterizers do things that they are unable to think outside of the box, and see much simpler solutions. Especially since many of these hacky, overcomplicated ways are products of technical limitations which are long gone these days.

    If you know, that it is simple, how about you offer a solution or propose an approach instead?

    Leave a comment:


  • replied
    Originally posted by MostHost LA View Post

    Is it a lot of work? No doubt. Is it a workaround? Not so much. To get something to look good you would probably have to set things up very similarly in almost anything...
    This is where you are very wrong. Unreal's renderer is one of a very few rasterizers where rendering a tinted refraction/translucency has to be a workaround. This is another one of the common, fallacious arguments - that the tinted refraction is commonly a complicated thing to do.

    Originally posted by MostHost LA View Post
    Its actually how the tinted glass works IRL if you think about it. It's one layer of coating over the glass.
    In the engine you just have to invert it to get it to display properly.
    Mostly because the reflection in front of it needs to shine and the layer in between is the shade of tint which you can manipulate/change on the fly.
    Here you are also very wrong. Regular generic tinted glass, such as red glass is a SINGLE dielectric solid medium without any coat. What gives it a reflection is just polish of the surface, which makes the surface structure very fine.
    Click image for larger version

Name:	BlockOpticTumbler56a016955f9b58eba4aedd16.jpg
Views:	336
Size:	24.7 KB
ID:	1674291
    There is absolutely nothing on a material like this which involves multiple layers.

    What's sad is that most of people here have a perspective so deformed by a decades using a hacky way rasterizers do things that they are unable to think outside of the box, and see much simpler solutions. Especially since many of these hacky, overcomplicated ways are products of technical limitations which are long gone these days.

    What I want is something that IS technically possible, to be a one click solution instead of complex set of steps. So that I, as an artist, can spend my time focusing on more important stuff. This just comes down to me being able to trust Unreal's shading model to handle all the possible real world materials. Currently it can handle all of them except tinted glass, which means it's incomplete. All I am requesting is that it's a complete shading model.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post

    The rudimentary script which would be created to create tint material geometry for static meshes would hardly work for simulated fluid caches. Anyone with any DCC familiarity would know that. So it would require some elaborate monstrosity which would cover also a case of animated mesh with dynamic topology. Those are usually heavy so it's also hardly something you want to be playing back and keeping in memory twice.
    You can set up transparency to render in different passes, and that's precisely how you handle water with things like waves.
    It's fairly complicated, It looks like **** most of the time, but it does work.
    The 2 render passes allow you to single out what is visible and what is invisible on your own priority.
    This is generally useful when you make waves. The reason being that 1 pass needs to show you what you actually see (normals pointed at camera) and hide what you dont see (the backside of the wave) or sort between the 2.
    Without the filtering you end up with holes in the water - those arent holes but back faces displaying in front of the front faces. All of which you would discover when working with an ocean/water body from scratch. It's also not an "this engine only" thing. It's how most rendering works. In the end The UE4 workaround is actually a GameGem implementation....
    All that to say, you dont necessarily need double the geometry to sort transparencies.

    But, in the case of tinted glass you really do.
    Its actually how the tinted glass works IRL if you think about it. It's one layer of coating over the glass.
    In the engine you just have to invert it to get it to display properly.
    Mostly because the reflection in front of it needs to shine and the layer in between is the shade of tint which you can manipulate/change on the fly.

    Particularly for cars - if they are built well - all the windows are already separated/individual meshes so that you can get them to break as needed.
    It takes a whole 10 seconds to select a window and edit it out to have 3 layers of the same window mesh at a distance of .1mm (Because my inside needs reflections too, yours might not).
    It also adds overall thickness to the mesh, and it can eventually end up allowing you to create the additional rounded edge seam so you can lower a window like IRL.

    Sure, those are all things you may never need IF you don't plan on having the user/player enter a car, but if you set stuff up as detailed by the epic documentation you get a leg up should you ever change the way it works.
    That's mostly why I don't believe this to be any sort of "hack" but a logical approach to how you can set different shades of tint with minimal work, on the fly.

    Additionally, keep in mind what I was saying about the reflectors also extends to front lights and such.
    The real life items in this case really do have several "coatings" or layers as well. The refractors/brake lights for instance have up to 3 layers of plastic with different coatings on them. The front/fog lights have at least 2 (front transparent plastic and interior chrome plating).

    Is it a lot of work? No doubt. Is it a workaround? Not so much. To get something to look good you would probably have to set things up very similarly in almost anything...
    Last edited by MostHost LA; 10-15-2019, 08:10 PM.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post

    I understand the claims you are making, but you still don't understand a crucial difference between complicated solutions which are justified, and those which are not. I never claimed I am going into UE4 with the expectation to replace a path tracer with it. I do understand difference between realtime rasterizers and offline path tracers. But there's GIANT difference between technical limitations of the technology and usability deficiencies.

    Many of the "weird workarounds, hacky solutions, and approximations" as you put it are necessary since many of the effects just can't be otherwise achieved with realtime rasterizers, but things like tinted glass is not one of them. A simple additional shading mode, or ability to use two existing shading modes together is completely realistic and there are quite a few other rasterizers out there that show it's easily possible.

    I am talking specifically about a class of usability issues which are not a consequence of underlying technical limitations and yet come at a significant cost in terms of artists' time.

    To put it bluntly, way too many times I've heard the something along the lines "It's complicated because this is a realtime renderer excuse". My point is that it does not always apply. There are many cases which are as simple as usability design flaws, rather than products of technical limitations. Or in other cases, perhaps products of technical limitations which have been resolved for sometimes up to a decade now.
    There's certainly an interesting discussion to be had regarding the limitations of translucency in Unreal specifically, the limitations of translucency in deferred rendering overall, and the limitations of translucency in real time generally.

    And I have no doubt that you do hear from a lot of people who don't understand that the distinction between those things exists and matters. That said, I certainly don't think anything I've said here really pertains to that topic, to say nothing of it demonstrating a fundamental misunderstanding on my part.

    Again, I thought I pretty explicitly and consistently laid out the scope of what I was talking about. If anything I said in particular suggests otherwise, feel free to highlight it so that I can be more clear in the future.

    Otherwise, I do think it's clear to both of us that a) there are lots of interesting discussions to be had broadly regarding translucent effects, both from the angle of workflow and from a theoretical standpoint, and b) we are not having any of those discussions.

    Leave a comment:


  • replied
    Originally posted by amoser View Post

    No. I've done it on multiple occasions and it works fine. Let me know if my posting a video would change your mind.


    See, this is what I mean about not communicating. You still seem to be responding to a claim that I have noted from the beginning that I am not actually making. You will find no disagreement from me that there are many caveats associated with using Unreal as a substitute for an offline renderer. Yes, doing this absolutely requires weird workarounds, hacky solutions, and approximations. If I thought otherwise, I promise I would have said so earlier.

    In fact, I have been and am saying something very near to the opposite of that: that there are so many obstacles to using Unreal as a complete replacement for an unbiased path tracer, many of which cannot be surmounted even with workarounds, that the fact that there is a usable solution at all to the particular problem of tinted glass means it's probably not at the top of the list of things that need to be addressed.

    Even more specifically, I was merely pointing out that several of the particular claims you made regarding the approach linked to by MostHost LA were factually inaccurate.
    I understand the claims you are making, but you still don't understand a crucial difference between complicated solutions which are justified, and those which are not. I never claimed I am going into UE4 with the expectation to replace a path tracer with it. I do understand difference between realtime rasterizers and offline path tracers. But there's GIANT difference between technical limitations of the technology and usability deficiencies.

    Many of the "weird workarounds, hacky solutions, and approximations" as you put it are necessary since many of the effects just can't be otherwise achieved with realtime rasterizers, but things like tinted glass is not one of them. A simple additional shading mode, or ability to use two existing shading modes together is completely realistic and there are quite a few other rasterizers out there that show it's easily possible.

    I am talking specifically about a class of usability issues which are not a consequence of underlying technical limitations and yet come at a significant cost in terms of artists' time.

    To put it bluntly, way too many times I've heard the something along the lines "It's complicated because this is a realtime renderer excuse". My point is that it does not always apply. There are many cases which are as simple as usability design flaws, rather than products of technical limitations. Or in other cases, perhaps products of technical limitations which have been resolved for sometimes up to a decade now.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post
    The rudimentary script which would be created to create tint material geometry for static meshes would hardly work for simulated fluid caches. Anyone with any DCC familiarity would know that. So it would require some elaborate monstrosity which would cover also a case of animated mesh with dynamic topology. Those are usually heavy so it's also hardly something you want to be playing back and keeping in memory twice.
    No. I've done it on multiple occasions and it works fine. Let me know if my posting a video would change your mind.

    Originally posted by Rawalanche View Post
    I think the main disagreement we have is that you underestimate the importance of having a complete basic PBR shading model. Sure there are many more issues that need to be tackled, but it's really hard to even build on a broken base. In production environments, it's just very difficult to employ any kind of shading model which does not cover even as common use case as a tinted translucency/refraction.

    I've been working as offline 3D generalist for about 11 years now, so I'd say I have a good basis for comparison, and quiet a few of my colleagues have tinkered with realtime workflows too, but the consensus is pretty much the same - the main issue being simple stuff requiring ridiculous, time expensive workarounds to achieve. I've eventually managed to bite the bullet, and transitioned career into something you could call UE4 technical artist, but most of my colleagues just were not wanting to put up with that. Even I, myself am still spending way more time in UE to ultimately achieve inferior quality, but hey, it pays better
    See, this is what I mean about not communicating. You still seem to be responding to a claim that I have noted from the beginning that I am not actually making. You will find no disagreement from me that there are many caveats associated with using Unreal as a substitute for an offline renderer. Yes, doing this absolutely requires weird workarounds, hacky solutions, and approximations. If I thought otherwise, I promise I would have said so earlier.

    In fact, I have been and am saying something very near to the opposite of that: that there are so many obstacles to using Unreal as a complete replacement for an unbiased path tracer, many of which cannot be surmounted even with workarounds, that the fact that there is a usable solution at all to the particular problem of tinted glass means it's probably not at the top of the list of things that need to be addressed.

    Even more specifically, I was merely pointing out that several of the particular claims you made regarding the approach linked to by MostHost LA were factually inaccurate.

    Leave a comment:


  • replied
    Originally posted by amoser View Post
    Why would it fail in those cases? I don't see why the approach of duplicating geometry would not be applicable either to a baked geometry cache or a live simulation.
    The rudimentary script which would be created to create tint material geometry for static meshes would hardly work for simulated fluid caches. Anyone with any DCC familiarity would know that. So it would require some elaborate monstrosity which would cover also a case of animated mesh with dynamic topology. Those are usually heavy so it's also hardly something you want to be playing back and keeping in memory twice.

    I think the main disagreement we have is that you underestimate the importance of having a complete basic PBR shading model. Sure there are many more issues that need to be tackled, but it's really hard to even build on a broken base. In production environments, it's just very difficult to employ any kind of shading model which does not cover even as common use case as a tinted translucency/refraction.

    Originally posted by amoser View Post
    I'm just not sure I agree that this tinted glass thing is a prime example of why real time renderers haven't displaced offline renderers. I think there are plenty of other more pressing limitations involved, to say nothing of the fact that studios tend to have a lot of custom infrastructure built around specific offline renderers that would need to be mostly thrown out and re-created in order to support using Unreal instead. There are also plenty of non-technical challenges, such as training and familiarity, that make it challenging to completely replace a widely-used offline renderer with a real time renderer that most people aren't yet accustomed to.
    I've been working as offline 3D generalist for about 11 years now, so I'd say I have a good basis for comparison, and quiet a few of my colleagues have tinkered with realtime workflows too, but the consensus is pretty much the same - the main issue being simple stuff requiring ridiculous, time expensive workarounds to achieve. I've eventually managed to bite the bullet, and transitioned career into something you could call UE4 technical artist, but most of my colleagues just were not wanting to put up with that. Even I, myself am still spending way more time in UE to ultimately achieve inferior quality, but hey, it pays better
    Last edited by Rawalanche; 10-14-2019, 02:00 AM.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post
    I would not. Since the usefulness of ray tracing currently lies mainly in the visualization market, to which Epic is trying to rapidly expand, given the recent developments as well as some items on the 4.24 roadmap, sooner or later more and more people will get bitter about the inability to raytrace any kind of colored glass, especially in the visualization market.
    I'm not sure we're even really disagreeing about most of this, but it remains my opinion that for translucency in general, including the specific case of raytracing glass, there are other issues that are more significant than this one. I think that those issues should, and probably will, be addressed first.

    Originally posted by Rawalanche View Post
    You also keep mentioning script to automatize those tasks. Despite the fact it will still fail in many cases (fluid simulation of pouring wine for example) (...)
    Why would it fail in those cases? I don't see why the approach of duplicating geometry would not be applicable either to a baked geometry cache or a live simulation.

    Originally posted by Rawalanche View Post
    (...) it's still a bad solution. It adds tons of workflow overhead which needs to be constantly managed and manually reviewed to cover corner cases. It's just not possible to employ overcomplicated and fragile solutions in production environments.
    Keeping in mind the fact that all production environments are not necessarily created equal, I personally do not find the thought of using some custom logic to prepare data for migration from one piece of software to another to be particularly alarming. In fact, in my own experience, it's nearly ubiquitous. Again, note that I'm not saying that it's desirable, just that it's not only possible, but often necessary in practice.

    Originally posted by Rawalanche View Post
    I mean look at how they were using The Mill human race car demo to sell all the great aspects of the realtime rendering to the public. How everything is suddenly interactive, and realtime, and cool, yet The Mill continues using offline rendering for vast majority of their jobs. It's the overcomplicated, convoluted solutions this tinted glass thing is a prime example of, which are the reason it just doesn't pay off, despite all the realtime benefits. The artists' work time overhead on engineering and performing tons of unnecessary workarounds is way more expensive than bunch of machines just crunching frames using offline renderers.
    I'm just not sure I agree that this tinted glass thing is a prime example of why real time renderers haven't displaced offline renderers. I think there are plenty of other more pressing limitations involved, to say nothing of the fact that studios tend to have a lot of custom infrastructure built around specific offline renderers that would need to be mostly thrown out and re-created in order to support using Unreal instead. There are also plenty of non-technical challenges, such as training and familiarity, that make it challenging to completely replace a widely-used offline renderer with a real time renderer that most people aren't yet accustomed to.

    We're saying lots of words at each other, but I'm not sure we're actually communicating about anything. I'm sure Epic's developers will be able to formulate an opinion on which limitations, bugs, and missing features should be addressed first without either of our input.

    Leave a comment:


  • replied
    I am also the opinion that tinted glass is quite complicated to setup right now, plus that the method you can use are either not working with Emissive behind it or not working with Raytracing. Also you need to do some hand work of duplicating Geometry, explained in the HumanRace paper.
    There are only workarounds for tinted glass right now, not a real solution.

    Leave a comment:


  • replied
    Originally posted by amoser View Post
    Like I said, I'd simply be surprised if Epic decided to prioritize this particular issue over any others.
    I would not. Since the usefulness of ray tracing currently lies mainly in the visualization market, to which Epic is trying to rapidly expand, given the recent developments as well as some items on the 4.24 roadmap, sooner or later more and more people will get bitter about the inability to raytrace any kind of colored glass, especially in the visualization market.

    You also keep mentioning script to automatize those tasks. Despite the fact it will still fail in many cases (fluid simulation of pouring wine for example), it's still a bad solution. It adds tons of workflow overhead which needs to be constantly managed and manually reviewed to cover corner cases. It's just not possible to employ overcomplicated and fragile solutions in production environments.

    I mean look at how they were using The Mill human race car demo to sell all the great aspects of the realtime rendering to the public. How everything is suddenly interactive, and realtime, and cool, yet The Mill continues using offline rendering for vast majority of their jobs. It's the overcomplicated, convoluted solutions this tinted glass thing is a prime example of, which are the reason it just doesn't pay off, despite all the realtime benefits. The artists' work time overhead on engineering and performing tons of unnecessary workarounds is way more expensive than bunch of machines just crunching frames using offline renderers.
    Last edited by Rawalanche; 10-12-2019, 04:31 AM.

    Leave a comment:


  • replied
    Originally posted by Rawalanche View Post

    Do I really, seriously need to explain why creating unique, separate complex geometry with two separate materials is a worse solution than adhering to the PBR standard where base color defines transmission color for transmissive materials?

    https://youtu.be/DO7zkJRWNgs

    I do get that not everyone needs to be effective at what they do, but I do. I can't afford to spend exceptional amounts of time to achieve mediocre things.
    I don't think you understood my post. I did not that there aren't better ways it could work. In fact, I said the opposite. I did say that I feel you're exaggerating the degree of inconvenience present in the current way of doing it, and I still believe that. The current workflow is not as bad as how you present it.

    1. Get back to your DCC, assuming you are lucky enough it's your model and not a bought/received asset
    2. Spend time selecting all the window geometry
    3. Duplicate it
    4. Offset it
    5. Assign it new material ID
    6. Spend time selecting all the tail light geometry
    7. Duplicate it
    8. Offset it
    Like I said, if the window and tail lights already have separate materials on them, this can easily be scripted in any modeling package so that it can be done with a single button click. Sure, that requires work, but if it's something you're going to be doing regularly enough that doing it by hand is genuinely unacceptable, it seems like the benefit of making a script is more than worth it.

    9. Spend more time dealing with the mesh self intersections induced by offseting mesh of complex curvature along the face normals
    10. Assign it a new material ID
    11. Bring the asset back
    12. Notice you are no longer able to take advantage of automatic LOD generation as decimation of 2 thinly neighbouring surface is imperfect so tint layer sometimes clips into the glass layer
    Like I also said, if self-intersections between the translucent geometry causes a problem, use the camera offset node on one of the layer materials instead of actually including the offset in the geometry. Confirm that self-intersections are even a problem first, though, since I've never run into that in this situation, and I don't think you will either given how depth sorting works with translucency.

    13. Create glass material by creating Lit Translucency material
    14. Create green tint material by creating green modulate material
    15. Create red tint material by creating red modulate material
    16. Assign glass material to glass pieces
    17. Assign red tint material to inner tail light layer
    18. Assign green tint material to inner window layer
    Again, this is pretty easy to script if you know this is something you'll need to do more than once.

    I can't comprehend what's in it for you to defend clearly inferior and ineffective workflow. Why would you advocate for not improving the engine? There is absolutely no benefit in treating one, solid glass medium as two separate objects. It has tons of downsides and corner case issues with literally 0 benefits.
    I believe I addressed this very clearly and specifically in my previous post, but I'll try one more time:

    I'm not saying this workflow isn't inferior to one in an ideal world in which this is handled without the user expending any effort. I am saying that there are plenty of other things, even specifically related to translucency, that are significantly more challenging, or even impossible, to achieve with the current tools. "Improving the engine," unfortunately, isn't a binary proposition. Improving anything necessitates making a choice about what, specifically to improve.

    Personally, I'd rather see attention given to things that can't be done at all than things that can already be done, even if the way to do them is fairly awkward. I'm not even trying to give an opinion or make a value judgement here, though. Like I said, I'd simply be surprised if Epic decided to prioritize this particular issue over any others.

    Leave a comment:


  • replied
    Originally posted by NotSoAccurateNo1 View Post
    what's wrong with doing it this way
    https://youtu.be/XRwFh6s5wqE
    1. Does not work with ray tracing
    2. Does ignore any translucent objects behind

    Leave a comment:

Working...
X