www.jpct.net
jPCT - a 3d engine for Java => Support => Topic started by: raft on October 20, 2009, 04:53:08 pm
-
hi,
i've adapted new version of jPCT to karga. (not online yet) and been playing with mipmapping and multi threading. multi threading definetely increases fps one multi core machines :) mipmapping works almost identical to previous external MipMapper and i guess performs slightly better. and of course much easier to use. great job :)
however after some time, some of my textures are gone. it's like we have added an object with a missing texture. below are two shots:
(http://img99.imageshack.us/img99/5474/screenshotkargatheother.png)
(http://img99.imageshack.us/img99/235/screenshotkargatheotherw.png)
i cannot regularly reproduce it, but i can say it happens with multi cores, mipmapping enabled and MOSTLY while resizing the window (creating a new FrameBuffer). i guess it's a multi-threading issue
any ideas ?
r a f t
-
Strange...i'm pretty sure that it's a multi-threading problem. I just can't figure it out ATM. Obviously, the textures are there, just blank. Because otherwise, it would give you a null pointer or similar. Are you by any chance getting some messages like "Could not grab pixels from image!" or something similar?
-
i've just retried it, it happened again and no, nothing is printed.
-
Does it go away without multi threading and/or mip mapping used?
-
And are you calling dispose() on the old framebuffer and/or are disabling the renderer on it before it goes out of scope when creating a new one? If not, please add that. If it still doesn't help, please give this jar a try: http://www.jpct.net/download/beta/jpct.jar (http://www.jpct.net/download/beta/jpct.jar)
-
it happened single threaded and mipmapping disabled :/
are both FrameBuffer.dispose and disable renderer necessary ? looking at the code, i call most of the time dispose but not disable renderer..
-
onfortunately neither helped. i also tried the new jar. i dispose the buffer with:
buffer.disableRenderer(IRenderer.RENDERER_SOFTWARE);
buffer.dispose();
buffer = null;
maybe this may give you a clue: once this happens, recreating the buffer doesnt help, missing textures remains missing..
-
Are you using that advanced blitting method (that one what supports scaling and such)? It looks like as if somehow the textures are replaced by the dummy texture. Can you replace the dummy texture with something else (for example a Texture with the word "dummy" on it) by using setDummyTexture(<Texture>) in the TextureManager to see, if this really is the dummy texture or something else!?
-
no, i do not use blitting at all. i'm happy with swing for such things :)
it's definetely the dummy texture, i replaced the dummu texture with:
BufferedImage image = new BufferedImage(256, 256, BufferedImage.TYPE_INT_ARGB);
Graphics2D g2d = image.createGraphics();
g2d.setColor(Color.WHITE);
g2d.fillRect(0, 0, 256, 256);
g2d.setColor(Color.BLACK);
for (int i = 0; i < 120; i+= 10) {
g2d.drawRect(i, i, 256-2*i, 256-2*i);
}
g2d.dispose();
return new com.threed.jpct.Texture(image);
and the result is:
(http://img99.imageshack.us/img99/5548/screenshotkargatheothers.png)
an interesting detail is, it always happens to same objects. seldomly on the village to center area and to banks over there, and mostly all of the mushroom club itself.
hope this helps..
r a f t
-
How are you handling textures in Karga? Are they loaded once at the beginning, are they added at runtime or even removed? Actually, there aren't much locations in the code that make use of the dummy texture. replaceTexture() is one of them. Any chance that your own mip mapping code is still active somehow (just to be sure...)?
-
How are you handling textures in Karga? Are they loaded once at the beginning, are they added at runtime or even removed?
both. scene textures are loaded when world is first created, avatar textures are created/added/replaced on demand. remember, users can change dress in karga, most of which is done by creating texture combinations on the fly..
Any chance that your own mip mapping code is still active somehow (just to be sure...)?
i didnt remove my MipMapper code. but it's disabled. to make sure i put some breakpoints and none suspended..
-
i've found it :) i had overriden World.dispose() and there clear textures specific to that world by name. World.dispose is called when the scene changes. you had a finalizer method in World and you call dispose there too. when that finalizer runs, textures with same name of current world is replaced by dummy texture ::) that mostly happens when resizing window since a call System.gc() after disposing previous FrameBuffer. that's the whole story ;)
i can put a guard to prevent double disposing, but i guess you should do the same. ie: put an internal disposed flag to world.
regards,
r a f t
-
I dimly remember adding that finalize-method, because there was some memory leak otherwise when people forget to dispose the world. Too bad that i can't use weak references to stay compatible with 1.1. I've updated the jar above with a version that hopefully prevents double disposing.
Nice bug btw... ;D
Edit: This is the source of all problems: http://www.jpct.net/forum2/index.php/topic,1110.0.html (http://www.jpct.net/forum2/index.php/topic,1110.0.html) (well, maybe not of all...)
-
thanks. i've also prevented it in my code. well if i were you, i had dismissed 1.1 support long time ago. lucky jPCT users i'm not you ;)
btw, is there a lighting change ? looking at the change log, i can only see a default ambient ligt change which shouldn't effect me, since i explicitly set ambient light.
this is how village looks before (not sure but i guess jPCT 1.17) this is still the online version
(http://img230.imageshack.us/img230/789/oldlight.png)
this is how it looks with 1.19.
(http://img38.imageshack.us/img38/192/newlight.png)
especially the skybox looks darker. it's another world instance rendered to same frame buffer with an ambient light 255,255,255.
what do you think, my fault or ?
-
Actually no...i did a comparision of the light calculations back to mid-2007 and i can't find anything that should cause this. Maybe you are calling compile() on objects? That will implicitly set Config.lightMul to 1 (instead of 10, which is default) and doesn't make any sense when using the software renderer either.
-
Maybe you can try 1.18 instead and see if it happens there too: http://www.jpct.net/download/jpctapi_118.zip (http://www.jpct.net/download/jpctapi_118.zip)
-
i've made a search and found no compile() call.
1.18 is same as 1.19. 1.17 is working fine (i've that version and tried).
my render method is like this:
buffer.clear();
if (skyBox != null) {
skyBox.renderScene(buffer, world.getCamera().getBack());
skyBox.draw(buffer);
buffer.clearZBufferOnly();
}
world.renderScene(buffer);
world.draw(buffer);
buffer.update();
where SkyBox.renderScene is
public void renderScene(FrameBuffer buffer, Matrix matrix) {
world.getCamera().setBack(matrix);
world.renderScene(buffer);
}
and SkyBox.draw is
public void draw(FrameBuffer buffer) {
world.draw(buffer);
}
see any flaw ?
-
Looks fine to me. The only light related change that i can see in my code shouldn't show this effect nor do i have ever experienced something like this in my tests...strange...
Can you provide me with a test case for this? When i'm back home, i'll upload a jar that reverts the change to see if this does any good.
-
i will try to when i get home
-
OK...i've updated the jar at http://www.jpct.net/download/beta/jpct.jar (http://www.jpct.net/download/beta/jpct.jar) with a version that takes back the change in the lighting calculation. I really doubt, that this will show any effect, but it's worth a try anyway.
-
no, it didnt help. i will try to setup a test case..
-
Egon, i've sent you a test case with email..
-
No mail so far...maybe my spam filter eated it!? I've whitelisted both, your gmail-account and aptalkarga.com now. Could you please try again?
Edit: Got it. Took some time but it finally arrived. I'll look into it now.
-
Found it! As usual, it's not a bug...it's a feature. To be exact, it's this (from the change log of 1.18): "The 3ds- and obj-loaders now load transparency information."
Your sky has a transparency value of 100 for whatever reason. The loader now loads this information. That, combined with the way how transparency works in the software renderer, cuts the light intensity in half on the sky. Just add a
sky.setTransparency(-1);
and it should look better.
-
thanks, this solved my problem :)