I've been troubleshooting a shader for quite some time now, and just now decided to have a closer look at the texture I'm using. And there seems to be quite a difference in how I expected the textures to look like (based on how the renders looked in blender) and how unity displays them (it looks the same when sampling it with a shader btw, so it's propably not related to the preview window). The right part of the screenshot also shows both import and export settings for the image.
Is there some kind of color correction going on here? How could I handle that and get unity to show the original image?
EDIT:
So I've done a lot of testing now and here's some of the stuff I've gotten to know so far:
The color channels blanking out seem to be a bug within unity. This only occurs when all 4 channels have the same values and does not affect the alpha channel. There's also no issue when having only 3 identical color channels (an rgb image).
The change in brightness was caused by blender as well. The values displayed by unity seem to be correct, as verified by a third party webside:
Blender also showed the correct brightness after changing the view transform to raw:
So hopefully these thing are cleared up now, the issue definetely is within blender (or propably more so in how I use it). But that
I am however still experiencing the artifacts I was earlier. You can see here how the red channel (now with some other information) looks before saving:
And here how it does right after loading the saved image into the compositor back again. It seems like what I was blaming on compression earlier is caused by the alpha channel somehow being overlayed onto all the other ones:
All the channels look fine before saving the image (still to a simple rgba 64 bit png), so any help would still be appreciated. Would be glad to know if there's any further information I should provide as well.
Related
I started a new Xcode project with the ARKit template and simply replaced the "ship.scn" with my "test.scn" filename asset. The object is about 16.5mm wide and 4.8mm tall. The ship worked fine of course, but my test object that reads "test" does not rotate as I move around it, or scale when I move towards or away from it, yet it does track in one location.
I compared the ship and test attribute panels, and I can't find anything that is different about them, except that the ship is textured and my test text is not. What is inherently special about scn objects that would make them behave correctly in ARKit besides their size? I've read through the documentation about anchoring, but it seems like I wouldn't have to do this in code if it's already a scn object.
In case anyone wants to test the file I'm using in the ARKit template to see how it's behaving, the file is here: https://ufile.io/ey49t
I’m answering the question because I think it could help others that are making a similar mistake, but it can be closed if it doesn’t make sense.
The problem is that the size was much too large where I could not see scaling or rotation no matter how much I moved around the room. Compare the scaled size in the last attribute panel on the ship model - not its actual size. Then get the size of your own model scaled down enough so that it is actually resonable.
I am using r82.
I have a mesh with multiple materials. I can change their opacity just fine, but how they are rendered is what I would call "splotchy". I have been using ThreeJs for a while, and EDIT: was able to get the transparency working in a past version (r67) with the same model in a significantly more consistent way. So I was wondering if there is something that now I need to set that I didn't need to set before or if I am just overlooking something. Upon revisiting my older code and testing it again, I found that the same transparency issues were present. It was simply a matter of there not being as obvious "splotches" (and not testing enough, I'm sure). Here is a screenshot.
Here are a few more pictures I took that highlight the issue a bit better. I have the outside wall in a light grey and the floors a dark grey in the model and can toggle the outside walls to be visible or not. In these pictures I have one face of the outside wall purple and a face of the floor in the room on the other side of the wall green.
Based on the angle of the camera, it makes part of the green floor face invisible even though there is only one face between the camera and it.
The materials are all double sided already and there is no sign of this until the transparency is on. I found a similar question that suggested changing the mesh.setFaceCulling (or something similar) but that seemed to be from an older version and wasn't in r82.
Thanks for any help in advance!
EDIT:
I started looking into the old version of threeJS and the current version's source code to see what is done differently regarding transparency. I found transparentObjects, which is an array of the objects (I believe faces) that are going to be rendered and are in sorted based on "reversePainterSortStable". There is another list of objects (I believe for the materials objects, maybe?) called opaqueObjects that uses "painterSortStable". So to see if changing the sort order would change the outcome of how things are looking when transparent I changed it so that transparentObjects got sorted by "painterSortStable" and it did change how things showed up significantly (granted it didn't fix my problem since it just removed some problem spots and created new ones).
So the short version, it looks like it is an issue with the renderOrder of the faces.
That being said, I tried finding how the r67 version of the code handled the "renderOrder" of the faces since it wasn't something that (to my knowledge) could be set in that version and just did it automatically. But I have had no such luck tracking down how it was done as of yet.
So I see two possibilities. 1) find out how the past version correctly did transparency (at least for my purposes) and change the logic in the current version to use that. Or 2) find how to properly set the renderOrder of the faces based on the camera position in the scene. Will look into the second option first, but figured it would be good to document this for others looking to help answer or that have a similar problem.
EDIT 2:
So digging through the source code for threeJs and noticed something about the transparentObjects array I mentioned in the previous edit. The first, that I cannot for the life of me figure out how it gets populated since it doesn't seem like it is added to anywhere in the code. The second is that I think it is being populated with duplicates of the entire building object/mesh (see screenshot below).
The z indexes all seem to be the same. as well as the ids and the objects are all of type "mesh" (of the ones I looked through, granted, since there are a few thousand). So I was going to figure out why its adding what is being added to the array, but that is when I stumbled across the issue of not finding where in the code that the transparentObjects array actually get populated.
EDIT 3:
WestLangley, I tried setting the depth test for the outer wall material to false and got this. Like I said in my response comment, even if it did work it wouldn't fix the issues experienced with the camera inside the building, but wanted to follow up none the less (see snapshot below).
I have two computers
Windows XP 32 + chrome last version
Windows 7 home Premium 64 bits + chrome last version
The meshlambertmaterial example is not showing at PC 2?
I have discover that there is some problem related with the lights or the emissive color ( initially black, and screen black = nothing is viewed.) I can see the 3D object if I choose other color but the result is poor because the light is not taken into acount. The behaviour is like meshbasicmaterial.
The phong material, depht and others works as expected.
I promise I'm using the web example http://threejs.org/docs/#Reference/Materials/MeshLambertMaterial
Same problem with Firefox last v.
Any idea what is happening? It is related with my graphic card? Windows 7
Other materials (phong) are viewed OK.
Any tool to check what is happening?
UPDATED
The problem could be related with three.js release.
This example uses three.js r60 :
http://www.lostmarble.com/misc/experiments/learning-threejs-master/chapter-04/06-mesh-lambert-material.html
This example works fine on my 'problematic' second computer.
However, if I change the src to three.js r71, the box is black ?
The example uses ambient white color but this parameter does not exist in r71
Any idea Westlangley? (I know that this is strange but .... is a real problem)
I can see that the second example is opened by file. If opened from the link you posted that holds the example is the same problem taking place?
Also the background of the file is black so the setClearColor attribute of the renderer might be set wrong. The black box can be related with the light.Can you post some code?
I would advise you always to use the latest revision of three js if possible.
We are using a png/8 sprite on a client's website. He is reporting the image is appearing distorted for him and on other computers on the company.
Here's how it should look:
http://i.imgur.com/wfV7ReR.jpg
And here is the print screen the client sent us:
http://i.imgur.com/sWKDYKU.jpg
I have tried donloading and exporting it again, uploading again. The problem is: On our computers it looks fine, so it's hard to test it. Our client is viewing it in IE: 11 and Google chrome: 41.0.272.118.
Has anyone seen this type of error before?
It may be the device-pixel-ratio is better than 160dpi; that'd throw off some CSS used for spriting.
If this shows "1" for you and a different value for them, I'd dig farther on that one. You could probably test this by hitting the site with an iPhone or newer Android device; they have >1.0 pixel ratios.
http://www.devicepixelratio.com/
Edit: this would also show up across-browsers on their end, as it's tied to the hardware, and not IE11.
My bet in that case is the PNG is somehow broken.
graphicdesign.stackexchange.com might be more useful; I don't know if this is fixable in CSS. (Might be; look for hacks around image backgrounds as well.)
Looking around, if you have Photoshop, you might try saving the original image, then creating a copy and changing this setting:
Image -> Mode -> Check "RGB Color"
Alternatively, try opening the image in pixlr.com, change anything however slightly, then save and use that one.
My strong suspicion is something in the way the PNG/8 is saved (maybe the alpha channel) is the issue, not any CSS you've written. Good luck!
I have a QCView that loads a Quartz file which gives you iSights feedback (basically like a QTCaptureView)
Everything displays fine
The button simply takes a snapshot using the following simple lines of code
- (void)takePicture:(id)sender {NSImage *currentImage = [outputView valueForOutputKey:#"ImageOutput"];
[[currentImage TIFFRepresentation] writeToFile:#"/Users/hendo13/Desktop/capture.tiff" atomically:NO];}
The exported image however has some very wonky colouring issues like so:
http://kttns.org/gjhnj
No filters of any sort have been applied. Does anyone know what is causing this?
It's inverted. You can use the CIInvert filter to correct it (assuming there's no way to correct the actual output of the QC view).
Oh, and I think the blue and green alpha channels are the wrong way around, too (possibly an endianness problem?). If you go with the CIInvert solution, you can use CIColorMatrix to rearrange the channels, swapping blue and green back to their proper places. Here's a tutorial I wrote for it—I wrote it for the user interface in Core Image Fun House, but using it programmatically shouldn't be too hard once you understand how the filter works.