Continuing from #567, it seems that there is a general consensus that the animation system needs an overhaul.

Everyone seems to agree that the GL thread should be responsible for managing animation time steps. The exact means of doing this seems to be up in the air still so as @AndrewJo suggested, I am creating a new issue here to continue the discussion.

TODO

• [x] Rewrite base animation class.
• [x] Rewrite animation queue
• [x] Add and test new ColorAnimation3D
• [x] Adapt and test BezierPath3D
• [x] Adapt and test CatmullRomPath3D
• [x] Adapt and test RotateAnimation3D
• [x] EllipticalOrbitAnimation3D
• [x] ~~Adapt and test RotateAroundAnimation3D~~ (deprecated for EllipticalOrbitAnimation3D)
• [x] ~~Adapt and test RotationAnimation~~ (deprecated and consolidated into RotateAnimation3D)
• [x] Adapt and test ScaleAnimation
• [x] Adapt and test TranslateAnimation3D
• [x] Fully test all core animation functionality
• [x] Update RajawaliExamples to use new animation code.
• [x] Update Rajawali Wiki to use new animation code.

After 2 full months of development, the Blue Marble HD is finally live. Thank you to all the members on Rajawali GitHub and those who provided all the help.

Screenshots

DECISIONS WILL BE MADE SOON ON A SITE, MAKE SURE YOU CHECK OUT THE MOCKUPS AS THE WEEK GOES ON AND LEAVE YOUR FEEDBACK Mockups for new site

As you may know we are moving to put the project in a more organized state. Part of this organization effort is to create a website that better supports all of the useful documentation for the Engine. As such we need a plan on what the site should look like and what functions it will serve.

Status

• [x] What features must the site have, we need to answer this before we can move forward at all. Requirements requirements requirements!
• [x] How do we edit pages, what limitations are we bound to? I am guessing that the site is limited to HTML only so we can not run any server side goodness.
• [x] How should the site look? This will likely be a process of finding some candidates and slowly narrowing it down to something we can all, or just Dennis, agree on.

Requirements

• A list of features, particularly those that make Rajawali stand out. For me being 4.0+ and no NDK makes Rajawali immensely attractive now.
• A general breakdown of how the rendering process in Rajawali is intended to work
• Host the wiki? Or should this stay put?

Overall

• A simple, uncluttered layout. Responsive (mobile/desktop friendly).
• Small Rajawali logo (top left)
• Menu at the top (top right) (Gallery, Tutorials, Documentation, Issues, Team)
• Light colours
• Google AdSense integration

Homepage

• Short description of the framework with some of the key features (4.0+, no NDK, ES 2.0, etc)
• 6 or 8 square images of the most beautiful Rajawali apps/wallpapers. With a link to the complete gallery.
• "Start building 3D content now" with a link to Github (tags & unstable version w/ disclaimer)
• Icons w/ short description + links to same items as menu (Gallery, Tutorials, Documentation, Issues)

Gallery

• Square tiles with links to Google Play. Clean, simple layout

Documentation

• JavaDoc but sexier than it currently is, well integrated with the site

Issues

• Basically just links to the Github Issues page

Team

• Team profiles. Avatar, short description, role + social media links.

Mods, feel free to edit this post as needed to add clarity or update as progress is made.

I have a Plane that is my application's world. Also, I have a Camera that moves along X axis in front of that plane. Camera Z = 8, Plane Z = 1. I need to determine that my camera reached left or right border of a Plane and so my view is not out of this Plane.

How it could be implemented ?

Hi,

While loading an obj file it gets rendered with about half the triangles that compose it, as in the attached picture.

I can't post the obj file for copyright reasons but I can assure you that it's always this way even if processed with blender or meshlab. Both of them correctly display the model and the associated texture that, by the way, is also not displayed even though it's loaded as I see the log message 'hastex ...'

There are no errors or warnings in the logcat.

What's happening here?

(ps: I use the VuforiaRajawali extension)

I saw a doubt like what I have, but did not see the solution ...

I'm creating my live wallpaper based on the template. but the effect does not work in normal activity was as follows:

public void onCreate (Bundle savedInstanceState) {
super.onCreate (savedInstanceState);
setGLBackgroundTransparent (true);
mRenderer RajawaliRipplesRenderer = new (this);
mRenderer.setSurfaceView (mSurfaceView);
super.setRenderer (mRenderer);

mSurfaceView.setOnTouchListener (this);

Display display = getWindowManager (). GetDefaultDisplay ();
mScreenSize = new Point ();
mScreenSize.x display.getWidth = ();
mScreenSize.y display.getHeight = ();

LinearLayout ll = new LinearLayout (this);
ll.setOrientation (LinearLayout.VERTICAL);
ll.setGravity (Gravity.BOTTOM);

TextView tv = new TextView (this);
tv.setText ("Touch Me");
tv.setTextColor (Color.BLACK);
ll.addView (tv);

initLoader ();
}

