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.


Messages - AeroShark333

Pages: 1 ... 3 4 [5] 6 7 ... 12
61
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: January 06, 2017, 02:13:51 pm »
Basically like in this fragment shader:
Code: [Select]
precision highp float;
precision highp int;

uniform sampler2D textureUnit0;
uniform sampler2D textureUnit1;
uniform sampler2D textureUnit2;
uniform sampler2D textureUnit3;
varying vec2 texCoord0;

void main() {
float xVal = texCoord0.x;
float yVal = texCoord0.y;

vec4 base;

if(xVal < 0.5){
// tex0 or tex2
if(yVal < 0.5){
// tex0
base = texture2D(textureUnit0, vec2(xVal*2.0,yVal*2.0));
}else{
base = texture2D(textureUnit2, vec2(xVal*2.0, yVal*2.0 - 1.0));
}
}else{
// tex1 or tex3
if(yVal < 0.5){
// tex1
base = texture2D(textureUnit1, vec2(xVal*2.0 - 1.0,yVal*2.0));
}else{
// tex3
base = texture2D(textureUnit3, vec2(xVal*2.0 - 1.0,yVal*2.0 - 1.0));
}
}

gl_FragColor = base;
}
It works but it kind of looks ugly around the borders of the textures...
I actually used texture.setClamping(true) so not 'false' to make it look better around the borders which kind of worked.
But it only looks better for higher resolution textures.
Let's say I have 4 lower resolution textures, then these borders become visible again which I don't really want. (it should just work like a single texture)

See attachment for clarification :)

62
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: January 05, 2017, 11:11:30 pm »
I wanted to optimize texture loading so I tried splitting the texture into 4 parts.
So a 8192x4096 texture now is 4 * 4096x2048 textures.

So why split?: Because I'll be uploading the texture after it has loaded and textures use a lot in VM memory and I thought this would be a nice solution to split the textures, so the VM memory doesn't go up as much as with a complete texture...

I added these 4 textures to the Object3D and in the shader I'd use the texcoords to select which texture to use (and change the texcoords so it draws the texture properly on the Object3D's vertices)...
However, the results seem kind of ugly and it's not as I hoped it would be... Using a complete texture in the shader looked better than 4 split textures. texture.setClamping(false) helped but it's still kind of visible on the Object3D that the textures are split...

Is there some way to merge these 4 textures into 1 texture without the Bitmap stuff in Android since that obviously just uses memory? The textures are immediately uploaded after loading so the VM memory only 'spikes' up when the Bitmap instance is still used for uploading...
I suppose jPCT and OpenGL see these textures as texture layers but actually they're just next to each other.

63
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 27, 2016, 10:36:08 pm »
My version:
Code: [Select]
import com.threed.jpct.Camera;
import com.threed.jpct.FrameBuffer;
import com.threed.jpct.Interact2D;
import com.threed.jpct.Object3D;
import com.threed.jpct.RGBColor;
import com.threed.jpct.SimpleVector;
import com.threed.jpct.Texture;
import com.threed.jpct.TextureManager;
import com.threed.jpct.World;

/**
 * A simple lens flare effect. You need five different textures for this, one burst and four halos. How
 * to create/get these textures is up to you. jPCT doesn't come with any.
 * @author EgonOlsen & AeroShark333
 */
