Recent Posts

Pages: 1 [2] 3 4 ... 10
11
Support / Re: Environment Mapping with Software
« Last post by EgonOlsen on February 09, 2018, 12:10:32 pm »
The software renderer doesn't support multiple texture layers. Or at least not in the way in which the hardware renderer does. You could use a different path for the software renderer and use setBlending(true). Then assign three textures to it (diffuse, envmap and envbump) but use a single colored texture with (128/128/128) as color value for the envbump texture. That should give you some kind of blending between diffuse and env.
12
Support / Re: Environment Mapping with Software
« Last post by AGP on February 09, 2018, 01:30:59 am »
Do you have a response?

Also, I know I keep hitting the same keystrokes but, Polyline for the software renderer? It's really very important. I wrote the following class. Even if it worked all of the time, it would still be a bit of a hack...

Code: [Select]
import java.awt.*;
import com.threed.jpct.*;

public class PolylineSoft extends Polyline {
     private SimpleVector[] points;
     public PolylineSoft(SimpleVector[] points, java.awt.Color color) {
super(points, color);
this.points = points;
     }
     public void update(SimpleVector[] newPoints) {
super.update(newPoints);
this.points = newPoints;
     }
     public void draw(Graphics g, Camera cam, FrameBuffer buffer) {
Color oldColor = g.getColor();
g.setColor(super.getColor());
for (int i = 0; i < points.length-1; i++) {
     SimpleVector p1 = Interact2D.project3D2D(cam, buffer, points[i]);
     SimpleVector p2 = Interact2D.project3D2D(cam, buffer, points[i+1]);
     if (p1 == null || p2 == null)
continue;
     g.drawLine((int)p1.x, (int)p1.y, (int)p2.x, (int)p2.y);
}
g.setColor(oldColor);
     }
}
13
Support / Re: Crash (native)
« Last post by AeroShark333 on February 08, 2018, 09:26:41 pm »
To answer your last question: The textures and other native data is using that RAM.
Ah understood.

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device.
Yes, they are fine if the device is rotated

However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer.
Well it is a live wallpaper, and live wallpapers are able to preserve EGL context on pause (or something like that).
https://developer.android.com/reference/android/opengl/GLSurfaceView.html#setPreserveEGLContextOnPause(boolean)
So whenever the device is rotated, onSurfaceChanged(...) is called again, and here I can resize the already existing FrameBuffer to the new width and height.

But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?
I tried that... but the render target won't have the right dimensions then and it will give weird results on screen.
Let's say I start the wallpaper in portrait mode.
I would create a 1440 x 2560 FrameBuffer (width x height)
And at the same time I'd create a 1440 x 2560 NPOTTexture for the render texture.
All fine here.
Now if I change the orientation to landscape, I'd resize the FrameBuffer to 2560x1440 (width x height). (Notice that the values are now swapped)
But the rendertexture is still 1440 x 2560, so I remove this texture from the texturemanager and add a new 2560 x 1440 NPOTTexture.

Removing without unloading did not change anything, still filling memory...

I actually have the feeling that unloading textures does not completely work...
Whenever I open a second live wallpaper instance (using preview) it seems that the textures of that instance aren't unloaded whenever the preview instance is 'killed'.
It is like the primary live wallpaper instance is preventing the other textures to get unloaded or something
(Unless all instances are killed it will all be gone)
14
Support / Re: Ambient Mapping with Software
« Last post by AGP on February 07, 2018, 12:16:18 pm »
Yes, sorry.
15
Support / Re: Ambient Mapping with Software
« Last post by EgonOlsen on February 07, 2018, 10:45:44 am »
Just to clarify this: With "ambient map", you mean the environment map?
16
Support / Re: Crash (native)
« Last post by EgonOlsen on February 07, 2018, 10:44:31 am »
To answer your last question: The textures and other native data is using that RAM.

About the render targets: As long as you don't create a new FrameBuffer, nothing happens for the textures if your rotate the device. However, I've no idea how it's supposed to work that way, because rotating the device should destroy the context (simply because width and height are changing) and so you should need a new instance of the buffer. But anyway...as long as the buffer doesn't change, there's actually no need to unload the render target texture at all. Have you tried what happens if you don't do that at all?
17
Support / Environment Mapping with Software
« Last post by AGP on February 06, 2018, 06:40:35 pm »
One of my ships is shiny. I have a vague memory of talking to you about environment mapping with the software renderer. I fully expected that the environment map would not work with the software renderer, but my expectation was that the diffuse map would be completely replaced by the environment map and that the environment map would be treated as diffuse. This is not so. Ambient map acts like the ambient map but the diffuse channel disappears. To that end, I tried writing the following method. But obviously, the result is that the ambient map is just colored by the diffuse. My question, then, is since the environment mapping is already performing as expected, would it be possible to just make the diffuse channel work with it?

Code: [Select]
     private void combineAmbientAndDiffuse() {
Texture tex = TextureManager.getInstance().getTexture("EnvironmentMap");
tex.add(TextureManager.getInstance().getTexture("Starfighter.png"), .5f);
     }
18
Support / Re: Drawing a Graphic on a Separate Thread
« Last post by AGP on February 06, 2018, 06:36:09 pm »
That makes sense, thanks.
19
Support / Re: Crash (native)
« Last post by AeroShark333 on February 06, 2018, 06:12:48 pm »
Uhm, I'm not sure if the context is lost...
I don't re-initialize the Framebuffer ever (I just use #resize() whenever the device is rotated).

I already had Config.unloadImmediately set to true, which did not work... Setting it to false did not work either unfortunately.
Whenever I don't use a rendertexture but just the FrameBuffer, RAM usage does not increase on screen rotations.

Is there perhaps a rotate function/method possible for rendertextures/NPOTTextures since screen rotations usually just swap the width and the height? (But these rendertextures would hold the same amount of data eventually for the different orientations)
Probably my solution for now would be to create these two rendertextures at start (one with default orientation and one with rotated orientation) and just switch between these two rendertextures.

---

Another thing about my application:
I don't keep my texturedata for rendertextures nor any other texture in VM.
TextureManager.getMemoryUsage() would indeed show that just 1024 bytes is stored by the VM. (Basically nothing)
However, when I use "Runtime.getRuntime().totalMemory() - Runtime.getRuntime().freeMemory()", it would show that there's muuuch RAM usage more by the VM, up to 300 megabytes (by jPCT, I assume). What could be using all the RAM?
20
Support / Re: Crash (native)
« Last post by EgonOlsen on February 05, 2018, 09:50:32 am »
Sorry, I haven't spotted your question ealier. The upload method works only at render time, i.e. if you call unload, it doesn't really unload but waits for the next render call and then does the unloading. That's because it has to happen in the GL thread or otherwise, there's nothing to unload.
If you rotate the device, it might be that the actual context is already lost (or onDrawFrame not called anymore on it) so that the unload never happens but somehow the driver keeps the copy in memory (albeit it shouldn't, because it should be bound to the context and if that changes, it should go away).
If you sure to be in the right thread, you can try to set Config.unloadImmediately to true and see if that helps.
Pages: 1 [2] 3 4 ... 10