I don’t know if this is a graphics glitch, or something to do with the mesh deform (hance a post in General, rather than Graphics), but you can see for yourself in this video:
So, it’s a simple match 3 game, not unlike Cubis (if anyone played that). There are wedge objects which animate into a regular cube shape, but it seems something is wrong, because the wedges tend to turn black sporadically (based on camera orientation, or adding yet another wedge to the playfield), as you can clearly see in the video.
I’m using the ColoredTextured material, as stated in the title, so it’s not a lighting issue (there are no lights in the scene).
Presuming your mesh isn’t being changed as the camera moves then there isn’t much that can be wrong with the code. ColoredTexture is also about as simple a shader as there is.
So, presuming it’s not a dynamic mesh generation issue then it comes down to bugs in the graphics card/drivers, I guess.
I should have mentioned that all my models were created in, and exported from blender. The wedge is just a deformed cube, with an armature (and accompanying animation) that “reforms” it back into a cube.
I’ve created materials (based on ColoredTextured template) for each distinct color I want to use, and then I just set those materials.
I don’t have time to download project zips and mess with them but hopefully someone else will. Was the test case sufficiently simplified down to just a single class exhibiting the issue? If so then maybe you can include that here in a code (java) tags so that those of us strapped for time can see if anything obvious jumps out.
If you replace your models with JME boxes does the problem go away?
Hmmm… how are you implementing the black outlines?
his example project is just a single 100 line file, and its just things sitting in the scene and you see them flicker as you move the camera.
i have no clue whats going on here myself. i was suspecting it was a video card thing too and if someone else ran it that it wouldnt show up. however i only see the issue on the wedges and never the cubes
codewise i dont see anything weird, in terms of the models themselves theyre a little weird:
wedge has 2 animation controls, and both models have lights and camera nodes on them.
i would start off with trying to figure out why wedge has 2 AnimControl’s, the lights and camera nodes likely aren’t impacting anything though you typically wouldn’t include them in your models.
unfortunately i dont know much about blender so i cant help you with troubleshooting that, maybe someone else here can give you a little insight.
@icamefromspace said:
wedge has 2 animation controls, and both models have lights and camera nodes on them.
That’s simply how blender exports the scene. In the code, you’ll notice that I only add the “Cube” object to rootNode, so all the “extra” stuff is not included, and should therefore not cause any problems.
But then again, I don’t know.
@pspeed said:
I'm starting to think that the key is how the black outlines are done.
It’s just a texture with an alpha channel.
As Daniel confirmed, my example is simplified, so you can see for yourself, without wasting much time.
the extra AnimControl might have nothing to do with it, but it could as it might just becausing the importer to get confused or do something weird.
the way that the issue happens though it feels like its some kind of z-fighting issue (two colors/objects in exactly the same place), espeically since at some angles youll see part of a face being one color than another part of a face another color.
btw where exactly is the texture file located? i see you reference it in your material but i cant find the file itself… is it somehow packed in the j3o?
@Goran said:
It's just a texture with an alpha channel.
As Daniel confirmed, my example is simplified, so you can see for yourself, without wasting much time.
I would really appreciate it if you could.
Well, it’s acting like there is a black cube and a colored cube in the same location and that sometimes they sort incorrectly at certain angles. You could load your model in the scene explorer to poke at the hierarchy and see.
I can’t think of anything else that would cause this.
@icamefromspace said:
the extra AnimControl might have nothing to do with it, but it could as it might just becausing the importer to get confused or do something weird.
I created a blend file that hosts the wedge without any animation, and imported that into jmonkey -> There is no AnimControl, and it’s basically the same hierarchy as the regular cube, but the problem still persists.
So, that doesn’t seem to be an issue in this case.
btw where exactly is the texture file located? i see you reference it in your material but i cant find the file itself... is it somehow packed in the j3o?
It seems to be packed somehow. If you open one of the materials, you can click on “Set” for the texture, and you should see a list that includes “blackborder.png”.
@pspeed said:
Repeating another question... if you use a JME Box instead of your model does the issue still happen?
No, the issue seems specific to the wedge geometry type.
If you take a look at my simple example, you will see a scene with both regular cubes, and wedges; only wedges seem to carry the anomaly.
Also, as far as I can tell, there is nothing in the node hierarchy to indicate that two objects are overlapping, but maybe I’m just not looking at the right thing …
hmm, now i am i suspecting that in blender the wedge has two faces in one spot or something like that. (in the new blend file you made did you remake the wedge, or just remove the animations?)
you could try deleting all the faces in blender, then doing the “remove doubles” for the verts, then manually add back the faces. (selected 4 sides, then push f to “fill in” the edges with a face).
@icamefromspace said:
in the new blend file you made did you remake the wedge, or just remove the animations?
I just removed the animations. A completely new wedge seemed to work fine.
I continued on to add the armature (along with the animation) to this new wedge, and even that worked great!
So, it seems like the issue is resolved, but I have no idea what the problem was to begin with … I guess it was some blender glitch …
Well, in either case, I consider the issue resolved (as far as I’m concerned) - If jMonkey devs want to dig into it a bit deeper, they can look through the example, but I’m all set at this point.
@Goran said:
No, the issue seems specific to the wedge geometry type.
If you take a look at my simple example, you will see a scene with both regular cubes, and wedges; only wedges seem to carry the anomaly.
Also, as far as I can tell, there is nothing in the node hierarchy to indicate that two objects are overlapping, but maybe I’m just not looking at the right thing …
BTW: Did you look at the example?
Well, in your video the cubes were going black too.
I rarely if ever download and unpack zips from forum posters, so no I didn’t look at it. It’s easier to read code if it’s just posted to the forum and the zip is nice for people with more time.
Glad you seem to have gotten your problem sorted out, though.
@pspeed said:
Well, in your video the cubes were going black too.
If you watch carefully, you can see that those were actually wedges that deformed into cubes.
I rarely if ever download and unpack zips from forum posters, so no I didn't look at it. It's easier to read code if it's just posted to the forum and the zip is nice for people with more time.
Given your activity on the forums, I was under the impression that you had some time to look at a simplified example.
@Goran said:
If you watch carefully, you can see that those were actually wedges that deformed into cubes.
Given your activity on the forums, I was under the impression that you had some time to look at a simplified example.
Well, in either case, I appreciate the effort.
9 times out of 10, if it’s a code problem then I can spot the error right in posted source code in less than 20-30 seconds. Then I can move on to the next post or get back to work. Having to download a zip, extract it, find and open the right source file, find the issue, cut and paste it back to the forum just to comment on it… no thanks. A 20 second helping hand became a 5-10 minute job.
…and there are plenty of others who will take the time to download. So I stick to answering the posts where people posted the code.