@Syncroz
Missing/having redundant "0"s in the list?
Converted skinned meshrenderer into meshrenderer already? Does the mesh stay on (0,0,0) position?
What format the eyebrow was using? (I got a crash a while ago when I was using .tga format)
That's some possible issue I can think of.
Edit: Yeah, and the CAB-string problem enimaroah mentioned. The string have to be unique, hexadecimal and same length.
For all my mods I tend to copy Illusions TextAssets and just alter the IDs/names/path. Shouldn't be missing/having redundant amount 0's in them.
I am going to check that just in case... it did look alright.
Yes, I did convert it into Meshrender, Skinned Meshrender are meant for meshes with bones connected to them... if I remember right.
The eyebrows uses DDS DXT 5 interpolated Alpha.
@enimaroah @Aastaroth CAB... CAB... I might have missed checking that one. So I'll get on to that in a bit.
argh... local. I used to make a parent transform one level upper than all the meshrenderers I have.
It makes me easier to manage the scale to fit into HS world. Does that mean if my scale (of parent transform) deviates too much, the center and extended fix isn't gonna to produce any effects?
I made several tests with the Yusha map. I used a scaling transform and the shadow bug is still there even with the hopefully corrected bounding box.
So you might have to use WorldCoordinates in your vertex positions instead of a scaler. Remember, you can export with WorldCoordinates in MQO format. But I am not completely sure if that fixes the problem. Back to the workbench.
Unfortunately it seems that the bounding box isn't going to fix my maps' shadow problems. The maps was just simply too large.
I can't really blame illusion though, because the game is not designated for a huge open map like SBPR.
The far clipping plane have to be restricted into a relatively short distance. Things just go weird when we are close to that limit.
Well, unless this can be changed, I am not placing high hopes fixing this. This bug is ugly one but not a killer for me. I can still circumvent the issue.
@enimaroah & @Aastaroth It was indeed the CAB-string that was the issue for the eyebrows, I haven't been checking the accessory mod yet, but I'll assume it's the same thing there.
I were under the assumption that SB3UGS would alter it when you saved any changes, seem I was wrong about that one... or is it supposed to?
Hey, that seems to work. Using worldcoordinates in vertex positions and using Identity matrices in Transforms produced a good result, while using a scaler made the shadow bug visible.
But I have to check other bounding boxes of original MeshRenderers. Although it seems to be unlikely I need to verify if the bounding boxes are really local.
Sorry guys, it seems I was too hasty in my conclusion :( After reading your input and doing more tests, it would appear the bug indeed remains.
My test was flawed: I was using a model that seems particulary resilient to the bug. I can't understand it at all, but it's a fact. Some hairs and clothes are affected by this way harder than others.
I managed to find an angle that showed signs of the bug even on the resilient subject in the boulevard. You can see it in picture 1. Very light tho.
Same subject in a newly modified in 1.9 DR Mall shows a greater bugged effect (picture 2)
What is baffling is that the boulevard is not only quite larger, it has shadow cast/receive activated on all meshes. In comparison, the modified Mall only has receive shadows on the inner Mall floor. The big green outfield and most of the other meshes have no shadows activated.
Picture 3 is a size comparison, but please note that the boulevard is scaled in SB3U matrix x10. In game, both are set to size 1:1:1.
Running test with a very vulnerable subject to the bug, it again shows the difference in severity.
I hope that could help. If you need the files to run tests by yourselves, I can provide.
Sorry guys, it seems I was too hasty in my conclusion :( After reading your input and doing more tests, it would appear the bug indeed remains.
My test was flawed: I was using a model that seems particulary resilient to the bug. I can't understand it at all, but it's a fact. Some hairs and clothes are affected by this way harder than others.
I managed to find an angle that showed signs of the bug even on the resilient subject in the boulevard. You can see it in picture 1. Very light tho.
Same subject in a newly modified in 1.9 DR Mall shows a greater bugged effect (picture 2)
What is baffling is that the boulevard is not only quite larger, it has shadow cast/receive activated on all meshes. In comparison, the modified Mall only has receive shadows on the inner Mall floor. The big green outfield and most of the other meshes have no shadows activated.
Picture 3 is a size comparison, but please note that the boulevard is scaled in SB3U matrix x10. In game, both are set to size 1:1:1.
Running test with a very vulnerable subject to the bug, it again shows the difference in severity.
I hope that could help. If you need the files to run tests by yourselves, I can provide.
Verified: Mesh's and submesh's Center and Extend seem local to me. Translation and rotation of several original items were like that. I couldn't find a scaled item but I am sure that scaling must be handled local too.
GIL, please try a map with a scaler, delete all meshes except one, save that version and check the bug. Then replace the mesh with the downscaled scaled version and make the scaler Identity. Check for the bug again. In my test it made a difference and the bug was nearly invisible without scaler.
I did it in the same procedure: export meshes with scaler, down-scale the vertices (not the mesh transform), re-import the down-scaled meshes and revert the scaler to identity.
But, as long as the mesh reaches a size limit, the shadow bug starts to become noticeable.
From my test, the limit is less than 10% of the far clipping plane.
Within 5% of the far clipping plane, the bug is tolerable. Which is roughly the size of the skydome below:
Not a very long distance for map sized items to be honest. Any ground/sea/skydome meshes can easily exceed this limit.
@enimaroah: confirmed. Most vulnerable subject shows no signs of the bug after making scaler Identity in the modified map. I was underestimating how much the other meshes were contributing to the bug tho, because as you can see the bug is extremely faint already in the pre-file.
Unfortunately, scaling the map ingame nets you the bug effect.
EDIT: @aastaroth- if size is the only factor here, it's not a complete dealbreaker since most maps that have massive size don't really need shadow cast/receive on all of it's expansion. It's a pain, but we would have to selectively deativate it on the meshes that are not normally used for posing models. The problem is we're encountering this bug too on meshes that don't really challenge the far-clip range. Actually, the domes are a great example. The Amemiya domes are far from huge, but at their default state they produce the bug like crazy. Another example would be the Dr mall floor I guess. But again, I'm a nurse talking to doctors right now, I just wish I could help.
EDIT2: actually, scratch that, the domes are pretty big :P just a lil size comparison:
Yes, it should be related to the size, at least after the fix. To speak it more accurately, it should be the size of the meshes that matters.
It is not directly related to size of the map though. A huge map can have more pieces of smaller meshes which gives better result than a skydome with one huge mesh.
Using the default size of temple as an example. After the fix the shadow bug is tolerable.
Making the temple size 0.5 is enough to make the bug unnoticeable.
But as I have said, this bug is not a killer to me. There are ways to circumvent the issue which includes the usage of shortcut plugin light setting. A slight tweak in angle direction gives different result.
It is a hassle, but finding the fragmented pieces that exceeded the size limit from several hundred of them is way more painful. Not sure I am gonna do that :(
For testing purposes I tried fixed values at the edge.
An extend of (0, 0, 0) made the item dissapear. (Single.MinValue, Single.MinValue, Single.MinValue) let the item remain visible but the girl's selfshadow was gone.
And then I used Single.NaN which means "Not A Number" and so broke the math :P
I am sure that this will have side effects, testing...
I was playing with the idea of chopping the boulevard up in smaller segments (pretty much as how the SBPR isle is divided).
Then the better part of my brain took over and went for that it probably wouldn't have an greater impact on the issue.
@Syncroz,
sure you could break bigger maps into pieces; and you would have to center each piece. And that would work of course. But as soon as the user would try to make scene with all pieces and would move the pieces out of the bounds the problem would return.
On the other hand, someone making a comic doesn't have to use the full map. When there would be some movement through the full map they would only need to include two adjacent pieces and those could be small enough not to produce the bug.
I was playing with the idea of chopping the boulevard up in smaller segments (pretty much as how the SBPR isle is divided).
Then the better part of my brain took over and went for that it probably wouldn't have an greater impact on the issue.
NaN... It may make an infinite loophole in the game and explodes your display card.
Well, fragmentation is something that worth a try, but my experience told me that, if the segments are too small, they also cause mesh flickering. (Which is why I deliberately include some ground meshes in the SBPR days to increase the mesh boundaries)
@Syncroz,
[...]But as soon as the user would try to make scene with all pieces and would move the pieces out of the bounds the problem would return.[...]
Well, fragmentation is something that worth a try, but my experience told me that, if the segments are too small, they also cause mesh flickering.
(Which is why I deliberately include some ground meshes in the SBPR days to increase the mesh boundaries)
I did notice the mesh flicker once in a while as well with small segments while working on my AoD mod for SBPR.
I had in mind to split the boulevard into 4-5 segments, hopefully avoiding the mesh flicker and the shadow issue.
The bounds I were talking about were described by aastaroth in his post before mine. Consider a very big map and a user would try to put piece by piece together in order to get the full map in the scene. There will be a piece which will cross the border of the dome, and then the problem will be present.
Any of the experts out there know if any advanced software or tips. The thing is when I import maps I have to go through each image to find transparent ones with alpha channels and convert them to dxt5 and non transparent to dxt1. Any quicker ways if you don't mind sharing?
Any of the experts out there know if any advanced software or tips. The thing is when I import maps I have to go through each image to find transparent ones with alpha channels and convert them to dxt5 and non transparent to dxt1. Any quicker ways if you don't mind sharing?
Use this tool for batch processing images. https://vvvv.org/contribution/dds-converter
I read you figured out how to import maps with auto assign texture to material. So do I need to guide you or you doing fine now?
Haha, I'm doing fine now thanks to the amazing support from all of you. Really thanks for the help!
Also that is the software I use, but it seems i have to look through each one to separate out the transparent alpha textures to make sure they are dxt5 not dxt1
Haha, I'm doing fine now thanks to the amazing support from all of you. Really thanks for the help!
Also that is the software I use, but it seems i have to look through each one to separate out the transparent alpha textures to make sure they are dxt5 not dxt1
Wow I didn't know you could use dxt5 for them all i guess it makes sense if a image doesnt have a alpha channel it wont show regardless of format. Still learning this kind of stuff.
I ported the entire SBPR island and no hiccup with shadow bugs. The thing that grinding my gears are the weird shiny parts in most location in the maps. This problem is happening after final December update. I tried using different materials and no effect. Now I am not bothering with it and releasing it.
Just wanted to drop by and confirm that the fix seems to be working perfectly as of .21. Tested destruction of bounding box in Lost World, probably the worst offender I had available (I think the ground mesh beats even SBPR's island meshes in size, it's a small continent). Just applying the fix in this one mesh did the trick flawlessly. With ramoram also porting a shadow bug free SBPR island using .21, I think we can safely call this one solved. Thank you so much enimaroah! This was an incredible breakthrough for the Studio. (Please excuse Azariah's face... she's about to get eaten)
