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.


Topics - mech

Pages: [1]
1
Support / A few notes and questions on FrameBuffers (and other stuff)
« on: March 07, 2013, 08:30:57 am »
When developing with jpct-ae I noticed the following:
  • someFramebuffer.display() is not required for a Galaxy SIII, Tegra 3 GPUs seem to require it on the other hand
  • The .display() method does not trigger a screen refresh, only after .onDrawFrame() finished the screen will refreshed, this is troublesome when blitting a loading screen that only should be blitted once because the logic behind the actual loading has to happen in the frame AFTER the blitting. This is probably because of GLSurfaceView, see http://developer.android.com/reference/android/opengl/GLSurfaceView.html for more details.
    Alternativly do the loading outside the render thread, this is discouraged (see jpct documentation)
  • All rotation is done using radians this is nothing bad, but not noted in many places.
  • According to the documentation http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Config.html#nearPlane the near clipping plane is 1 at default, may want to set this to 0.1 if you use the coordinates as meters, else clipping might happen pretty soon if you use a camera for first person view
  • A solution for android picture rescaling, this will spare you the time and RAM needed for resizing loaded textures, all examples on the jpct wiki use a strange way of letting Android rescale a picture then rescale it back and the convert it to textures this is unnecessary complex.
Code: [Select]
package com.example.game.loaders;

import android.graphics.Bitmap;
import android.graphics.BitmapFactory.Options;

/**
 * Contains necessary options to load files correctly with the BitmapFactory
 */
public class BitmapLoadOptions extends Options{
/*Constructor*/
public BitmapLoadOptions(){
this.inPreferQualityOverSpeed = true; //We have the time to load the textures
this.inScaled = false; //Don't scale the textures to fit dpi, this would result in non power of 2 textures which are rejected by JPCT
this.inJustDecodeBounds = false; //Decode the actual data instead of just looking for the boundaries
this.inPreferredConfig = Bitmap.Config.ARGB_8888; //Set the format of the Bitmap
}
}
Code: [Select]
package com.example.game.loaders;

import java.io.*;

import ai.pathfinding.Map;
import android.content.res.AssetManager;
import android.graphics.*;
import android.util.Log;

import com.threed.jpct.*;

/**
 * Helper class to load textures
 */
