www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: trisco on November 20, 2009, 02:46:22 pm
-
This thread is a split from here: http://www.jpct.net/forum2/index.php/topic,1462.0.html (http://www.jpct.net/forum2/index.php/topic,1462.0.html)
- ATM I called getpixels in the main thead, aka:
public void init()
{
........
new Thread(this).start();
}
public void paint(Graphics g)
{
super.paint(g);
.....
// render the world onto the buffer:
world.renderScene(buffer);
world.draw(buffer);
buffer.update();
......
buffer.getPixels();
buffer.displayGLOnly();
//output
rendercanvas.repaint();
}
public void run()
{
while (loop)
{
if (mouseoverleftturn && mousedown)
{
turnLeft();
}
else if (mouseoverrightturn && mousedown)
{
turnRight();
}
this.repaint();
try
{
Thread.sleep(16);
}
catch(Exception e)
{
//Don't care...
}
}
}
I assume I should move the getPixels() call out of the paint method and into another thread? If I do that, would it be synchronized with the update method of the buffer?
- It was more a general question, atm I load the 3DS file directly from the server, however the 3DS contains references to textures which don't seem to work. But the textures have to be bumpmapped anyway, so I guess I can't just use the loadobject method and expect it to work :). Will have to put some work in that one :D
-
Yes, move it out of the paint-method. The paint-method is called in the awt event dispatch thread too, which means that calling getPixels() in paint cause jPCT to wait for paint() to complete, which is a bad idea while being inside of paint itself... ;)
If you are calling it from another thread, the call will wait for the next painting and return with the result. Something like this should work:
public void paint(Graphics g)
{
super.paint(g);
world.renderScene(buffer);
world.draw(buffer);
buffer.update();
if (hasToGetPixels) {
new Thread() {
public void run() {
pixels=buffer.getPixels();
}
}.start();
hasToGetPixels=false;
}
if (pixels!=null) {
writePixels(pixels);
pixels=null;
}
buffer.displayGLOnly();
rendercanvas.repaint();
}
Remember to not call getPixels() on each frame. It will cripple performance.
-
Thanks, that's great! Very helpful :)
And no, I don't call it every frame, just copied the relevant parts of the code which made it look that way ;)
-
- It was more a general question, atm I load the 3DS file directly from the server, however the 3DS contains references to textures which don't seem to work. But the textures have to be bumpmapped anyway, so I guess I can't just use the loadobject method and expect it to work :). Will have to put some work in that one :D
I'm still not sure if i got the question right, but the model loaders don't load any textures at all. More information can be found in the wiki: http://www.jpct.net/wiki/index.php/Loading_models (http://www.jpct.net/wiki/index.php/Loading_models)
-
Got it now, the loader only loads the name of the texture and I have to make sure the texture is available in the texturemanager. Sounds simple enough, now I only have to write the pixelshader for bumpmapping.
-
There's a simple bump mapping shader in the wiki as an example. The "problem" is, that jPCT doesn't provide the tangent vectors, which is why the example in the wiki approximates them: http://www.jpct.net/wiki/index.php/Shaders (http://www.jpct.net/wiki/index.php/Shaders)
-
One last question, on intel graphics chips i receive following error:
[ Sun Sep 27 23:38:17 CEST 2009 ] - ERROR: No support for WGL_ARB_multisample
Any idea which parameter causes this?
-
al right, has to do with the sampling mode, how do I find out which sampling modes a card supports?
-
al right, has to do with the sampling mode, how do I find out which sampling modes a card supports?
You can query the driver via LWJGL directly...the problem is, that you can do this only if you already have a valid GL context. For my game Robombs, i'm creating a small native GL window at startup, query the driver and close the window afterwards. But that's not really an option for an applet. To be honest, i would simply ignore the fact that intel's crapsets can't do any proper multi-sampling and ignore the error. In case you can't/don't want to, the actual call to get the information is
boolean canDoAA=GLContext.getCapabilities().GL_ARB_multisample;
This has to be executed in the awt event dispatch thread when using the GLCanvas, i.e. you have to put it into one of the methods that the IPaintListener interface offers. You may try what actually happens when calling this before creating the frame buffer directly in the main thread. Maybe that information is already available then, but i heavily doubt it.
-
I would happily ignore the error if those forementioned crapsets would render anything, however they don't fall back to normal mode.
I'll try to start in normal mode, do one repaint, ask for the capabilities in the paintstarted method and reinitialize the buffer according to the result. Should work i guess?
-
@Override
public void startPainting()
{
if (GLContext.getCapabilities().GL_ARB_multisample)
{
System.out.println("Reinit for multisample");
buffer.dispose();
// create a new buffer to draw on:
buffer = new FrameBuffer(RENDERWIDTH, RENDERHEIGHT, FrameBuffer.SAMPLINGMODE_GL_AA_4X);
buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);
buffer.disableRenderer(IRenderer.RENDERER_OPENGL);
rendercanvas = buffer.enableGLCanvasRenderer();
rendercanvas.setBackground(new Color(34,34,34));
rendercanvas.setSize(RENDERWIDTH, RENDERHEIGHT);
}
buffer.setPaintListener(null);
new Thread(this).start();
}
something like this i guess, but it doesn't work yet. No errors, but also no rendering to be seen :)
-
When using the native gl renderer, this fallback works fine. Maybe there's a problem with GLCanvas when trying the same thing. I'll have a look at that and report back...
-
Looking at the code, i remember the actual problem here. It's this: Before creating the AWTGLCanvas, you can't query the driver for features because you have no context. The context itself is created inside of the canvas' paint method by LWJGL. If the hardware doesn't support the sampling mode, this fails and the canvas calls a method named exceptionOccured, which is the method that prints out the error message you are seeing.
The problem is, that you actually can't change the pixel format afterwards. It's feeded into the constructor of the canvas and goes into a private field. So you end up with a canvas that can't initialize itself properly (but tries again in each iteration...), you are aware of this...but you can't change anything.
I've uploaded a new jpct.jar here: http://www.jpct.net/download/beta/jpct.jar (http://www.jpct.net/download/beta/jpct.jar). In case of this error, it tries to inject a new pixel format into the canvas via reflection, modifies some other fields of the canvas so that it thinks that it's new and makes the canvas reinit itself this way with a proper pixel format in the next paint-call. This is very hacky...and it only works as long as the behaviour of the canvas doesn't change.
Anyway, just give it a try and tell me if it helps.
-
hmmmm, another error:
Java version is: 1.6.0_17
-> support for BufferedImage
Version helper for 1.5+ initialized!
-> using BufferedImage
Software renderer (OpenGL mode) initialized
Software renderer disposed
Using LWJGL's AWTGLCanvas
Software renderer disposed
Loading Texture...textures/floor_select.jpg
Loading Texture...textures/floor.jpg
Loading Texture...icons/turn_right_over.png
Loading Texture...icons/turn_left_over.png
Loading Texture...icons/turn_right_over.png
Loading Texture...icons/turn_left_over.png
Loading Texture...icons/lookdown.png
Loading Texture...icons/lookup.png
Building octree for 8192 triangles!
Octree constructed with 1 nodes / 1 leafs.
Adding Lightsource: 0
Adding Lightsource: 1
[ Sat Nov 21 16:49:44 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
Loading Texture...from Image
[ Sat Nov 21 16:49:52 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
[ Sat Nov 21 16:49:52 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
[ Sat Nov 21 16:49:52 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
[ Sat Nov 21 16:49:52 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
....
-
I've updated the jar with a version that prints out the actual exception message ("No support for WGL_ARB_multisample" isn't the one causing this print out). Judging from the log, i would guess that your lwjgl-version doesn't have the field in AWTGLCanvas where i'm trying to inject the pixel format into. I've used version 2.2.1 (the latest). Maybe it works with that one? The news-section has a link to it.
-
I changed the applet to version 2.2.1 this morning, so it should be using that.
With the normal jpct jar I used before the message is as follows:
[ Sun Nov 21 15:38:18 CEST 2009 ] - ERROR: No support for WGL_ARB_multisample
With the one you gave me this afternoon and lwjgl 2.2.1:
[ Sat Nov 21 16:49:53 CET 2009 ] - ERROR: Unable to recover: No support for WGL_ARB_multisample
I guess it's hopeless :)
Any idea why just recreating the buffer in the ipaintlistener isn't working?
-
Please try the new jar. It can't possibly print out that message but some other. It works fine this way on my Intel based test machine, so something has to be different. We just have to find out, what that is.
-
Are you using an obfuscator or something similar on the jars?
-
I've uploaded the latest version of jwgl, jpct and the applet to the same link:
http://www.freedownloads.be/bloxsystemsapplet/test.html
The jars are not obfuscated.
-
ps: i don't have an intel chipset (always careful not to buy one of those :p) so I have to ask a friend to test it.
-
Damn...it's a security problem with the applet. To inject the new pixel format, i have to access a private field. In an application, i can happily set the field to accessible and everything is fine. In an applet, i'm not allowed to do this. It should work if you sign the jpct.jar, if that's an option.
The IPaintListener solution doesn't work, because it never gets called. The AWTGLCanvas calls my paintGL-implementation (where i'm calling the listener's methods) inside paint...but only of the GL context is valid, which it isn't.
Currently, i see two solutions only: Don't use AA or sign the jpct.jar.
-
Thanks for all your trouble, I really appreciate the builds you made!
I'm just going to make two applets, one that determines the capabilities and launches the complete builder with the correct parameters. Sounds like the best thing to do to make both intel chipset owners and nvidia/ati users happy :).
Thanks again, a final link for your project page is coming your way and I'll make use of the JPCT framework in the future too. When I find time I'll even try to contribute to the wiki ;)