16
Support / Re: Texture Limit
« on: February 26, 2014, 10:53:26 am »
Ok, thanks for the information. I'll let you know when I find out more about my specific problem.
News:
Show Posts
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
17
Support / Texture Limit
« on: February 19, 2014, 05:56:25 pm »
Is there a maximum number of textures that one can have? I'm investigating some issues and want to get the easy-to-check things out of the way first =)
18
Support / Re: Multiple entities using the same models/textures.
« on: February 12, 2014, 02:02:14 am »
Wait, would mesh reuse improve the software renderer performance? Or is this only about memory?
19
Support / Re: Advices about possible project
« on: February 12, 2014, 01:57:18 am »
Yes. Look for poly2tri. I hope your polygons don't have edge holes, otherwise it becomes tricky.
20
Support / Re: Rapid Texture loading/unloading
« on: February 11, 2014, 12:46:11 am »
Hehe, always the simple things causing the biggest issues.
Thank you for fixing this so fast!
Thank you for fixing this so fast!
21
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 11:31:07 pm »
After spending so much time tracking this down I have to ask: What was causing it?
22
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 11:16:45 pm »
Great, thank you. That fixes it!
Yes, that was what I figured. Unfortunately because of how I have organized things it's very tricky to do that in the particular case.
Yes, that was what I figured. Unfortunately because of how I have organized things it's very tricky to do that in the particular case.
23
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 10:17:59 pm »
No, that is exactly the problem that I found. I read the doc, but thought that it doesn't apply. Let me explain:
So basically what happens is
addTexture("a", img1);
addObjectWithTexture(obj1, "a");
removeObject(obj1);
removeTexture("a");
addTexture("a", img1);
addObjectWithTexture(obj2, "a");
Note that the texture (when it exists) always contains the same image.
I'm not expecting an object to update, just expecting that it shows any texture (old or new version doesn't matter, they're the same anyway) when I create it and the texture exists in the TextureManager. Instead the object doesn't show a texture.
If you say it's expected I'm happy to add an replaceTexture after the addTexture (as described in the first post) and forget about it.
So basically what happens is
addTexture("a", img1);
addObjectWithTexture(obj1, "a");
removeObject(obj1);
removeTexture("a");
addTexture("a", img1);
addObjectWithTexture(obj2, "a");
Note that the texture (when it exists) always contains the same image.
I'm not expecting an object to update, just expecting that it shows any texture (old or new version doesn't matter, they're the same anyway) when I create it and the texture exists in the TextureManager. Instead the object doesn't show a texture.
If you say it's expected I'm happy to add an replaceTexture after the addTexture (as described in the first post) and forget about it.
24
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 09:41:57 pm »
Here you go.
http://blackflux.com/software/vs/download/?file=BugTestCase.zip
I wanted to simplify it more, but it behalves.. very strange. So I decided to leave it as it is. The non-java files are the textures that are loaded (png images).
Screenshot of the bug: Texture is available but not displayed.
http://blackflux.com/software/vs/download/?file=BugTestCase.zip
I wanted to simplify it more, but it behalves.. very strange. So I decided to leave it as it is. The non-java files are the textures that are loaded (png images).
Screenshot of the bug: Texture is available but not displayed.
25
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 09:05:59 pm »
God... I was finally able to create a test case that reproduces the bug. Cleaning it up now, but will post soon!
26
Support / Re: Rapid Texture loading/unloading
« on: February 10, 2014, 12:45:48 pm »
They are already synchronized. Also the behavior is very consistent and my approach always stops the problem from occurring (in my tests anyway).
The only thing that was multithreaded w.r.t. rendering, world or texture modification is JPCT itself. I just disabled that and the problem still occurs. Will try to get you that test case... (or maybe find my own stupidity while doing so =)
The only thing that was multithreaded w.r.t. rendering, world or texture modification is JPCT itself. I just disabled that and the problem still occurs. Will try to get you that test case... (or maybe find my own stupidity while doing so =)
27
Support / Rapid Texture loading/unloading
« on: February 10, 2014, 12:14:51 pm »
So, I have a problem when rapidly loading and unloading textures in a multithreaded environment with several viewports, worlds, etc
In particular the problem occurs when unloading a texture, then immediately loading it again (same image and name) and creating an object that uses the texture (all without redraw). The texture then appears without the texture and is colored in the setAdditionalColor(...) color. I suspect that the texture doesn't get unloaded from the FrameBuffer. However when I add another object with the same texture "a little bit later" (after redraw), it is textured fine.
I tried to create a simple test case, but no luck. The workaround I have now is that I use
Will this cause a lot of extra load? How bad practice is this?
Thank you!
In particular the problem occurs when unloading a texture, then immediately loading it again (same image and name) and creating an object that uses the texture (all without redraw). The texture then appears without the texture and is colored in the setAdditionalColor(...) color. I suspect that the texture doesn't get unloaded from the FrameBuffer. However when I add another object with the same texture "a little bit later" (after redraw), it is textured fine.
I tried to create a simple test case, but no luck. The workaround I have now is that I use
Code: [Select]
if (textureManager.containsTexture(name)) {
textureManager.replaceTexture(name, texture);
} else {
textureManager.addTexture(name, texture);
textureManager.replaceTexture(name, texture);
}Will this cause a lot of extra load? How bad practice is this?
Thank you!
28
Support / Re: Texture Memory Usage
« on: February 10, 2014, 12:20:49 am »
Thank you! That finally works correctly with my testcase!
What I'm using this for:
Basically the voxel rendering works as following:
(1) A batch of voxel sides (that look into one direction on the same plane) are converted into a polygon.
(2) The polygon is converted into triangles. Each triangle can contain different colors (because it might span more than one voxel). Now we need to find or create a texture that can be used for this triangle.
(3) Complex algorithm determines whether there is an available triangle. If there is not, a new texture is created. It might be beneficial to reorganize textures (this is done with idle capacity). For this reorganization I was estimating the size of the texture by using the dimensions, but that wasn't very accurate. Much cleaner to get the real size (this will even be accurate if you ever update the internal structure of the Texture object).
Why do I even bother with this? Well, if voxel contain only a single color it's no problem at all. But they can also be textured and in that case you run out of memory faster than you can say "Texture".
What I'm using this for:
Basically the voxel rendering works as following:
(1) A batch of voxel sides (that look into one direction on the same plane) are converted into a polygon.
(2) The polygon is converted into triangles. Each triangle can contain different colors (because it might span more than one voxel). Now we need to find or create a texture that can be used for this triangle.
(3) Complex algorithm determines whether there is an available triangle. If there is not, a new texture is created. It might be beneficial to reorganize textures (this is done with idle capacity). For this reorganization I was estimating the size of the texture by using the dimensions, but that wasn't very accurate. Much cleaner to get the real size (this will even be accurate if you ever update the internal structure of the Texture object).
Why do I even bother with this? Well, if voxel contain only a single color it's no problem at all. But they can also be textured and in that case you run out of memory faster than you can say "Texture".
29
Support / Re: Texture Memory Usage
« on: February 09, 2014, 01:33:36 pm »
Works ok if you're working with large textures. However very inaccurate if you're working with many small textures (<=16x16).
Just found this method. Will TextureManager.getInstance().getMemoryUsage(true) produce an accurate result in the software renderer?
Edit: Mhmm, no that seems to consider removed textures as well. Would it be possible to add this functionality to the Texture object to determine how much memory it uses?
Just found this method. Will TextureManager.getInstance().getMemoryUsage(true) produce an accurate result in the software renderer?
Code: [Select]
public long getMemoryUsage(boolean paramBoolean) {
long l = 0L;
for (int i = 0; i < this.textureCount; i++) {
int[] arrayOfInt1 = this.textures[i].texels;
int[] arrayOfInt2 = this.textures[i].alpha;
if (arrayOfInt1 != null) {
l += (arrayOfInt1.length << 2);
}
if (arrayOfInt2 != null) {
l += (arrayOfInt2.length << 2);
}
if ((!paramBoolean) && (arrayOfInt1 == null)) {
l += (this.textures[i].width * this.textures[i].height << 2);
}
}
return l;
}Edit: Mhmm, no that seems to consider removed textures as well. Would it be possible to add this functionality to the Texture object to determine how much memory it uses?
30
Support / Texture Memory Usage
« on: February 09, 2014, 07:02:27 am »
Is there an easy way to determine the texture memory usage in the software renderer? Trying to optimize textures and the would be quite helpful.