and livewallpaoer have this:

onCreateEngine public Engine () {
mRenderer RajawaliRipplesRenderer = new (this);

return new WallpaperEngine (this.getSharedPreferences (SHARED_PREFS_NAME,
Context.MODE_PRIVATE) getBaseContext (), mRenderer, false);
}

WORKING BRANCH

This post is so that I can layout my idea for how a texture atlas could/should work. Since this is on the challenging side for me I wanted to ensure I got some input from the gurus.

Concept

Texture atlas code has been written a thousand times over, and there is a lot of data that says to keep things simple. I am going to be adapting some code for mobile and Rajawali, the forked source can be found here.

Basically, a new class TexturePacker.java would be created and would handle the bulk of the work, and it would return a new object type TextureAtlas which can hold the data about each "tile" in the atlas as well as the atlas Bitmaps

public TextureAtlas mTextureAtlas = TexturePacker(String atlasName, int atlasWidth, int altasHeight, int padding)

TextureAtlas would contain the altasBitmaps, and a list of file names and coordinates(X,Y,W,H) for each texture packed into the atlas.

I am thinking there should be a getter to retrieve the image coordinates needed for a given object. Something like -- TextureAtlas.getCoords(String textureFileName). We then need a way to translate those coordinates into UVs.. this part is still hazy for me. Once the developer has the UVs they can simply get the appropriate atlas Bitmap by using another getter -- `TextureAtlas.getAtlas(String textureFileName).

Scope

Loading

1. Designate folder and populate with textures
   • Possibly drawable-nodpi, and append a prefix/suffix to each texture
   • Custom folder accessible at runtime (if possible I would need some suggestions)
2. Retrieve files from target folder
   • Capture file name, width, and height of each

Packing

1. Developer defines the size of the atlas on construction
2. Utilize this algorithm for simple and efficient packing
   • Store coordinates of each tile as it is placed with reference to the original file name
3. Collect loaded Bitmaps into a Canvas
   • Draw as many Bitmaps as needed to accomodate all files in the target folder
   • Support compression of final Bitmaps??
4. Return a TextureAtlas will all collected data and atlas Bitmaps

Retrieval

1. Getters will allow retrieval of all, or specific data within the TextureAtlas
2. Return the correct atlas bitmap based on file name
3. Return correct coordinates based on file name
   • Convert texture coordinates to UVs (need some direction here)

Uncertainties

Compression support is possible, but I'm not sure it make sense. It seems that a bitmap could be returned and the "on-the-fly" compression could be implemented is the developer so desired. I don't think that this should support compressed textures on input.

Is there a better way to collect the images besides a Canvas? Any prodding in the right direction is super helpful.

Please give me whatever feedback you can, I will do my best to learn whatever I need to to get this done properly. Thanks!!

Enhancement Info Needed Review Discussion 

Hi, issue #166 is closed, but i'm not sure what needs to be done...

I tried loading an .obj file with a transparent texture, but the transparent areas appear to be black. Is there a solution for this?

Just a heads up. All of the LWP's listed on this repository, with the exception of the ferrari one, glitch while in the preview. Once set they are fine. To be more specific, MonkeyIsland items end up in different positions. Most of them fluctuate between increasing in size(stretching) and then reduction is size(squeezing). What I've found with my own projects as well is the same results especially if you start adding more features like PhongMaterials, etc. I'm not sure if this is just a SGS3 issue or not but thought I should bring it to everyone's attention. Is this a simple fix? Would loading a serialized model instead solve this?

Problem

The TextureManager class currently has no less than 56 methods that do basically the same thing: add textures. This is a proposal to simplify the API and to make the TextureManager more compact. Your feedback (especially @AndrewJo) is appreciated.

Solution

Leverage the existing TextureInfo class. Most of the parameters that are passed to the addTexture() methods are already part of the TextureInfo class.

A significant change is that TextureInfo will be used as input instead of output. This way the number of addTexture() methods can be reduced from 56 to 10.

Implementation

TextureInfo class properties:

public class TextureInfo {
    int mTextureId;
    int mUniformHandle;
    int mWidth;
    int mHeight;
    int mInternalFormat;
    int mBitmapFormat;
    boolean mMipmap;
    boolean mShouldRecycle;
    boolean isCubeMap;
    boolean isExistingTexture;
    String mTextureName;
    TextureType mTextureType;
    WrapType mWrapType;
    FilterType mFilterType;
    Config mBitmapConfig;
    CompressionType mCompressionType;
    PaletteFormat mPaletteFormat;
    ThreeDcFormat mThreeDcFormat;
    AtcFormat mAtcFormat;
    Dxt1Format mDxt1Format;
    PvrtcFormat mPvrtcFormat;

    Bitmap mTexture;
    Bitmap[] mTextures;
    ByteBuffer[] mBuffer;
    ...

New TextureManager methods:

public class TextureManager {
    void addTexture(TextureInfo info);
    void addTexture(TextureInfo info, Bitmap texture);
    void addTexture(TextureInfo info, Bitmap[] textures);
    void addTexture(TextureInfo info, int resourceId);
    void addTexture(TextureInfo info, int[] resourceIds);
    void addTexture(TextureInfo info, ByteBuffer buffer);
    void addTexture(TextureInfo info, ByteBuffer[] buffers);
    void addTexture(TextureInfo info, ByteBuffer buffer, Bitmap texture); // manually mipmapped textures
    void addTexture(TextureInfo info, ByteBuffer[] buffers, Bitmap texture); // manually mipmapped textures
    void addTexture(TextureInfo info, InputStream compressedTexture, Bitmap fallbackTexture);
    ...

Usage

// -- simple texture config
mTextureManager.addTexture(new TextureInfo(TextureType.DIFFUSE), myTextureBitmap);

// -- advanced texture config
TextureInfo info = new TextureInfo();
info.setTextureType(TextureType.DIFFUSE);
info.shouldRecycle(true);
info.setWrapType(WrapType.REPEAT);
info.setCompressionType(CompressionType.ETC1);

mTextureManager.addTexture(info, compressedTexture, fallbackTexture);

// -- Cube maps
TextureInfo info = new TextureInfo(TextureType.CUBE_MAP);
info.shouldRecycle(true);

mTextureManager.addTexture(info, textures);

Still in Question

Should Bitmap, Bitmap[] and ByteBuffer still be part of the TextureInfo class? Semantically it is incorrect I think.

These properties are only used when the textures shouldn't be recycled. This way the texture can be uploaded again when the OpenGL context needs to be re-created. This can be flagged by the user by setting info.shouldRecycle() to false.

An alternative solution would be to store these in the TextureManager class.

Should the class be called TextureInfo or should it be renamed to TextureConfig?

Enhancement Info Needed Review Discussion 

This was initially brought up in #543 but I thought it deserves a dedicated discussion.

I have had need of adding and removing objects from the scene at run time after it is initially created primarily for testing the scene graph stuff I'm working on but I believe I will need to do this in the app that I am currently working on as well. I am planning to work on a solution to this after I finish up the scene graph so I would like to start getting peoples thoughts on a good way of doing this. I know something to this effect could be accomplish by controlling if things are hidden or not but this seems cumbersome and not fully effective to me.

@ToxicBakery suggested a queue of some kind but from what I understand has concerns about the overall latent weight this would have. Following @MasDennis's suggestion in #112 someone can add object in onDrawFrame() but iterating them has some definite concurrency risks, which have been reduced with #546.

I will need something to be able to do this so I certainly don't mind doing it in a way you guys would be agreeable with. Anyone have some thoughts to share?

TODO List

• [x] Create queue and queuing functions
• [x] ~~Add PostProcessingFilter support~~ Not handling this at the moment
• [x] Update RajawaliExamples
• [x] Handle Add Task
  • [x] Animation
  • [x] BaseObject3D
  • [x] Camera
  • [ ] Lights
  • [x] Plugins
  • [x] Texture
  • [x] ~~PostProcessingFilter~~
• [x] Handle Remove Task
  • [x] Animation
  • [x] BaseObject3D
  • [x] Camera
  • [ ] Lights
  • [x] Plugins
  • [x] Texture
  • [x] ~~PostProcessingFilter~~
• [x] Handle Add All Task
  • [x] Animation
  • [x] BaseObject3D
  • [x] Camera
  • [ ] Lights
  • [x] Plugins
  • [x] Texture
  • [x] ~~PostProcessingFilter~~
• [x] Handle Remove All Task
  • [x] Animation
  • [x] BaseObject3D
  • [x] Camera
  • [ ] Lights
  • [x] Plugins
  • [x] Texture
  • [x] ~~PostProcessingFilter~~
• [x] Handle Replace Task
  • [x] Animation
  • [x] BaseObject3D
  • [x] Camera
  • [x] Lights
  • [x] Plugins
  • [x] Texture
  • [x] ~~PostProcessingFilter~~

Bumps espresso-core from 3.5.0 to 3.5.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps junit-ktx from 1.1.4 to 1.1.5.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps runner from 1.5.1 to 1.5.2.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps junit from 1.1.4 to 1.1.5.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps kotlin_version from 1.7.22 to 1.8.0. Updates kotlin-gradle-plugin from 1.7.22 to 1.8.0

Updates kotlin-stdlib from 1.7.22 to 1.8.0

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.