Closed Bauxitedev closed 6 years ago
ViewportTexture seems to be broken in general. If you apply a material to the sphere and set the Albedo-Texture to the ViewportTexture the texture will show in the editor perfectly, but it will show black in-game and it will show as black if you close and re-open the scene.
Related to #7998
Note that you must check "Local To Scene" for all resources containing a local to scene resource, such as the viewport texture. (So, that would mean setting the Environment as local to scene and the PanoramaSky too, as well as the SpatialMaterial in @ShyRed's example)
Unfortunatelly, even after I did that to the example project, the sky continued to be black. On the other hand, setting the material as "local to scene" made the viewport texture appear on the sphere in-game as well.
Not having any luck with this either, also not when assigning the viewport texture through code
This could be made to work, but roughness maps would be generated statically, and not updated in real time.
Replace the following line:
With:
if (tex->proxy && tex->proxy->tex_id)
glBindTexture(tex->target, tex->proxy->tex_id);
else
glBindTexture(tex->target, tex->tex_id);
and stuff starts working, if you set up the viewport and reference it in the sky:
https://i.imgur.com/B2HjEFk.gif
It only works after messing around with the properties, though, otherwise your console is spammed with things like
scene/main/viewport.cpp:106 - Condition ' !vp ' is true. returned: Size2()
I believe the error messages are the result of the ViewportTexture being queried before it had a chance to initialize itself correctly. The above fix seems to work in editor only. Still won't work in preview.
EDIT: Just to avoid confusion: in the gif I've added the viewport's texture as a material to the sphere for debugging purposes.
Nice job, it seems to work now. For future reference, to get this to work you need to do this:
I'm still having this problem. Setting the stuff to "Local to Scene" etc. doesn't help. I also put the Viewport up in the tree with respect to the WorldEnvironment that has the PanoramaSky; doesn't help. Any new ideas?
@stur86 which build are you on? You need a recent master to use this properly and it won't work in the editor, only in runtime. You have to time things right, when the viewport texture is assigned to the sky, that is when the radiance map is rendered. If you assign it before the viewport actually has a content, you won't get reflections.
Check out my project here: https://github.com/BastiaanOlij/godot-sky-asset Note there is a branch that only works on the latest master that uses the latest fixes, the master branch still has a work around in place which is much slower.
@BastiaanOlij the Steam one, so v3.0.2.stable.official.
Also, will this be fixed better at some point? Right now, this is still a very hackish way of going around the issue.
Hey Stur86,
3.0.3 which is currently going release testing has a few enhancements, I'm not sure if the last one is being cherry picked. That should result in most of the hacks no longer being needed. I have submitted an idea for automatically updating the radiance texture when the skytexture is re-rendered but whether that will be picked up or whether I will find time to do it myself, I don't know.
In the end I don't mind forcing people to do one extra step because it is far to easy to start rendering the sky texture every frame and then wondering why you're framerate suffers. There is a price to pay for full PBR support with proper reflections of the full skymap instead of only rendering a plane in front of the camera.
What if I don't want all the lighting stuff then? Can I just have a procedural panorama sky created with a shader but that doesn't produce any lighting, as that's provided by the usual environmental/directional light sources?
Easiest way for that would be to just turn the background black so it no longer plays a role in the lighting code, then just render a quad that is a child object of your camera appropriately sized and at your far distance and apply the shader to that.
While the directional lighting does provide your normal lighting you miss out on all the stuff that makes PBR look so realistic as you won't have your sky reflected in metallic materials.
Personally I plan to render just the rayleight mie scattered sky as I do right now as that doesn't need to be updated every frame, then use a raymarching shader on a plane to render animated clouds. I won't get the clouds reflected or possibly do something with a reflection probes but it is asking alot of the GPU.
I'm looking for a space-like environment so I don't care much for reflection at the moment. It's not going to look realistic but I'm going for an abstract effect anyway so yeah. Thanks!
@BastiaanOlij: I wish I could get my clouds (inverted sphere) to be exactly at the far distance and not culled. Custom AABB is a pain.
@Zireael07 yes it is a bit tricky because you never render a perfect sphere, you're still rendering triangles with the worst bit of floating point precision at the outer bounds. I don't have any culling issues though.
This needs to be reopened. I don't think it works in any of the stable releases. It only worked briefly in the master build.
Still works fine for me on todays master.
Keep in mind that the problem of having to re-apply the viewport texture to the sky to trigger creating the radiance maps still exists, but its easy to work around.
See if this works for you on the latest master: https://github.com/BastiaanOlij/godot-sky-asset/tree/use_proxy_fix
I will try it tonight. Thanks for responding.
Your sky asset worked fine for me. But that was using the expensive texture copy, not assigning the viewport directly.
Maybe I unknowingly messed up my code base such that it no longer renders correctly.
On 3.0 the texture copy is still needed (not 100% sure if the fix was cherry picked in 3.0.4), in 3.1 you do need to reassign the texture but no longer need the copy:)
On Tue, 26 Jun 2018 at 1:16 am, Clay John notifications@github.com wrote:
I will try it tonight. Thanks for responding.
Your sky asset worked fine for me. But that was using the expensive texture copy, not assigning the viewport directly.
Maybe I unknowingly messed up my code base such that it no longer renders correctly.
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/17510#issuecomment-399988329, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2vabFG6MNziepNpzb_n0l8p-7lS_1dks5uAP7UgaJpZM4Sq6zw .
-- Kindest regards,
Bastiaan Olij
https://www.facebook.com/bastiaan.olij https://twitter.com/mux213 https://www.youtube.com/channel/UCrbLJYzJjDf2p-vJC011lYw https://github.com/BastiaanOlij
Ah, that's it. The fix hasn't been cherry picked yet. It works fine in the master build. Thanks for the help.
Godot version:
Godot 3.0.2
OS/GPU: Linux GTX 1060
Issue description: If you assign a ViewportTexture as a PanoramaSky texture then the sky becomes black. It doesn't actually show whatever's inside the viewport, which is a shame because this would be extremely useful for procedural skyboxes (e.g. dynamic day/night transitions, rotating stars/nebulae, etc).
Steps to reproduce:
Also notice that if you afterwards open the WorldEnvironment node again and open the PanoramaSky, the console is being spammed with this error:
Minimal reproduction project: viewportskybug.zip