could somebody take a look at these tests and tell me what u are seeing, unfortunately for some this is setup for Eclipse and may take some setup time for netbeans/jmp
http://www.box.net/shared/ogj3s6zb4jbrmxz8tjax
there are five test cases TestOgreAnim, TestOgreAnim2, TestOgreAnim3, TestWalkingCharToon3, TestWalkingCharToon4
both TestOgreAnim, TestWalkingCharToon3, would give an accurate idea of what the effect should look like
the others are wrong in that TestOgreAnim2, TestWalkingCharToon4 produces a weird blue tinting effect while TestOgreAnim3 just not correct, in addition firing bullets in TestWalkingCharToon4 (LMB) or movin the camera around would cause the affect to flicker while in TestWalkingCharToon3 everything work as it should
I,ve been tryin to determine what’s up with this and couldn’t find the issue other the models are different, but that is inconsequential since all these models display correct in Render Monkey and meshlabs though I have to tweak the settings in meshlabs to eliminate that very said blue tint effect.
hope someone can help
notes: pressing space plays a sequence of animations in TestOgreAnim2
note2: in TestWalkingCharToon3, TestWalkingCharToon4 most input stuff is handled by mouse buttons
anybody ? I just need some ideas as to why the effect might be so inconsistent across models in jme
Unfortunately I think this is one of those occurrence where using something else than jMP will not help you at all. 
I would love to take some time to check things out but having to install Eclipse… Not very tempting.
I’d love to know and understand why anyone would use Eclipse though. I’ve got nothing against it really, but jMP is pretty powerful in its own right, so why would you give yourself so much trouble? I would also imagine most, if not all, of jMPs plugins are not working on Eclipse unless they were ported.
This is not to bash to you or your decision to use that IDE. I’m badly placed to give anyone a hard time on that subject, or any other really, but I’m curious.
madjack said:
Unfortunately I think this is one of those occurrence where using something else than jMP will not help you at all. :( I would love to take some time to check things out but having to install Eclipse... Not very tempting.
I'd love to know and understand why anyone would use Eclipse though. I've got nothing against it really, but jMP is pretty powerful in its own right, so why would you give yourself so much trouble? I would also imagine most, if not all, of jMPs plugins are not working on Eclipse unless they were ported.
This is not to bash to you or your decision to use that IDE. I'm badly placed to give anyone a hard time on that subject, or any other really, but I'm curious.
quite frankly I move/copy code around a lot, testingassessing this and that and Eclipse make that whole scene alot easier than netbeansjmp I know some might say whats a few red Xs to fix, well its a couple minutes I dont have to spend in eclipse, beyond that I'm too used to Eclipse and I did give jmp a real try for coding, felt uncomfortable at the time, cant get a hang of the material editor, depending on what you do your setting would disappear, and I have to take the extra precaution of copying the text to an external editor just out of fear that work done would simple disappear for god alone knows what reason..... I test stuff out in there from time to time but........
as for the argument well I did try the import thingie but it doesn't recognize my workspace folder....still though its a few classes and some assets
You don’t have to fix every broken part of your code to run a main in jmp at all, just right-click it and it will be run with whatever last working build of any class was there. But frankly thats not a very clean way to code in any IDE ^^
as for the issue this seems to originate from blender I imported Oto exported it back out and sure enough the effect seemed to fail which leads to my next question does anybody know what Oto was original exported from and why that(the export process) would make jme3 choke
seriously was Oto originally exported from blender or anyone knows where it came from I tried google but I’m not having luck finding it, importing and exporting the jme3 stock model produces markedly different xml output
You can find the oto model here:
OTO the cleaner
See “oto pushing”.
It was exported from Blender 2.49 with the latest Ogre export script for that version. I don’t know about 2.58
thank you man, hope fully this will provided insight into why the shader is bugging out on my own models
yeah there is definitely something with my own models and the eventual export that’s screwing up the shader, still haven’t the slightest idea why the adverse effects on the shader of all things, since my models look and behave as expected on import into jme3, but goes all dark blue once the j3m is applied… weird…but I have the oto file now which on export handles a duplicate of that very said j3m quite nicely as did the original, hopefully I can find the missing screw now
still any Idea why a mesh export might corrupt a shader’s render
Bad normals will affect shaders rendering.
Is it possible to post the shader in a way that doesn’t require a download and de-raring just to look?
madjack said:
Bad normals will affect shaders rendering.
thought of that too but these models tested fine in Render monkey and meshlabs (though with a tweak internal to that app), then again the format was .obj, what else can I do besides blenders normals repair options
pspeed said:
Is it possible to post the shader in a way that doesn't require a download and de-raring just to look?
yeah why not but its the models from the look of things though
frag
[java]varying vec3 vLight;
varying vec4 vDiff;
//varying vec4 vView;
varying vec3 vNormal;
varying vec4 vMat;
varying vec2 texCoord0;
uniform sampler2D m_colorMap;
uniform vec4 m_vWidths;
uniform vec4 m_noiseMod;
uniform vec4 m_vWidthFactor;
uniform vec4 m_Material;
uniform float m_Time;
uniform float m_Strength;
uniform float m_blend;
void main(){
vec3 vNorm = normalize(vNormal);
vec4 vColour = vMat;
vec3 vLightN = normalize(vLight);
// Random, adding values to get rid of edge errors and mods that return 0
float x = (texCoord0.x+4.0) * (texCoord0.y+4.0) * (m_Time*10.0);
vec4 grain = vec4(mod((mod(x, 13.0) + 1.0) * (mod(x, 123.0) + 1.0), 0.01)-0.005) * m_Strength;
float ndotl = dot(vNorm, vLightN);
vec4 base0 = texture2D(m_colorMap, texCoord0);
gl_FragColor = base0 * gl_FrontMaterial.diffuse;
vColour *=mix(m_vWidthFactor.x+(grain*m_noiseMod.x), vec4(1.0), step(m_vWidths.x,ndotl ));
vColour *=mix(m_vWidthFactor.y+(grain*m_noiseMod.y), vec4(1.0), step(m_vWidths.y,ndotl ));
vColour *=mix(m_vWidthFactor.z+(grain*m_noiseMod.z), vec4(1.0), step(m_vWidths.z,ndotl ));
vColour *=mix(m_vWidthFactor.w+(grain*m_noiseMod.w), vec4(1.0), step(m_vWidths.w,ndotl ));
float lum = dot(base0.rgb, vec3(0.299, 0.587, 0.114));
vec4 gray = vec4(lum, lum, lum, base0.a);
gl_FragColor = mix(base0, gray, m_blend);
gl_FragColor *= ((mix(base0, gray, m_blend) + vColour) * (gl_FrontMaterial.diffuse*.75))* m_Material;
}
[/java]
vert
[java]varying vec3 vLight;
varying vec4 vDiff;
varying vec4 vView;
varying vec3 vNormal;
varying vec4 vMat;
varying vec2 texCoord0;
uniform mat4 g_WorldViewProjectionMatrix;
uniform mat3 g_NormalMatrix;
uniform mat4 g_WorldViewMatrix;
attribute vec3 inPosition;
attribute vec3 inNormal;
attribute vec4 inColor;
attribute vec2 inTexCoord;
void main()
{
gl_Position = g_WorldViewProjectionMatrix * vec4(inPosition, 1.0);
vec3 vtx = (g_WorldViewMatrix * vec4(inPosition, 1.0)).xyz;
vLight = (gl_LightSource[0].position).xyz - vtx;
//texture
//texCoord0 = gl_MultiTexCoord0.xy;
texCoord0 = inTexCoord.xy;
vView = vec4(inPosition, 1.0) - g_WorldViewMatrix[3];
vNormal = g_NormalMatrix * inNormal;
vMat = inColor * gl_LightSource[0].diffuse;
}[/java]
j3md
[java]MaterialDef MyToon1{
MaterialParameters {
Texture2D colorMap
Vector4 vWidths
Vector4 noiseMod
Vector4 vWidthFactor
Vector4 Material
Float Time
Float Strength
Float blend
}
Technique {
VertexShader GLSL100: assets/Shaders/toon.vert
FragmentShader GLSL100: assets/Shaders/toon.frag
WorldParameters {
WorldViewProjectionMatrix
NormalMatrix
WorldViewMatrix
ViewMatrix
CameraPosition
WorldMatrix
}
}
}[/java]
character ready j3m sample
[java]Material toon : assets/MatDefs/MyToon1.j3md {
MaterialParameters {
colorMap : assets/Models/hitman/suites1navy3.png
vWidths : 0.645 0.635 0.62 0.6
noiseMod : 0.75 0.5 0.25 0.05
vWidthFactor : 0.75 0.5 0.25 0.0
Material : 0.7529 0.6362 0.7145 1
Time : 10.0
Strength : 125.0
blend : 0.0
}
}
[/java]
Probably unlikely, but jME3/lwjgl might be less lenient when it comes to error. I don’t know about Meshlab, but RenderMonkey is pretty “old” and unmaintained.
There’s an app I tried when I worked on my lens flare called ShaderMaker. You might want to try it. It’s also old, but it’s very easy to use. Look it up on google and try it. That way, if all three of them show the same result then you’ll be sure (or as sure as possible given their age) that it’s not the shaders.
mcbeth said:
yeah why not but its the models from the look of things though
Yeah, but I was trying to see if something in the shader jumped out at me as being model-dependent in some way. It didn't but maybe it will for someone else.
The only thing I could see is the texture coordinates... I didn't work through the math but maybe if one model sticks to 0-1.0 and the other has negative texture coordinates or larger than 1 or something then it does something weird. Sort of grasping at straws, though.
madjack said:
There's an app I tried when I worked on my lens flare called ShaderMaker.
yeah thanks I'll give that a go, though I feel its an anomaly in the my blend files or setup because the Oto packaged with jme3 that worked initially will also start showing the blue tint if I import and then re-export, the one thing that is common is due to expedience on my part I imported to one of my test model files rather than a clean new one......now that I think about it....but I'll have to test this tomorrow, I'm done for now
thanks all
Regardless of the model, do you get the same result when you apply that shader to something else than Oto? Like a cube? Or the hovercraft? Could it be the lighting? I imagine you tested that, but worth a mention anyway.
Sorry if you mentioned it before, I didn’t see it. Besides, I just woke up and my memory is lazy at this time of the day. 
yep two others
well I found the solution to my issues but it’s so friggin weird, Oto had a Vertex Color layer applied didn’t notice that at first because I never really used vertex paint, but this the strange part adding a vertex paint layer to my model and manually configuring the ogre mat file to match the way Oto’s is written ( though I feel this is consequential since I had adjusted my copy of the jme3 stock Oto xml to load j3m instead of material files and it work perfectly
in short I have to apply an invisible layer of vertex painter for my shader to work …how f’ed is that :o
any clues as to why
anyway solved…ish
thank again everyone
Your shader expects the vertex to have a color attribute:
attribute vec4 inColor;
…perhaps that changes you’ve made are the way to make sure that the mesh has one. Otherwise it might have just had whatever garbage the GPU driver decided to stick there.