I've created a sample to show what I'm seeing: https://haddons.net/threejs/chrome_firefox.html
I have a basic model that's loading a texture onto a plane and also pulling in some heightmap data. If I load it in chrome the texture is oriented in one direction and if I load it in firefox it's rotated 180 degrees.
Am I doing something wrong or is this a firefox, chrome or three.js bug?
Unfortunately, this is a bug in the current version of three.js (R102). It will be fixed with the next release by this PR.
The problem was that textures were flipped if a resize was necessary. This always happens if you try to use mipmapping with a NPOT texture. A workaround is to configure your texture like the following, to use POT textures or WebGL 2:
texture.minFilter = THREE.LinearFilter;
Related
I have a pretty strange behaviour with three.js when I try to load different textures for an environment cube map. Everything works fine till I try to test the same scene with larger textures. My camera is pretty much stable so I only have to change one side of the env cube to a large resolution texture as that will be the background of the scene which will be visible, the other 5 sides are small pngs - those are only visible in reflection.
There is no clear breaking point, what seems to usually work as an image for the env.cube is about 600x600px-ish, going any higher resulting in the scene loading completely black.
To make the scene look nice on most devices, I have to go up to a resolution around 1500x1500px (so not insanely large) for the background, and I have no idea why it breaks with a bigger image.
What I already tried/did:
image paths are fine, overwriting a working image to a larger version also breaks the scene.
I had no other idea what to try, maybe it has to do something with photoshop and its image encoding or something along those lines?
the scene contains:
a camera, a gltf model to test with and the environment cube. everything works perfect with small textures.
I already looked at the texture documentation of threejs and found nothing about what could cause this behaviour, I'm completely stuck.
I have created a simple human figure. The eyelashes use a texture with transparency.
However as soon as I turn on transparency for the face texture there is created transparency where it shouldn't be.
You can look through the face texture in the part that lies below the eye lashes.
See the effect by toggling face transparency with this line:
mesh.material.materials[3].transparent = false
mesh.material.materials[3].transparent = true
I wish to have transparency turned on for the face texture, so how can I solve this problem?
Demo:
http://dev.udart.dk/transparencyProblemStackOverflow/
(wait for model to load)
Code:
https://github.com/vibber/transparencyProblemStackOverflow/blob/gh-pages/index.html
Transparent geometry gets manually depth-sorted, for more information see this canonical answer by Toji: Transparent textures behaviour in WebGL.
If you want this scenario to work properly, you'll have to split up your model, and render the eyelashes as a separate (sub)mesh. This way three.js can render the rest of the face using the normal z-buffer approach, then apply the eyelashes separately (from the depth-sorted transaprent objects queue).
I am using sprite sheets to create animated textures with THREE.js. Each sprite instance utilizes texture offsets to control which of the images to present that frame. Multiple animated sprites may be on the screen at once.
Currently I am using Texture.clone() to duplicate the sprite sheet texture. However, unless I set Texture.needsUpdate to true, the texture will not display on the sprites. Setting needsUpdate to true allows me to display multiple independent animated sprites at once, but unfortunately this causes the texture memory to be duplicate on the card (/ integrated chip). Using Chrome WebGL Inspector I can clearly see that the sprite texture has been duplicate the same number of times as animated sprites that have been rendered.
Is there any way to clone / reuse the texture with different offsets for each instance without duplicating the memory? Is this a bug or am I doing something wrong.
THREE.js r67
Update:
One way that we have gotten around this (not a great way I admit) is to duplicate the GL texture ID assigned to the original texture and set the cloned texture as being initialized.
clonedTexture.__webglTexture = origTexture.__webglTexture;
clonedTexture.__webglInit = true;
This requires that the texture has already been sent to the card, which we force with render.setTexture(origTexture...).
This is something that's in the works. Keep an eye for whenever THREE.Image lands.
In the example program given here in Dart, why is the image texture initially upside down? It seems to be flipped upside down, not rotated. Why is that?
Here is the example running, I am talking about the cube texture on the first frame when you view it, before it rotates. I made an example based upon this but I am upset to find the texture flipped upside down.
In the example program given here in Dart, why is the image texture initially upside down?
For me, the example shows the texture upside down not only in the first frame but in all frames (by comparing the texture and the running example). I am not sure why you and I are seeing different things.
In any case, this seems to be an old bug in CubeGeometry in three.js, which was fixed in July 2012 but has not been fixed in three.dart.
When I add to the scene two objects and set their transparency as true with some opacity and using TrackballControls I rotate the scene by mouse, the object which was initially further from camera loses its transparency.
I read that this is Z-buffer problem and further objects from camera will be displayed first. But when I rotate the scene using TrackballControls, camera changes its position, so transparent objects should be displayed correctly. But it is not like that.
Here in this picture - on the right is frontview, on the left is backview which is not displayed correctly:
http://www.foto-ondruskova.cz/Experiment/lenses.jpg
Please, any solutions?
I have come across this problem and setting alphaTest: 0.5 to the material as suggested here solved my problem. But it is hit and miss. Give it a try. Hopefully it works!