Object not shown and not rendered properly in some devices

[kkl]

You were right! Adding dummy matrix works as well!

For opaque objects seems to be ok now. There's another issue, btw. When I add in additive transparent objects at the back, the cut off reappear again. Is it zbuffer causing the issue again? Default shader works fine.

The additive transparent objects at the back use default jpct shaders.

[kkl]

More screenshots:

1st screenshot is taken in Nexus 6
2nd is from samsung device, which is expected result

[kkl]

In shader, I changed the "myPosition"(hardware skinning) to normal "position" from JPCT, and everything works ok. I think there must be something wrong with hardware skinning part. I still wonder why it just doesn't work on Nexus 6. Can it be possible the device can't handle that many of attributes data?

[EgonOlsen]

I'm a bit confused about the usage of skinJointIndices. It's a vec4, but you are using a [.]-index on it. Is that a valid syntax to access the components? Have you tried .x and .y instead?

[kkl]

I think I was copying from raft code. I changed them to .x and .y， it still gives the same result with cut off. What could be wrong? I'll try and check if the skinJointIndices contains any value bigger than the skinPalette matrix array size. Does out-of-bound-index possibly cause the problem?

[EgonOlsen]

Does out-of-bound-index possibly cause the problem?

Maybe. Either that or a similar thing as with the mat[]-array. It might be driver bug as well. Just rule that out, try to re-order your uniforms in the shader to see if that changes something.

[kkl]

I got the first shader fixed by adding back the "if (angle > 0.0)" (this part was commented in first shader). It seems if the vector angle between vertex and light position is < 0, it will mess up the whole thing. I can't be sure if that's the root cause, but it's working fine now.

As for the second shader, bcoz I'm using the sample code from http://www.jpct.net/wiki/index.php?title=Shaders (with bump map), it doesn't have "angle" value. Is there any way we can control to avoid processing the light calculation if the angle vector < 0, like the one in default shader?

[kkl]

Strangely, for second shader, if I change final color to 0.0 in fragment shader, it doesn't have the cut off anymore. Initially I thought some calculation in fragment that give NaN value to variable and mess up the system, but I tried using sqrt(-1) to produce NaN value, then set final color to 0.0, to try to reproduce the cut-off issue, but it still seemed ok. I'm getting out of idea, do you have any clue on this?

I tried reordering the uniforms, doesn't seem to fix the issue. In what way should we order the uniforms?

* Nexus 6 is really a pain-in-the-ass device. Only it causes the problem so far.     

[EgonOlsen]

It's most likely caused by negative values for alpha or color values. Try to add something like

Code Select Expand

col=max(col, vec4(0.0, 0.0, 0.0, 0.0));

to see if that helps.

[kkl]

Code Select Expand

col=max(col, vec4(0.0, 0.0, 0.0, 0.0));
Tried and it's still have the same issue.

I tried to reorder the way of adding objects to world. By adding the transparent object (suppose to be in background, further away from camera), then adding the blue objects (closer to camera) after that, and it works now! I'm just curious if the order of adding object to world will affect the rendering. Do you have any idea what's going there?

[EgonOlsen]

Do you have any idea what's going there?

No, not quite. Ordering in jPCT-AE happens by state for opaque objects and by depth for transparent ones. Regardless of that, transparent objects will be drawn after all opaque objects. So I fail to see how reordering them in World can help, because they will be reordered anyway. Are you using setSortOffset()? Have you tried without it? Maybe you are giving it some values that screw up the sorting.

[kkl]

Yes I'm using setSortOffset. I tried to disable all setSortOffset and strangely, it has cut off for first few frames, then it becomes ok after that. But if I disable setSortOffset, it would tend to draw object further away from camera first, in which it does not take advantage of deferred rendering. If we are to take advantage and reduce overdrawing, we should draw the front object first, then follows the back objects, right? That's how I use setSortOffset to achieve that.

[EgonOlsen]

...deferred rendering....

...so you are doing something special here? What exactly?

[kkl]

Just something we discussed earlier http://www.jpct.net/forum2/index.php/topic,3956.msg27790.html#msg27790. CMIIW, if one opaque object A overlaps another object B, the part of B overlapped by A can be deferred and not required to be rendered. So this way we can save more fill rate. That's what I intended to do by using setSoftOffset(). Does it mess up with rendering? Maybe I have overlooked other factors?

[EgonOlsen]

I don't think that this will work in combination with the engine's default behaviour.  setSortOffset has no effect on opaque objects and while it might be possible to move a transparent object behind an opaque one, this is more like a crude hack and can work only by accident. In Config, there's a switch called stateOrientedSorting. By setting it to false, all objects will be sorted based on their depth. This might help in this case.
Have you tried not to do this deferred thingy at all? I don't think that it will help on anything but Tegra chips anyway.