A Unity ID allows you to buy and/or subscribe to Unity products and services, shop in the Asset Store and participate
in the Unity community.
Discussion in 'Assets and Asset Store' started by jimmikaelkael, Feb 21, 2016.
I'll probably do that soon
Ok, my issue was solved! The product looks great by the way, rating 5 stars in a sec
Any chance for this to work on VR with Stereo-Pass Single Render? I'm testing this using an Oculus DK2.
I see everything pretty strange... but also I get a lot of errors like this:
Could you please send me your invoice number in PM ?
I'll try to send you a fixed build asap.
VR single pass isn't implemented yet but it's on the road for the next release.
@jimmikaelkael - We're experiencing issues with faint black lines that occur when using half or quarter resolution settings. For reference, we're seeing those lines within VR - those same lines don't seem to show up in the game view.
Do you have any initial thoughts on how we could address this?
Hmmm, on top of my head I can't see what could be the problem, most likely It requires investigations.
Which per pixel normals type are you using ? (Please check when it's in play mode as it can change at runtime if the setting isn't available for the current rendering type).
Does it work with VR (Rift/Oculus)?
Yes, but the current release doesn't support Single Pass Stereo Rendering, I'm currently in the process of implementing it.
In any case, you can always try the free trial package.
These are my settings during play mode. You can clearly see faint horizontal lines on the Vive... let me know if I have an incorrect setting
Are you using Single Pass Stereo Rendering ? HBAO is not yet ready for that...
You could try to set the blur amount the "None". If it still persist, try to set Per Pixel Normals to "Reconstruct", and if you still get the black lines set Resolution to "Full". Let me know at which of these steps you get a normal output.
It looks like setting per pixel normals to "reconstruct" did the trick. Looks like there's an issue on any resolutions lower than "full" when the normals are either set to Camera or G Buffer.
Thanks for your help!
Ok, can I know a bit more about your setup ?
- VR device
- Unity version
- DirectX version
Thank you very much!
- VR device: HTC Vive
- Unity version: 5.4.0f3
- DirectX version: 12
Sorry for the late confirmation, but yes it works with SteamVR and also The Lab Renderer.
The Lab Renderer vr_standard shader requires a modification so that it can write to Z-Buffer but I can provide it on demand
Just tried it and working perfectly with a perspective camera, however when I switch to orthographic I haven't been able to get it working correctly with all the settings I've tried. Would it be possible to share a demo of it working with an orthographic camera?
Are you sure you are using the latest 1.7 update ?
Theoretically it should work out of the box with orthographic cameras.
The best test to try is the HBAO demo scene, activate the AO only view and switch the camera to orthographic.
Yep absolutely, freshly downloaded and just checked the readme - says 1.7.
So I open up the demo scene, select the camera and switch to orthographic, then I switch to AO only and this is the result;
When switching back to perspective it's working fine. Using Unity 5.5.0b4
Unity betas are not supported, have you tried with the latest stable release ?
Which platform are you building for ?
The trial version of you tools works very well with Unity B7. I'm currently evaluating your product on a (real) open world. Everything are fine.
Ah you're absolutely right, just tried the latest stable version and it's working correctly there. Had no idea there would be such a problem using the latest beta releases. Thanks for the support!
Glad it's working
Anyway thank you for your report as I'm now aware of an eventual future problem.
I've tried to reproduce it and YES there's definitely a problem regarding HBAO with orthographic camera in Unity 5.5 betas.
I've checked Unity's cinematic effects package and it suffer the exact same bug so I'm watching this carefully.
We have a strange issue. In editor everything looks fine, but in a build it seems the AO is inverted. Instead of darker areas, we get light areas. Is there some strange setting I've missed? Running: Unity 5.4.2f2, DX11, deferred, linear.
That's strange yeah... I'm unable to reproduce it.
Is it possible for you to send me a repro case ?
EDIT: Do you have color bleeding enabled or not ?
I've spent some time to try and make a repro case but I couldn't outside of the project (Sadly I can't send you the whole project...). However, I did (sort of) figure out the problem:
The build should run in deferred rendering (though log says "player settings"). HBAO doesn't seem to recognise this, so it automatically changes Per Pixel Normals to "Camera" instead of the default "G buffer". When the rendering mode is then forced to deferred, Per Pixel Normals doesn't change and is still "camera".
So right now the workaround is this:
1. launch a build with HBAO disabled
2. Ingame, switch/force it to run in deferred (instead of "player settings")
3. Enable HBAO
4. Everything is fine!
The odd thing is that I'm pretty sure it is actually running in deferred in the build, because it's clearly not running in forward as that gives all kinds of issues with our shaders.
Could it be that HBAO doesn't recognise whatever is set in "player settings" as deferred? Though in that case it should also cause issues in other scenes/projects, right..?
Another odd thing is that this problem didn't occur in earlier builds, so something in our project must've changed. I'll have to do some more investigation on monday and our other programmer is back in the office.
Edit: Color bleeding is disabled, everything is on the default settings. I've also deleted and re-imported the whole package. No difference.
Thank you for feedback.
Well such rendering path detection was a problem in earlier versions but it has been fixed some time ago.
Clearly I'm missing something... I've never seen Unity saying it uses "Player Setting" as rendering path in builds.
Wasn't it in the editor ?
In HBAO.cs (line 767), there's a method that is responsible for detecting the rendering path, you can clearly see there's a special treatment for "Player Setting" in editor but not in build:
private bool isDeferredShading()
return (!_hbaoCamera.orthographic && (_hbaoCamera.renderingPath == RenderingPath.DeferredShading ||
(_hbaoCamera.renderingPath == RenderingPath.UsePlayerSettings && UnityEditor.PlayerSettings.renderingPath == RenderingPath.DeferredShading)));
return (!_hbaoCamera.orthographic && (_hbaoCamera.renderingPath == RenderingPath.DeferredShading));
Are you instanciating the camera or something else specific with your setup ?
Sorry, I was mistaken, that was indeed in editor.
In the build it refuses to print
Debug.Log("Cam Path: "+Camera.main.renderingPath);
So I'm not sure what it does...
Only after I set a path will it print:
We do re-parent the cam as soon as the player spawns. Right now this happens immediately on starting the game, so I suppose that could be an issue..? As soon as we have a menu, etc. there will be some time between starting the game and stuff happening to the camera.
Strange, it prints nothing ? not even an exception ?
Have you tried enabling debugging in build ?
If you are reparenting the whole gameobject I don't see why this could be a problem...
Well I've found a major problem: Unity exposes the UsePlayerSetting in builds and HBAO is unable to detect the correct rendering path in some cases...
This explains your problem @P4p3Rc1iP
Working on a fix right now!
EDIT: Well, as a temp fix you can change the "isDeferredShading" method in HBAO.cs to
private bool isDeferredShading()
return _hbaoCamera.actualRenderingPath == RenderingPath.DeferredShading;
I'm submitting 1.8 update for review.
Ah yes, that explains! Thanks!
We are using your HBAO for our game Vaporum and one issue occurred, we see some kind thin semi transparent lines on screen, we have in most of the game camera in horizontal position. It weird because before I didn't see this.
We using Unity 5.4.0f3 ans Alloy Shaders. Inside editor is this issue less visible then in the build. We also use SSAA and this issue will lost after setup SSAA to 1.2x resolution or more.
In the link you will find video with issue and screenshot of settings (per pixel normals in video are setup on GBuffer) with our settings.
Also I try switch Per Pixel Normals from g-Buffer to Reconstruct and that fix the problem but it will wipe out AO from normals maps.
Thanks for your help.
HBAO has been updated today, could you please check with the latest version and report if the issue is still there ?
Is there a way to add Ambient Occlusion to transparent objects? I have an application which takes camera input and overlays a 3D model. The model has no AO at it's base. It would be great to just add a transparent plane on the ground and add a special shader that allow AO to be applied.
Is it possible for you to send me a small test project ?
Small comparative Screens of the HBAO, you Rock !!!
I have tested far away mostly all the ambient occlusion in the Asset Store, then I made definitely my choice here.
The variants of Settings and how is easy to set up make a big difference for me, moreover the Results, the smoothly Perfs in it are just the best I obtained with an AO in Unity.
Hardly tweaked closely, I show off on screens some transitions closer and widely too^^ These are obviously my own sets, you can so easily tweak the HBAO in your own way...I'm so amazed of this!
I guess it's enough^^
Hi I bought this package and am generally pretty happy with it but I was wondering if for a future release you could add a slider that controls how much directly lit areas of the scene mask away the ao ( they currently dont do that at all.)
Yeah I already have a beta release ready to support this. It integrates into the rendering pipeline and does PBR lit AO, I'm contacting you by PM.
Is there any ETA for release?
Not really... However it should be released in the coming weeks, before christmas.
sweet tried the beta works as advertised
Can we get the beta please? We need to utilize the fix env_warby mentioned.
Please send me your invoice number in a private conversation, I'll send you that build asap
I have a little problem that may be a bit hard to notice here, but please have a look:
The pillars in front are influencing the AO on the stairs behind them.
It looks a bit like the pillars are "glowing".
Well you'll get a bit of that effect (haloing) in almost every SSAO solution, but in your case it's surely exagerated... And shouldn't be.
Hard to say just like that... Is your object scale correct ?
Which Unity version, which platform ?
Deferred, Forward rendering ?
If you can strip it down into a test project I could look at it.
As you can see the radius is very big.
As soon as I reduce the radius it gets much better, but I would still like to have this big radius.
Is your object scaled correctly ?
If you're increasing radius, you could try to increase the "max radius pixels" setting as well.
Let me know if it has some effect.
EDIT: What's your radius currently ?
Are you using Deinterleaving ?
Unity 5.5.0p3 Pro
I started noticing the following issue when updating to Unity 5.5. Please see below for the screenshots.
In the first screenshot, with HBAO enabled, I can see through walls. Two characters standing can bee seen through the wall.
The 2nd screenshot is when I disabled HBAO, which then makes the wall look normal again.
I have noticed some walls and trees having this see-through issue. This seems to happen when the "per Pixel Normals" is set to "G Buffer". When I set it to "Camera" or "Reconstruct", the see-through issue does not happen.
I am using Deferred Rendering Path
Maybe, is there a setting that I am overlooking?
HBAO is enabled
HBAO is disabled
Seems to have to do with your material not writing to depth buffer.
If you set the wall materials to Default I guess you will not get this see through issue.
Your solution does work, but for the leaf material of the trees that were being used, it will look a little different.
I was able to change the affected see-through walls and trees to utilize the Standard shader to make it work. But, for the shader used on the leaves of tree, the Standard shader will make it look slightly different due to the differences in shader rendering, but it is acceptable.
Here are the shaders causing the see-through effect, of which, I had to change to use the Standard shader.
Shader used on the wall material
Shader used on the leaf material of the trees
Thank you so much for your quick reply!
Well, I suggested to switch material or shader just as a test to confirm the issue was related to your materials, but I can understand that's not what you want to use at the end.
For the "Probuilder/Standard Vertex Color" shader I think this is expected as this is not really a production shader I guess but rather a tool to during development. That said I can help you to fix this shader to work with HBAO if you really want it to.
For the "Tree Creator Leaves Optimized" shader this sounds really strange as I've already used some Trees with this shader and they don't have any problem (I tested it again this morning with Unity 5.5.0f3). Which asset are your trees from, could you send me a link please ?
The tree prefab name is "Spruce_1" from the following asset:
Stylized Nature Pack
Below is a screenshot close-up of the tree leaves. Circled in red, a brick wall can be seen through it as if there was some kind of transparency or x-ray like effect.
I am using the latest Unity 5.5.0p3, it's the patch 3 version, and not the f3, if that makes any difference or not.