Posts by Clemens Musterle

    Its a real pain to get rid of unless making the glass completely transparent.

    But that's exactly how a regular glass material should be setup ;) Unless it's some special kind of (frosted) glass opacity should be set to 0% for realistic results (and refractive index should be ~1.5).

    As you can see I have outlines set at '0' yet the resulting image still has outlines, I cannot remove them.

    We could reproduce the issue, sorry for the inconvenience. You can work around the issue by resetting the settings tab using the button on the bottom.

    Do you have automatic resolution enabled? This setting scales down the rendering resolution, when Enscape is unable to maintain a fluid framerate, which could be the case if scene complexity is too high. You can disable it on the general settings page.

    now waiting for preview version to try that better shadows

    Sorry to disappoint, but RTX based ray traced shadows are currently not in development. That's a feature that might come some time in the future, but RTX integration right now is basically a replacement for our existing path tracing implementation that does reflections and indirect lighting, but with better quality.

    Hi benjaminriendeau


    can you please provide us with a Sketchup project, where we can reproduce the issue? That's something that should definitely work. Based on the screenshot I actually don't think it's connected to the glass material, as you can see other textures on the wall behind the glasses.


    Thanks!

    Are there any findings when it comes to RTX and performance? Is there as much of an impact to performance as when it comes to other applications such as games?

    Up to now in games RTX features are often additional quality enhancements (better reflections, shadows, or AO) and therefore come with the price of additional performance cost (which however usually isn't a huge issue as the RTX cards offer quite substantial performance increase to previous generation cards).


    Right now we expect our RTX implementation to deliver about the same performance, however with increased quality of our existing path tracing functionality. That means for example more geometry visible in reflections and improved quality of indirect lighting. RTX exclusive features are not planned yet, but I can't exclude that something a long that line could come up in the future.


    As you can see from the benchmarks the RTX features might run on the Pascal generation cards, but performance is signficantly lower. We can't tell you numbers yet, but I expect there won't be much difference when running RTX powered ray tracing on these cards compared to our already existing ray tracing implementation.

    Hi coreym and welcome to our forums!


    We've indeed had similar reports - in most cases this was due to an unfortunate default setting in SteamVR that sets the rendering resolution to 200% for high performance gpus, please see this page in our knowledge base for more details:

    https://enscape3d.com/knowledg…ual-reality-headset/#vive


    Other than that it's still not unlikely, that the performance on Ultra quality doesn't reach a completely smooth level in VR depending on the scene complexity, as it involves very demanding lighting calculations, which are usually not done in VR applications in real-time. We still think it's a useful feature in some scenarios, for example to get a better impression of the overall lighting mood in a scene, when there's not necessarily a lot of (fast) movement involved.


    Hope that helps! :)

    I Think that Clemens is right, before the normal map was interpreted as a basic bump map, and "turned" it into greyscale in order to make it work... that means you was not adjusting the normal map, but only the greyscale version of it :-) in other words, you were missing all the great stuff that makes a normal map better than a bump map :-)

    Yes, this is correct. If you previously used a normal map in the bump map slot it was simply not interpreted as a normal map, but as a (brightness based) bump/height map. The result might still give a similar impression, but it's definitely not working as the normalmap was intended.

    So we did not remove a feature, but improved the interface, to actually support selecting normalmaps (without naming based workarounds).



    the way normal maps works is quite different from bump maps, and they are not meant to be adjusted, as all the height information is stored in the very specific RGB colors of the texture... In a normal map not only height is stored, but also the direction of each pixel, which is why they are quite superior to bump maps


    So having a slider for adjusting normal maps was very misleading

    While this is true, you can in fact do something similar to an "intensity" post processing on a normal map, which could make material fine tuning easier (you wouldn't have to rexport your normal map several times just for intensity tweaks). ;)