Heheh… pretty cool. The balls falling down the shafts looked cool.
That looks really nice. Tried to run it on my Mac (OSX 10.9.2 - AMD Radeon HD 6770M) and got: “No default technique on material ‘Simple’ is supported by the video hardware. The caps [GLSL130] are required.”
Ha, that is great… already spent an hour just hiking and swimming around the world generated by pspeed (win 7 64-ati 5670: SSAO kills my fps but otherwise fine).
And zomg, now it has physics and balloons already. Brilliant.
It’s like looking into the future of gaming.
@jmaasing said: That looks really nice. Tried to run it on my Mac (OSX 10.9.2 - AMD Radeon HD 6770M) and got: "No default technique on material 'Simple' is supported by the video hardware. The caps [GLSL130] are required."
Seems like you are missing support then, the graficcard is capable of it at least, (if you have a dual boot windows you could test this)
Hey cool! 
, I tried the demo and it works well. Two things , i don’t know if you are already aware of them :
- if you stop some balls on the ground and then modify the ground , it seems that they are no more rigid body . For example if you remove the ground under a bunch of stopped balls they will not fall .
- After I heavily edit the terrain there’s some random fps drops while I’m editing . this is not so evident ,though . ( i5 , windows 8.1 , Nvidia geforce 540M )
@jmaasing said: That looks really nice. Tried to run it on my Mac (OSX 10.9.2 - AMD Radeon HD 6770M) and got: "No default technique on material 'Simple' is supported by the video hardware. The caps [GLSL130] are required."
For some reason you have to specify that you want to use OpenGL 3 explicitly for Mac, idk if thats a limitation by lwjgl or our renderer though.
@Empire Phoenix said: Seems like you are missing support then, the graficcard is capable of it at least, (if you have a dual boot windows you could test this)
OSX Supports OpenGL 4.1 on most “modern” Macs. I think it’s like @normen says, the GLContext created is not a GL 3 profile by default. Don’t know what it ends up as (2.0, 4.1?), I’ll try to test this tonight if I can.
@jmaasing said: OSX Supports OpenGL 4.1 on most "modern" Macs. I think it's like @normen says, the GLContext created is not a GL 3 profile by default. Don't know what it ends up as (2.0, 4.1?), I'll try to test this tonight if I can.
I guess this is because OSX always completely abstracts OpenGL over the two graphics cards so you have to specify “what kind of” OpenGL you want I suppose.
@relucri said: Hey cool! :) , I tried the demo and it works well. Two things , i don't know if you are already aware of them :
- if you stop some balls on the ground and then modify the ground , it seems that they are no more rigid body . For example if you remove the ground under a bunch of stopped balls they will not fall .
- After I heavily edit the terrain there’s some random fps drops while I’m editing . this is not so evident ,though . ( i5 , windows 8.1 , Nvidia geforce 540M )
The reason (1) occurs is that in physics when a rigidbody is found to be in a stable position for a long enough time it goes to “sleep” (basically its frozen). At the end of my demo video i posted there were two balls just floating in the air despite there being no ground below them. When I shot another ball at them the physics identifies that these rigidbodies are no longer in a stable position (aka they have above some threshold velocity) and wakes them up.
A good fix would be to wake up any rirgidbodies near where terrain is being edited.
A easy fix would be adding the following line of code after line 268 in GSoC_DEMO.java
[java]
bulletNode.setSleepingThresholds(0f, 0f);
[/java]
this should prevent the rigidbody from ever going to sleep.
I’m aware of the frame rate drop this it’s due to my unoptimized code.
Not to detract from the cool demo, just wanted to finish up about the OSX problem.
Using the demo straight up the shader with GLSL 1.30 won’t work, same if I set AppSettings.LWJGL_OPENGL2 (not surprising since glsl 1.3 is OpenGL 3.0). If I ask for AppSettings.LWJGL_OPENGL3 the sky shader won’t work with:
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=Common/MatDefs/Misc/Sky.vert, defines, type=Vertex, language=GLSL100] error:ERROR: 0:1: ‘’ : #version required and missing.
ERROR: 0:7: ‘attribute’ : syntax error syntax error
So a bit of damned if you do, damned if you don’t 
@jmaasing said: Not to detract from the cool demo, just wanted to finish up about the OSX problem.Using the demo straight up the shader with GLSL 1.30 won’t work, same if I set AppSettings.LWJGL_OPENGL2 (not surprising since glsl 1.3 is OpenGL 3.0). If I ask for AppSettings.LWJGL_OPENGL3 the sky shader won’t work with:
com.jme3.renderer.RendererException: compile error in:ShaderSource[name=Common/MatDefs/Misc/Sky.vert, defines, type=Vertex, language=GLSL100] error:ERROR: 0:1: ‘’ : #version required and missing.
ERROR: 0:7: ‘attribute’ : syntax error syntax errorSo a bit of damned if you do, damned if you don’t
Hmm I’m not exactly sure about how to fix this. But for now you could try setting AppSettings.LWJGL_OPENGL3 and commenting out the line where the skybox is load
(line 144 in GSoC_DEMO.java).
[java]
rootNode.attachChild(SkyFactory.createSky(assetManager, “Textures/BrightSky.dds”, false));[/java]
Though I’m guessing even if you do that you’ll probably find something else that wont work.
If you don’t actually use in 1.3 features then you could always fix the code and go back to GLSL110. Change the out/in back to varying, etc…
Alight i followed pspeed’s advice and just dropped the shaders down to GLSL100.
It seems to compile and work for me but that doesn’t mean much.
DemoLinux
DemoMac
DemoWindows
You can see if these work for you @jmaasing
@FuzzyMonkey said: Alight i followed pspeed's advice and just dropped the shaders down to GLSL100.It seems to compile and work for me but that doesn’t mean much.
DemoLinux
DemoMac
DemoWindows
You can see if these work for you @jmaasing
No, set it to GLSL110. GLSL100 isn’t a real version and so will potentially throw your graphics card into compatibility mode which is kind of how this problem got started in the first place.
GLSL110 is the first real GLSL version (as I understand it).
@FuzzyMonkey said: Clearly I should have read more closely.
That little ‘1’ tries to hide in there. 
1 Like
@FuzzyMonkey said: Clearly I should have read more closely.
Did a quick test, this shows the same problem with Sky.vert, I don’t know what that is about since that shaders is the jMonkeyEngine sky shader.
I hope to get some free time to test more this weekend, d*mned day job customer does not understand the importance of getting shader versions to match in jMonkey-demos :roll: