Unsure exactly what’s happening but when I use the same material, which is pretty simple, I get a big white spot in the preview viewports whereas I don’t get that behavior in the main viewport when using the same material.
Material:
[java]
Material Star Material : Common/MatDefs/Light/Lighting.j3md {
MaterialParameters {
DiffuseMap : Textures/Stars/ClassM_mapped.png
GlowMap : Textures/Stars/ClassM.png
}
AdditionalRenderState {
}
}
[/java]
Here’s the preview viewport and the normal star in the real “main viewport” (that last one has a flare, but it has nothing to do with the material of the star itself, it’s rendered on top of the viewport).
As it was before, the preview viewports are having a multitude of problems when used with postprocessing. Relocation of viewport, texturing “doubling”, etc. I understand it’s not a high priority though but thought it was a good idea to put it back on topic.
you may have to play with the shininess and set it to 0.
The default is now 1 and may be why you have this.
btw nice work on the lens flare you finally did it, congrats!!
Manually setting Shininess to 0 didn’t do anything. I think it’s because:
Lighting.j3md
[java]
Float Shininess (MaterialShininess) : 1
[/java]
effectively enforces it to be 1 and will override any setting I might assign to it in my material.
As far as the lens flare goes, it’s not done yet. I’m having a hard time with the vectorization of the flares. At some angles it works fine, at others it looks like crap. There’s also some issues I have to fix with the distance to the star and simply disable part of the flare when we’re too close to a star. But for now those are minor and will get fixed (begged for help) later.
Set specular color to zero if you’re not using specular. By default specular is assumed to be white
Sorry to report no changes. Still get the same output.
[java]
private void texturizeGeometry(Material newMaterial) {
if (newMaterial != null) {
newMaterial.setColor("Specular", new ColorRGBA(0, 0, 0, 0));
geoObject.setMaterial(newMaterial);
}
}
[/java]
Oh crap.
Where’s that damn “delete thread” button!?
I have a light in that scene and I guess it’s too bright and/or too close to the geometry… I’ll tweak it so it’s more bearable. Just changing its color improved things by a lot though.
Move along, nothing to see here…
That is all. lol
Hmm… I was forced to switch to unshaded material because the brightness of AmbientLight is way too low. Even when using ColorRGBA.White, I can barely make the geometry out.
Let’s just hope the result will look good with postprocessing when it’s fixed for multiple viewports.
i’ve got a big white spot as well, which i don’t remember having before ;o
Its better than having your whole app filled with blackness on NVIDIA cards (this is what this fix was for)
:O, well in that case I guess i can live with it 
Momoko_Fan said:
Its better than having your whole app filled with blackness on NVIDIA cards (this is what this fix was for)
I don't get it. I've got a 480GTX and never experience that blackness. O_o
madjack said:
I don't get it. I've got a 480GTX and never experience that blackness. O_o
Its .... a very weird bug. Suffice to say.
It only happens with certain shader assembly versions and I am 99% sure its a driver bug and has nothing to do with jME3. Still as with everything else, we need to make workarounds for it and this is one of them.
Gotcha.
You hack it so it works, we hack it back to make it work. Ah, vicious circles.
madjack said:
Manually setting Shininess to 0 didn't do anything. I think it's because:
Lighting.j3md
[java]
Float Shininess (MaterialShininess) : 1
[/java]
effectively enforces it to be 1 and will override any setting I might assign to it in my material.
No 1 is the default value, setting it to 0 works, i did it like thousand times.
Also
madjack said:
Let's just hope the result will look good with postprocessing when it's fixed for multiple viewports.
Wait a minute, is there still issues with this? I thought that was working now.
Well, if you say it’s been fixed… I’ll go through it all line by line, but so far it doesn’t seem to want to play nice.
Well, I’ve looked and looked and searched and redid both preview classes (which are now pretty much the exact same thing) but I can’t find anywhere in my game where those behavior happen. I don’t think it’s on my side…
So, I decided to make a video to show off the two main problems. It seems when you have two glow post-processing on two viewports (plus the main one) it leads so some funky business. I can’t even explain, so better watch the video (it’s not long, about 2:30).
http://www.youtube.com/watch?v=sHVOADr9R2E
I’ll take questions at the end.
Well obviously the FilterPostProcessor assumes the viewport won’t move after it had already been set up. Probably some movement detection mechanism will need to be put in place and make the appropriate adjustments to the filter(s)
Did you notice how the filter acted? In the list preview (the small one on the left) the glow is immediately visible when enabled. Not the other one. But, on the two subsequent on/off, they would add. I’m pretty tired now, so I’ll recheck everything tomorrow, just in case something slipped by.