public class CustomLensFlare implements java.io.Serializable {
private static final long serialVersionUID = 1L;

private final SimpleVector sunPos;

private final Texture[] types;
private final float[][] scales;

private float globalScale=1;
private float burstScale=1;
private int trans=1;
private int burstTrans = 1;

private boolean cover=true;
private float maxDistance=-1;
private boolean revertDirection=false;

private boolean visible=false;
private SimpleVector light2D=null;

private final SimpleVector tmp1;
private final SimpleVector tmp2;
private final SimpleVector tmp3;

/**
* Create a new lens flare for a light source.
* Note: call initializeLensFlare(String texturenames...) before using this LensFlare
* @param lightPos the position of the light source
*/
public CustomLensFlare(final SimpleVector lightPos) {
this.sunPos=new SimpleVector(lightPos);
this.types=new Texture[7];

scales = new float[7][2];
scales[0][0]=1;
scales[0][1]=1;
scales[1][0]=2;
scales[1][1]=0.5f;
scales[2][0]=3;
scales[2][1]=0.25f;
scales[3][0]=8;
scales[3][1]=1;
scales[4][0]=-2;
scales[4][1]=0.5f;
scales[5][0]=-4;
scales[5][1]=0.25f;
scales[6][0]=-5.5f;
scales[6][1]=0.25f;

tmp1=new SimpleVector();
tmp2=new SimpleVector();
tmp3=new SimpleVector();
}
/**
* Create a new lens flare for a light source.
* @param lightPos the position of the light source
* @param burst the name of the burst texture as added to the TextureManager
* @param halo1 the name of the first halo texture as added to the TextureManager
* @param halo2 the name of the second halo as added to the TextureManager
* @param halo3 the name of the third halo texture added to the TextureManager
* @param halo4 the name of the fourth (repeating) halo texture added to the TextureManager
*/
public CustomLensFlare(final SimpleVector lightPos, final String burst, final String halo1, final String halo2, final String halo3, final String halo4) {
this(lightPos);
this.initializeLensFlare(burst, halo1, halo2, halo3, halo4);
}

/**
* Call this when you are sure the textures needed for this lensflare have been set
* @param burst the name of the burst texture as added to the TextureManager
* @param halo1 the name of the first halo texture as added to the TextureManager
* @param halo2 the name of the second halo as added to the TextureManager
* @param halo3 the name of the third halo texture added to the TextureManager
* @param halo4 the name of the fourth (repeating) halo texture added to the TextureManager
*/
public void initializeLensFlare(final String burst, final String halo1, final String halo2, final String halo3, final String halo4){
final TextureManager tm=TextureManager.getInstance();
final Texture repeatedHalo=tm.getTexture(halo4);

types[0]=tm.getTexture(burst);
types[1]=tm.getTexture(halo1);
types[2]=repeatedHalo;
types[3]=tm.getTexture(halo2);
types[4]=repeatedHalo;
types[5]=tm.getTexture(halo3);
types[6]=repeatedHalo;
}

/**
* Sets the transparency of the effect.
* @param trans the transparency. 0 is lowest,
*/
public void setGlobalTransparency(int trans) {
this.trans=trans;
}

/**
* Sets the transparency of the burst effect.
* @param trans the transparency. 0 is lowest,
*/
public void setBurstTransparency(int trans) {
this.burstTrans=trans;
}


/**
* Sets a new light position.
* @param lightPos the new position
*/
public void setLightPosition(SimpleVector lightPos) {
sunPos.set(lightPos);
}

/**
* Sets the burst scale of the effect.
* @param scale the scale
*/
public void setBurstScale(float scale) {
burstScale=scale;
}

/**
* Sets the global scale of the effect.
* @param scale the scale
*/
public void setGlobalScale(float scale) {
globalScale=scale;
}

/**
* If true (default), all geometry that is a potential collider hides the effect if it's located in
* a direct line between the camera and the light source.
* @param hides should geometry hide it or not?
*/
public void setHiding(boolean hides) {
cover=hides;
}

/**
* If hiding is enabled, this value specifies how far away from the camera a polygon can maximally be
* to be considered as a blocker. Anything farer away can't hide the effect. Lowering this value can improve
* performance but may lead to flares where non should be. -1 is default, which means no limits.
* @param distance the distance
*/
public void setMaximumDistance(float distance) {
this.maxDistance=distance;
}

/**
* If hiding is enabled, the visibility calculations can be done camera->light (default) or light->camera. Depending
* on the scene, one or the other will be faster.
* @param lightToCam do it light->camera or vice versa
*/
public void setDirection(boolean lightToCam) {
revertDirection=lightToCam;
}

/**
* Updates the lens flare. Skipping this method and calling render only will cause the lens flare to remain static.
* This method should be called if either the camera or, if hiding is enabled, the hiding objects are moving.
* @param buffer the frame buffer
* @param world the world
*/
public void update(FrameBuffer buffer, World world) {
Camera cam=world.getCamera();
light2D=Interact2D.project3D2D(cam, buffer, sunPos, tmp3);
visible=true;
if (cover) {
SimpleVector camPos=cam.getPosition(tmp1);
if (!revertDirection) {
// From camera to light
SimpleVector delta=camPos;
tmp2.set(camPos);
delta.scalarMul(-1);
delta.add(sunPos);
float dlen=delta.length();
float dist=world.calcMinDistance(tmp2, delta.normalize(delta), maxDistance!=-1?Math.min(maxDistance, dlen*1.05f):dlen*1.05f);
//System.out.println("1: "+ dist+"/"+(dlen-5));
visible=(dist==Object3D.COLLISION_NONE || dist>dlen-5);
} else {
// From light to camera
tmp2.set(sunPos);
tmp2.scalarMul(-1);
SimpleVector delta=camPos;
delta.add(tmp2);
float dlen=delta.length();
float dist=world.calcMinDistance(sunPos, delta.normalize(delta), maxDistance!=-1?Math.min(maxDistance, dlen*1.05f):dlen*1.05f);
visible=(dist==Object3D.COLLISION_NONE || dist>dlen-5);
//System.out.println("2: "+ dist+"/"+(dlen-5));
}
}
}

/**
* Renders the effect.
* @param buffer the frame buffer
*/
public void render(FrameBuffer buffer) {

if (light2D!=null && visible) {
SimpleVector lp=tmp1;
lp.set(light2D);
float mx=buffer.getCenterX();
float my=buffer.getCenterY();
lp.z=0;
SimpleVector cp=tmp2;
cp.set(mx,my,0);
cp.scalarMul(-1);
lp.add(cp);
SimpleVector dir=lp;
float len=dir.length();
dir=dir.normalize(dir);
SimpleVector d=tmp2;
d.set(0, 0, 0);

for (int i=0; i<types.length; i++) {
d.set(dir);
Texture t=types[i];
float l=scales[i][0];
float scale=scales[i][1]*(i==0? burstScale:globalScale);
int trans2 = (i==0? this.burstTrans:this.trans);
d.scalarMul((1f/l)*len);
int tw=t.getWidth();
int th=t.getHeight();
int x=(int)(d.x-((tw>>1)*scale))+(int)mx;
int y=(int)(d.y-((th>>1)*scale))+(int)my;
int dw = (int)((float)tw*scale*0.5f);
int dh = (int)((float)th*scale*0.5f);
// upper-left
buffer.blit(t, 0, 0, x, y, tw, th, dw, dh, trans2, true, RGBColor.WHITE);
// upper-right
buffer.blit(t, 0, 0, x+2*dw, y, tw, th, -dw, dh, trans2, true, RGBColor.WHITE);
// bottom-left
buffer.blit(t, 0, 0, x, y+2*dh, tw, th, dw, -dh, trans2, true, RGBColor.WHITE);
// bottom-right
buffer.blit(t, 0, 0, x+2*dw, y+2*dh, tw, th, -dw, -dh, trans2, true, RGBColor.WHITE);
}
}
}
}

