I’m not very familiar with GLSL syntax, but this seems weird to me.
There’s no sample2DArray
in dome20.frag.
Perhaps JME re-wrote the GLSL to something that’s invalid.
Did JME dump the rest of the GLSL, by any chance?
I’m not very familiar with GLSL syntax, but this seems weird to me.
There’s no sample2DArray
in dome20.frag.
Perhaps JME re-wrote the GLSL to something that’s invalid.
Did JME dump the rest of the GLSL, by any chance?
It dumped the whole thing to the browser console.
It’s long so I posted it to pastebin. Let me know if you can’t access it.
precision highp sampler2DArray; jmeapp.js:481:29
This is not really a JME thing. It’s related to the technology used to get JME running in a browser… which is definitely the topic of this thread but not really something sgold messes with (or myself).
No need to tag people as we all read the whole forum anyway.
You’ll have to wait for OP to get back to you on the issue.
Thanks for capturing and sharing the dump.
Paul is right that WebGL is outside my knowledge. I’ll await Riccardo’s input. If SkyControl needs modification to work with WebGL, I’ll gladly cooperate.
I think the problem is that the shader is using #version 100
.
The j3md should be updated to explicitly use GLSL300 when available:
Like so:
VertexShader GLSL300 GLSL150 GLSL100 : XXX.vert
FragmentShader GLSL300 GLSL150 GLSL100 : XXX.frag
nb. order is from higher to lower
WebGL imposes strict implementation requirements, limiting JME to run exclusively on WebGL2 with GL ES 3. Fortunately, as long as the shaders utilize GLSLCompat.glsllib, the above modification is sufficient, since GLSLCompat takes care of adapting the code.
That fixed it. For my program, I had to change those lines in 4 different places (2 in dome20.j3d and 2 in dome06.j3d).
Thanks to everyone for your help.
I’ve incorporated Riccardo’s solution into version 1.0.5 of SkyControl:
repositories {
mavenCentral()
}
dependencies {
implementation 'com.github.stephengold:SkyControl:1.0.5'
}
Is it possible to have the webgl canvas take up only part of the browser page?
e.g. for the canvas to take up the right 2/3 of the page.
I have set up my html so that the canvas is the correct size and position when empty. But once I call jme.start(), the canvas at various stages increases in size, until it takes up the full width of the screen (or even bigger, with scroll bars).
Any ideas?
The code resizes the canvas to the size of its container, so you can attach the canvas to a div of the correct size.
If that’s a problem for your usecase, you can disable the function that does the resizing by adding
<script>
if(!window.jme)window.jme={}
window.jme.canvasFitParent = function (){ /*do nothing*/ }
</script>
before the inclusion of jme.js
OK I got it working using the code snippet provided.
Another question: is there a way to change the log level? It seems to be logging messages at all levels. e.g. jme log messages at FINE log level are being logged.
I tried Logger.getLogger("com.jme3").setLevel(Level.SEVERE);
but setLevel() is not implemented by Teavm.
I’ve double checked, and indeed it seems setLevel is not implemented even in the latest version of teavm.
The correct way to solve this issue would be to patch the TLogger class using the TeaClassTransformer, however this might end up being pretty complex. At the very least it should be patched to output <=FINE logs to console.log, since it seems it is outputting everything to console.info atm.
Otherwise, i think the only workaround you can apply, is to disable console info entirely
console.info=function(){}
That workaround worked
I encountered some issues around handling of the Escape key and the mouse:
These two obviously don’t work well together. If the user presses escape, SimpleApplication calls stop() which unloads your application.
You can see this in the PBR Demo.
To stop unloading the application on Escape key, I added a line to simpleInitApp()
inputManager.deleteMapping(INPUT_MAPPING_EXIT);
My second comment is around use of mouse lock when flyCam.setDragToRotate
is true
and the application is not in fullscreen mode. In this scenario I don’t see the need for mouse lock, as the mouse drag works OK without it. The mouse lock messages are just an annoyance.
It might be useful to either disable mouse lock by default in this scenario, or provide an API to disable mouse lock manually. I just removed the call to canvas.requestPointerLock
in com.jme3.web.input.WebMouseInput
and I can’t see any ill effects.
My third comment is about handling Mouse events that occur outside the WebGL canvas. This would apply when the canvas is not in fullscreen mode and is sharing the page with other html elements. Currently JME will process all mouse events no matter where they occur on the page. e.g if the user drags the mouse on another html element, the view inside jme will also rotate.
I added an extra check to WebMouseInput.handleEvent()
to check if xpos and ypos are actually inside the canvas boundary and ignore the event otherwise.
if(xPos>=0 && yPos>=0 && xPos<= canvas.getWidth() && yPos<=canvas.getHeight()) {
MouseMotionEvent mme = new MouseMotionEvent((int) xPos, (int) yPos, (int) dX, (int) dY, 0, 0);
mme.setTime(getInputTimeNanos());
mouseMotionEvents.add(mme);
}