hi, I’ve been working on sun (s) /moon(s) and stars for a game i’m making. I found the skymaterial and while it has all the bells and whistles i could ever want it doesn’t seem to obey the transparencyMode setting (example here from the documentation Babylon.js Playground ) . Am I missing something or is there no way to do this? (is it even a pbr material? it has the appropriate methods and properties in the documentation SkyMaterial - Babylon.js Documentation .
I threw together a mock up so you can see what i’m talking about first hand. Sorry its not a star field behind the sunset. just the stock cloud skybox. but the point still is demonstrated. https://www.babylonjs-playground.com/#4R1H1U#12
Basically, i’m trying to make it so when it gets dark enough stars peek through. I can line up the actual sun (circular texture on a square plane) with the skymaterial’s sun location and make it work . but when it goes down i want those stars to peek through. The other nearby stars (in the system, if any) may have some form of their own skymaterial or just be like a really bright star in the star field. the moons basically behave like an orbiting texture which i can put in front the skymaterial so that one seems at least okay. but i need that starfield to peek through
@James_Scheibel I ran into the same issue. The way I solved it was to put the starfield (celestial sphere) in front of the sky material and adjust its opacity based on time of day. Same for sun and moon disks - in front. Dynamic cloud layer between celestial sphere and central observer. Works a treat for my use case. Sorry I can’t share the code.
I toyed with the idea of doing it all in a shader but 1) it’s beyond me, and 2) a layered approach gives me more control for compositing different elements.
thanks for sharing. you can set the alpha layer on the skymaterial (i actually have that code comment out in the example) and let the stars through if ya like in the same manner ecept making the sky material as a whole is see through instead of the stars. i’m guessing its an identical effect since in either cas you get stars showing up. but i tried that and it looks kinda meh unless you wait till tis more or less black and blue.
It might be possible to mess with the source code and rebuild it so that instead of black being black, black is an alpha channel (as well as black) but honestly i havent even started messing with it. I’ll probably look in to that if this doesnt work out/no one has a way to make it happen.
nice clouds btw thats next on my list of things to do. well that and working textures for my moons.
I think I tried that way myself. IIRC it’s really at twilight, sunrise and sunset when there’s that glow gradient preceding the sun disk. Sure you might be able to change black to alpha in the shader and it might work but this was simpler. I’m setting time of day and thereby sun & moon position from my script, so can fade starfield in and out seamlessly during that twilight phase.
I started with a simple textured plane for the moon but then getting the moon phase correct was a nightmare so opted for a sphere correctly illuminated by distant “sun” light.
Animated clouds are a custom variant of a shader I found on shadertoy.com
Note that the sky material supports vertex color, so you can use those with your alpha values and set mesh.useVertexColors = mesh.hasVertexAlpha = true.
well. i thought i had a working “good enough” solution by making the various skybox layers see-through via one method or another … but now odd things are happening.
so if i overlay things in the sky (moons) they work okay as long as i dont use an opacity texture. but as soon as i do, the whole moon (s) becomes semi transparent… even though the opacity image has 255 alpha through most of it (opaque).
this is really really strange. i’ve spent multiple days now trying to figure out what is going on (ex:rearranging layers so the skybox is in front of the sunset shader… trying to different alphamodes so they combine differntly … trying different lighting textures etc…). all i can figure is once a mesh gets flagged as having an alpha opacity texture and there are alpha-halving textures behind it, they get merged. even if that part of the texture is not see through . this doesnt happen if i use an alpha cutoff. but then of course it looks jagged as there is no anti-aliasing that way.
i tried using glow as an alternative since i could use an opaque image and light it up with that to get a nice effect (skirting the anti alias edge) but glow apparently wants to know about all meshes in the environment so it can mask the not-glow ones correctly. as i load/unload meshes a lot. it seemed like overkill in a huge way to try and use glow (for moons) as the overhead would be horrendous.
anyway if anyone has run in to this or has a good solution i’d love to hear it. i might try putting a slightly smaller opaque moon behind the see through one just… that would probably work. at least the stars wouldnt show through the moon and the edge would look nice. its a total hack but if no one knows of another idea i guess i’ll do that.(or just leave it looking like bleh)
I recall I had to use rendering groups and there are some situations where I also had to make “opaque” objects just very slightly transparent to force the blending I was after.
@Evgeni_Popov and @Deltakosh I was hoping the answer would be “it’s a known bug” as making a reproduction would take some time but i guess here we go… (see below)
@inteja I did look into it, but other than setting an index to 1 once to see the effect (there was none) i didnt pursue it.
so i finally sat down and remade the problem in the playground… except it of course doesnt do it there.
I thought maybe my libraries were out of date. so i got the latest stable version. (clearly changing something as my keysUpward and keysdownward no longer works heh)
so what do i see? here’s a screen shot (this is an alien procedurally generated world there are multiple moons/suns.)
since it does work in the playground. i can only assume there is either some code somewhere messing it up. or there is a difference in libraries or something about the number of meshes i’ve loaded or order i loaded them in is causing a problem. i’ll try stripping down my game to be exactly like the playground and start readding things in.
okay, i switched back to using material alpha. did a fresh load after adjusted the zorder (actually bring the sky material closer to the moons to be in line with my sample) and the problem has gone away. … so yay?
I’m not complaining. 2 days of working on the same problem teaches a person to just be happy its fixed even if its not clear why. (i did, as you can imagine learn way more than i ever cared to about transparencies.)
but i figured as many people who have seen this now. i’d try and reproduce the original issue. so i went and adjusted the distance of the skyboxes and set the visibility more closely to my code and huzzah. i reproduced it in the playground.
needless to say, since i have a way to make it work i’ll do that. if someone wants to investigate this or knows why this is happening. i’m all ears. but for now i’m good to move forward.
I dont know when i decided to overlap the the skyboxes but i think that has something to do with the bug (maybe the shader is doing strange things?), clearly once overlapped i never undid it.
suffice to say, i’ll leave the starfield 100% visible in my code and in the distance (not on top of the skymaterial) and just adjust the alpha of the sky material… that will make it work right.
edit more playing with it makes it clear, the second you set the skybox/starfield to have an alpha things break.
@James_Scheibel I suspect (but don’t know for sure) that the issue is floating point precision related. Your sizes are quite large i.e skybox = 17000 and cam.maxZ = 21000. I generally try to keep objects as close to the observer as possible, and the range between cam.minZ and maxZ as small as possible, whilst still maintaining the illusion of “infinite” distance. With a sky/starfield this is easy enough to do, as the skybox can move with the observer, or observer and skybox remain stationary while other scene objects move relative.
Anyway, not sure that’s what’s going on in your case, but it wouldn’t surprise me.
i appreciate the suggestion. in the sample i just knocked 2 digits off the scale of things (21000 -> 210 17000 -> 170 etc…etc…etc) and it still happens. https://playground.babylonjs.com/#S0P31H#2
I also noticed that once the moon is see through there are weird interactions with the sky’s shader.
I think i’m just going to have to stick to crappy looking hard edge suns and moons for now (with no anti-aliasing edges). or abandon the sky material as it causes so many problems despite how good it looks. though i’m not entirely sure that will fix anything in the long run. i might try something where i put a 2nd copy of the moon right in-front of the first and let the 2nd moon be see through. maybe i can fake a nice edge. or maybe i could use a spot-light pointed at the moon and the glow would make it look okay. i dunno. i’ve spent sooooooooo much time on the sky and i originally thought it would be a like a 3 day thing (coming up on 2 weeks now heh) its a musing to think all this time for something that will be largely ignored.
as for distance, I’ve learned the hard way that i do need to keep things as small as possible or the camera/render jumps meshes around when close to a mesh. scaling numbers down when everything is procedural isn’t too much of a problem. but it doesnt fix this =/ (and i will be to some extent i expect later, all my work has been in my test environment. the actual game needs to be able to let a guys run close to the ground without it looking “bleh” when you zoom in). i already have code that recenters all meshes on 0 if the user climbs a mountain more than 250 away in height. … code like that is kinda silly but hey, i get it.
edit yeah 2nd moon trick doesn’t work right thanks to the sky shader =( … behold my haloed moons.
Not sure it has much to do with SkyMaterial though as wouldn’t any skybox texture be the same if applied in the same way?
I initially tried a simple mapped plane for the moon and recall I ran into similar alpha blend and mask issues, but the bigger problem for me was getting accurate lighting on the moon i.e. moon phases, while still occluding the stars behind the “dark side” of the moon and having the “dark side” match the sky color directly behind in twilight or daylight. The only way I could do that was with a sphere for the moon rather than a mapped plane.
the skymaterial’s shader is interacting with anything that has an active alpha channel in the same space. i think this is how they make the neat sunrise. it adds a bunch of verticies and the shader just shades them… its just the shader isnt smart enough to know what it should be shading.
as for my opaque texture issue. that really feels like a bug, but i bet it stems from that shader (again). something to do with it thinking a material with a opaque texture on it needs to be handled by it… and it makes it more see through than it should be. why it requires the sky behind it to have an alpha level too? i dunno. i didnt write the shader. i’m going to set this aside for now unless someone chimes in with a solution. eventually i’ll probably write my own mechanism to do sunsets. (probably layer a meshes in the sky and just color them using them color3 based on the time of day. it wont look quite as nice but all my problems will go away.
you mentioned phases of the moon. i’m probably going to skip that for now. in fact that’ll probably be when i readdress this again. (which means probably in 5-6 months)
… its just a time sink right now and i need to move on to other parts of my project. if it turns out that things on the ground have “sky issues”. i might revist this sooner than later. but again. my solution will probably be super unfancy for now.
i got convinced this was a bug and submitted a super simple example. it was not… just maybe not working as you might expect. it turned out that i needed to bump the skybox alphaindex (not the moons) down. once i did this things started getting processed correctly.
thats next on my list of things to do. well that and working textures for my moons.