I hope it's okay to share this; if not then I guess you can delete my post :P
This modified class should be suitable for circular shaped lensflare textures.
So your texture images can be reduced to this part of the circular texture image: http://etc.usf.edu/clipart/40500/40550/pie_01-04n_40550_lg.gif :)
I guess the original lens flare textures don't take up that much memory anyway but oh well...

64
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 25, 2016, 04:16:16 am »
I see, thanks for answering :)
And eh, nevermind the 16k resolution textures...
I guess I just got curious there

I have a small request however...
May I have the source code of the LensFlare class, learn from it, modify it and use it? (I'll probably end up writing my own class then)
So why?...
Well there's a few things I want to change/add I guess:
-> I want to use 5 textures in total
-> I don't want the burst texture to be repeated in the lens flare (that's where the 5th texture comes in)
-> I want to give the burst it's own scaling which isn't done with the global scaling
-> I don't really know how to get the 2D coordinates for blitting from this 3D world
-> I want to use 1/4th part of a 'complete texture'

My lens flare images are all spherical so...
I basically could just use 1/4th of this texture and blit it 4 times (by flipping the blit). (relying on the assumption that the LensFlare class uses blits and not it's own Object3D's)

And Merry Christmas by the way :D

65
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 22, 2016, 04:55:23 am »
What will preWarm() do if a Texture has already been uploaded to the GPU? Nothing I suppose?
And what about Textures that will only be blit? Those don't need to be uploaded, do they? :|
Is there some way to not make them get uploaded in case they do?

