For my game I have large spatials (sectors of 32x128x32 tesselated blocks) that are generated asynchronously and that have to be attached to the main node. Currently I just add them by basically doing mainNode.attachChild(sectorNode); in the update loop. This of course creates a tiny lag every time a sector comes online. Is there a more optimal way to attach the sector to the main node? Some best practice? I figure that the
Another thing I’m asking my self is: if I create multiple matrials using partly the same textures (in this case for lighting) - are these equal textures stored n times in the graphic card’s memory or just once?
If you add only one sector per frame then there should not be that big of a dip. If you add many sectors per frame then… don’t do that. Limit the adding to one sector per frame. Same with removals. I found that one add and one remove per frame was about all I could get away with without noticeable hiccups.
Note: mitigating circumstances are if your bounding shape calculation is relatively expensive of if you somehow cause the collision shape to be calculated. In Mythruna, I have bypassed both of those things because my bounding shape does not need to be calculated (it’s constant) and I do not use JME collision for my terrain.
@pspeed said:
If you add only one sector per frame then there should not be that big of a dip. If you add many sectors per frame then... don't do that. Limit the adding to one sector per frame. Same with removals. I found that one add and one remove per frame was about all I could get away with without noticeable hiccups.
Thanks - that's the next thing I will try :)
@pspeed said:
Note: mitigating circumstances are if your bounding shape calculation is relatively expensive of if you somehow cause the collision shape to be calculated. In Mythruna, I have bypassed both of those things because my bounding shape does not need to be calculated (it's constant) and I do not use JME collision for my terrain.
After testing your game - I figured that you did the collision yourself ;). I was also thinking of doing that - I have even created half a physics engine and read a lot about AABB and OBBs, split planes, ... very interesting - but I tend to stick with jbullet because it also has the ability to add a rotation momentum when two objects hit - my physic engine doesn't have that ability yet and I think it would rather be complicated to implement that correctly ;) At least my first tests indicate that ...
Yeah, I don’t recommend writing your own full physics engine. That’s officially HARD. Actually, the momentum, etc. part is not so bad… it’s proper collision resolution and restitution that is tricky. Stacking boxes and so on.
But I think the collision detection data I’m talking about is different than the stuff bullet uses… but I may be wrong. The stuff I’m talking about is if you use spatial.collidesWith().
@entrusc said:
By the way - how do you set the bounding shape to be constant? Simply assign one? On the other hand I use this value for the laser ;)
For my mesh, I subclassed Mesh to return a constant bounding box. All of mine are always 32x32x32 so there was no reason to have JME manually recalculate it. Since I break up my world vertically I still get reasonably good culling performance even with a constant bounding box. You probably would, too. Lasers or not.
@pspeed said:
For my mesh, I subclassed Mesh to return a constant bounding box. All of mine are always 32x32x32 so there was no reason to have JME manually recalculate it. Since I break up my world vertically I still get reasonably good culling performance even with a constant bounding box. You probably would, too. Lasers or not.
I tried that and it seems to work - but no significant improvment in speed - and still laggy. Even with sequential frame by frame attachment. But after some more testing I found out that my shader seems to be responsible. It starts to lag when you turn around just to suddenly adapt and then run smoothly - don't know if this is some kind of grafic card optimization or sth. If I use a normal jME-Shader everything runs smoothly. I think I have to conduct further tests to figure out what the problem is ;)
turns out that if I comment out my sampler2DArray in the shader the jittering is gone … and I just implemented it so I could use multiple textures with bilinear minification without smearing into other textures …
After much more testing I suddenly realized what the problem was: the mipmapping - if I disable it the jittering stops. I think it’s because the mipmap is calculated for every sector - but once it’s done everything runs smoothly. I will now read a bit about mipmapping and then implement it myself so that it is only done once in software at world startup. Furthermore maybe I can get rid of the sampler2DArray completely - then moebius would be fully compatible with OS X again
@Momoko_Fan said:
I recommend preloading all your textures during loading, you can use RenderManager.preload() to do this.
Cool - didn't know that this feature existed. Will try it out later today! Meanwhile I implemented my own mipmapping and it's really smooth. But of course I'd rather use the hardware mipmapping if possible :)
By the way: can anyone answer my second question:
@entrusc said:
2. Another thing I'm asking my self is: if I create multiple matrials using partly the same textures (in this case for lighting) - are these equal textures stored n times in the graphic card's memory or just once?
Example: I have 3 Materials m1, m2, m3 and each of these materials have textures(t1, t2, t3) assigned to them so m1 has t1, m2 has t2 and m3 has t3. If I now add to ALL of them the same texture t4 - will t4 be duplicated three times and every material holds a copy of it or are they all holding just a pointer to the same texture in gpu memory? I would assume the latter but I'm not 100% sure.
@Momoko_Fan said:
The actual image data is shared, whereas the texture (parameters) are not.
Its the same relationship as Geometry -> Mesh as Texture -> Image.