public class DataLoader {
public static Texture loadTexture(String path, AssetManager assetManager) throws IOException{
return loadTexture(path, assetManager, false);
}

public static Texture loadTexture(String path, AssetManager assetManager, boolean hasAlpha) throws IOException{
if(path == null){ throw new IllegalArgumentException("Path given is null"); }
if(assetManager == null){ throw new IllegalArgumentException("Asset manager is null"); }
return new Texture(BitmapFactory.decodeStream(assetManager.open(path), null, new BitmapLoadOptions()), hasAlpha);
}
}

    Also some questions:
    • If the total number of frames  in an Animation is needed a workaround is required: sum the length of all AnimationSequence-s or by call getKeyFrames().length, a separate method would be nice, or is there a better way?
    • Reusing a FrameBuffer after flushing the TextureManager will introduce a memory leak (probably not a bug simply because jpct is coupled loosly together) because the references to the Textures are still in the FrameBuffer. Didn't find this in the documentation: A call to http://www.jpct.net/jpct-ae/doc/com/threed/jpct/FrameBuffer.html#freeMemory%28%29 is required, this should be noted in the documentation in TextureManager.flush() and Framebuffer.freeMemory()
    • A method for getting the x/y/z rotation of a Object3D would be really, really nice, I still have no idea how to get the actual values out of the rotation matrix
    • Mind open sourcing the config chooser for the Tegra chips? No idea how to do this without the SDK from NVidia. You used some constant right?
      http://www.jpct.net/jpct-ae/doc/com/threed/jpct/util/NVDepthConfigChooser.html
      I had to use my own config chooser but I still require the better depth buffer so I can't use yours
    • Probably a bug or a non documented limitation: Textures with a size of 1x1 (2^0) and 2x2 (2^1) can not be created because jpct-ae says the size is too small. Didn't test 4x4 and upwards, or should this be like that? The loader code is the same code as posted above

    2
    German corner / Texture Compression in JPCT-AE
    « on: November 22, 2012, 03:07:47 pm »
    Platform: JPCT-AE (Open GL ES 2.0)

    Laut Doku kann man zwischen:
    • 24bpp (RGB888), wird beim laden konvertiert?
    • 16bpp (RGB444), wird beim laden konvertiert?
    • ETC1, Kompression nach dem laden der Textur?
    wählen.

    1) Wann wird konvertiert (ETC1 vor allem)? Erst beim hochladen zur GPU? Oder kümmert sich der Texture Manager darum? Oder schon der Constructor von Texture?
    1.1) Funktioniert ETC1 schon gut?

    http://www.jpct.net/jpct-ae/doc/serialized-form.html#com.threed.jpct.Texture
    Nachdem laut Dokumentation intern alles mit ints arbeitet:
    2) Ist der Speicherverbrauch für 16bpp/ETC1 genauso groß wie für 24bpp?
    2.1) Sind Texture Objekte bereits für den TextureManager verwendbar ohne das noch zusätzlich etwas an dem Objekt verändert wird? (würde gerne serialisierte Texturen verwenden)

    3) Feature Wunsch: Bitte RGB565 implementieren, Transparenz braucht ich fast nie, außer als Effekt Channel für Shader, würde trotzdem gerne RAM sparen.
    (1/3 Speicher weniger ist doch was)

    4) Wird beim regenerieren des GLContext nochmals komprimiert? Oder werden die "fertigen" Texturen nur in die GPU geladen?

    5) Werden beim regenerieren des GLContext die Texturen die vorher da (in der GPU) waren in die GPU geladen oder nur die dann aktuell benötigt werden?
    Stichwort: TextureManager.preWarm(fb) nochmal aufrufen um keine Ruckler zu haben?

    6) Kann man im voraus mit einem ETC1 Tool konvertierte Grafiken direkt (und schnell) laden? Ein zusätzlicher Konvertierungsschritt scheint unnötig.

    3
    German corner / Zwei Texturen mit unterschiedlichen UVs
    « on: October 15, 2012, 08:45:10 am »
    Frage zu: JPCT-AE

    Konkrete Anwendung: Wiederholte Textur auf einem Objekt, Lightmap soll auf dieses Objekt angewendet werden ==> Eigener UV Layer

    Problem: Wie kann man einem Objekt zwei verschiedene UV Layouts zuweisen ohne über den Polygonmanager zu arbeiten?

    Idee:
    • Objekt "normal" laden (UVs aus der 3ds Datei übernehmen, nicht manuell definieren), UVs werden hoffentlich für beide Texture Stages verwendet? (0 und 1)
    • Beide Texturen über TextureInfo anwenden, keine extra UVs angeben
    • Mit setTextureMatrix die Stage 0 auf das gewünschte UV Layout ändern (da man ja sonst nichts ändern kann außer die 0er)
    • Über einen Shader zusammenblenden (da der Shader ja Zugriff auf die Texturkoordinaten hat)

    Fragen:
    1)Kann das so funktionieren oder gibt es einen einfacheren Weg?
    2)Wie ist die TextureMatrix aufgebaut? Wie komme ich von der obj/3ds Datei die ein UV Layout enthält auf eine Texture Matrix?
    3)Beim hinzufügen (add) zu TextureInfo kann man UVs für ein Triangle angeben, was ist das?

    4
    German corner / Fragen zu jPCT-AE
    « on: July 16, 2012, 11:02:13 pm »
    Hi,
    ein paar Fragen zu jPCT-AE:

    1) Wird es Support/Bugfixes für die nächsten 12 Monate geben?
    1.5) Was passiert wenn es kein Interesse mehr an der Weiterentwicklung gibt? Wird das Projekt dann Open Source?

    2) Werden Feature Requests angenommen?

    3) Verwendet jPCT-AE mehr als einen Prozessorkern?
    3.5) jPCT ist nicht thread-safe, heißt das nur, dass man nicht auf Grafikobjekte außerhalb des Mainthreads zugreifen kann? Oder ist da mehr dahinter?

    4) Kann irgendwie gespendet werden?

    Pages: [1]