_________________________

I wondered about something else as well:
Code: [Select]
// Test zone
IntBuffer max = IntBuffer.allocate(1);
GLES20.glGetIntegerv(GLES20.GL_MAX_TEXTURE_IMAGE_UNITS, max);
Log.d("e3d-tag","Texture units (shader): " + max.get());

max = IntBuffer.allocate(1);
GLES20.glGetIntegerv(GLES20.GL_MAX_TEXTURE_SIZE, max);
Log.d("e3d-tag","Texture size: " + max.get());

max = IntBuffer.allocate(1);
GLES20.glGetIntegerv(GLES20.GL_MAX_COMBINED_TEXTURE_IMAGE_UNITS, max);
Log.d("e3d-tag","Texture units (shaders): " + max.get());

Output:
D/e3d-tag(31156): Texture units (shader): 16
D/e3d-tag(31156): Texture size: 16384
D/e3d-tag(31156): Texture units (shaders): 96

So I read somewhere that jPCT-AE supports up to 8192x8192 pixels textures; what happens if I try 16384x16383 since my device seems to support it...?
And I don't understand these texture units values...
The first output line is for the texture units available to the fragment shader I thought...
And the third line for the texture units available for the fragment shader AND vertex shader combined, right?
So does this apply for one Object3D or for all?
And how does it work when a Texture is shared between Object3D's, is there something I need to keep in mind?

_________________________

And another side question: Will there be support for OpenGLES 3.0 someday maybe?

66
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 21, 2016, 12:19:00 pm »
Euh, so instantly uploading textures to the GPU wouldn't be possible? With a Bytebuffer InputSteam from a Bitmap image then maybe?

I tried TextureManager.preWarm(fB); but it didn't seem to upload all Textures that I needed... Some were uploaded only when the first World.draw(fB); call was made

67
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 19, 2016, 07:07:12 pm »
Using the Virtualizer class would significantly slow down loading time, right?
Especially with big resolution textures...?

Sooo, I tried this with my live wallpaper:
Code: [Select]
gLView.setPreserveEGLContextOnPause(true);And it seems to work fine I guess; even when not keeping textures in VM.

When the context changes, it seems that the GLSurfaceView and Renderer will get disposed and will get recreated.
Textures will be reuploaded so that's fine I guess.
Context changes aren't supposed to happen anyway I think, but it seems to happen in the Live Wallpaper picker for some reason when changing the orientation...
While context changes do not seem to happen, when applied in a certain launcher and then changing the orientation.

So now I basically only load textures when the Live wallpaper is launched (and on context changes).
This loading process is a one time thing only but it does seem to take up some time...
Also I noticed that when I'm adding textures to the texturemanager, the VM copy is still kept until the texture is actually used on a visible Object3D in a World.draw() call.

Is it somehow possible to upload textures to the GPU immediately when the texture is added to the texturemanager? (except the textures that are only being blit since I guess they don't need to be uploaded to the GPU...)
So I thought this would be possible by using a world.draw() call after an Object3D with a texture is added to the world.
But then it also needs to be visible in order to get the texture uploaded to the GPU; So is there some way to make all objects in my world 'visible'?
Sooner or later all my objects are visible anyway...

So how it now works:
[add Texture to texturemanager -> apply Texture to Object3D -> add Object3D to world -> world.draw() -> rendering starts -> after a few seconds there is a hiccup because the added Object3D has become visible -> uploading texture to GPU -> continue rendering]
And what I want:
[add Texture to TextureManager (as VM copy) -> apply texture to Object3D -> add Object3D to world -> upload texture to GPU -> rendering starts]
I think I could possibly achieve this my pointing the camera at the Object3D so it becomes visible:
[add Texture to TextureManager (as VM copy) -> apply texture to Object3D -> add Object3D to world -> make Camera face the Object3D -> upload texture to GPU -> rendering starts]

And since I guess I never actually really need a VM copy of these textures anyway (but only for the initial uploading), would it be possible to upload textures to the GPU immediately from a given InputStream (of a .png file)? (I suppose this would save VM memory...)

So what I originally wanted:
[add Texture to TextureManager (as VM copy) -> apply texture to Object3D -> add Object3D to world -> upload texture to GPU -> rendering starts]
What I would want now:
[apply Texture PNG-InputStream to Object3D (no VM copy of the Texture) -> add Object3D to world -> upload texture to GPU using PNG-InputSteam -> rendering starts] (or perhaps a bitmap byte-inputstream if that works better...)
Basically what I want to achieve here is that I don't want a Texture to take up VM memory if the VM copy of the Texture gets disposed after uploading anyway...

68
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 08, 2016, 04:11:31 pm »
Hmmm, so I did some testing... And I wondered, why can jPCT not use the uploaded textures in the GPU when the context has changed? After all... the 2D texture images don't change, right?

69
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 06, 2016, 03:53:23 am »
Well I'm using high resolution textures and VM memory is pretty limited on Android devices...

70
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 03, 2016, 04:44:52 pm »
Does jPCT automatically 'discard' these VM copies? Or do I have to do this myself?
If so, how?

71
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 02, 2016, 11:36:48 pm »
I guess I understood that, but aren't there scenarios when textures don't have to be re-uploaded? (so the textures don't need to stay in VM any more, right?)
So isn't it possible to clear the texture data in VM? Setting the texture data instances to null I suppose, so the GC can pick it up...

72
Support / Re: Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 01, 2016, 08:38:41 pm »
Hmmm, well (re-)uploads seem like the most time-consuming task, especially with bigger textures I suppose...?
I don't know if jPCT still re-uploads Textures that are actually still in the GPU with keepPixels enabled... (seems pretty useless to me? I don't know)
Hmhm, why wouldn't it be worth it? I don't really completely understand it I guess.

73
Support / Why does jPCT-AE need to keep the texture in the VM memory?
« on: December 01, 2016, 04:59:09 am »
Hello,

Well I guess the title explains all...
I wondered because when textures get uploaded to the GPU (even when pixeldata is kept so it should be safe for any context change) why does it still need the texture data in the VM memory?

Is it possible to not have the textures in VM memory but uploaded to the GPU only?

Cheers,
AeroShark333

74
Support / Re: Blitting in VR display happens on left eye only
« on: November 17, 2016, 02:55:54 pm »
About the not centered issue, you probably need to correct your placement with (the destination height)/2 and the same for the width I'd say.
So: fb.getWidth()/2-destinationWidth/2
(not sure whether you need to subtract or add, I guess you'll find out if you try it)
destinationWidth being the amount of pixels your blit will take in width.

fb.blit(reticleTex, 0, 0, fb.getWidth()/2+290, fb.getHeight()/2, 256, 256 ,64, 64, 2, false);
Why are your arguments "64, 64" here? And "128, 128" in the other?:
And why "+290", it might look okay on your phone but I doubt placement would look good on phones with other screen resolutions! :p

75
Projects / Re: Naroth - 3D open world RPG
« on: October 27, 2016, 07:22:25 pm »
Hmmm, well yeah I wanted to help to do something back to this community. I've learned quite a lot here and I've been using jPCT-AE for some of my apps :D
Not completely sure if it's needed, but well... not everyone in the Netherlands has amazing English skills but the English language is quite well implemented in the Dutch education system.
But the online tool sounds alright to me :)

Pages: 1 ... 3 4 [5] 6 7 ... 12