Would this be as fast as the rajawali method?

If it is, can you provide some example code? I tried doing something with the mesh and polygon manager....and I ended up having no clue what I was doing. 

Additionally, how can I change the color of each triangle in this array? I'm looking at the included document of the engine under the shader stuff, and I don't see anything about loading in an array of vertex colors...or an array of alpha values for the vertex points.

After being hung up with other projects, I'm finally able get back to this project.
In what you said about writing up my own shader and vertex arrays...is there a way I can piggyback the stuff on a Object3D? Or would it be easier to just skip the Object3D and do the whole thing from scratch?

I ask that because I like the features of camera/world classes and I'm not sure how to begin with writing up new classes to replicate those which are already made.

I've been working on making a 3D particle system for a class project. It's been going well so far....except for the speed.

At first, I was trying to do 3D objects (cubes), but half of the sides wouldn't be visible (plus, the particles would be small majority of the time unless they were near the camera). So I decided on doing them all in 2D with billboarding, and each object has only 2 triangles to worry about.
With this current setup, I'm getting around 30 fps with 100 objects and 5 fps with 400 objects. Which isn't the most appealing thing, since the game is supposed to have more particles (about 2k).

After checking out the Rajawali's implementation (http://www.rozengain.com/blog/2012/05/03/rajawali-tutorial-22-more-optimisation/) of a large particle system, I tried to do the same with jPCT (see, I'm not abandoning this engine).

First I was having problems changing the vertices (using the vertexController, still haven't completely got it working :-/) Then I found out that the code to change each particle's transparency/ color would no longer work in this method (because of how vertices share color with each other)

So, what would be the best way to do this system?
Requirements:
- particles which move in 3D space
- each particle has its own position/velocity/color/transparency/life
- many particles (around 2k) with a smooth frame rate
- dynamic creation of particles

Note: The particles don't need any high-quality stuff or collision. Although eventual gravity would be nice, it's on the far back burner.

I just finished the touch upgrade, so the actions take effect in the render thread only. Tested it with the 1.25, and there isn't any minor object disconnect like I saw previously. So I tried the beta you linked a few posts ago, and the game didn't have any glitches or fogging problem.

..so, it works :-). Thank you for your patience and help.


Edit: I re-enabled the line to render the scene only when needed (moving the objects and on the first frame), and the game still works. I get about 28 fps idle and 18 when moving around.

Yes, the touch events are taken care of as soon as they happen...I thought this was normal.
I created the class which controls all of what should happen for that screen (render, movements, actions, etc.), then fed that class to the renderer, then sent the renderer and previous class to the touch surface.
In the touch surface, I have the actions directly interfacing with the screen class, as opposed to the "queueEvent(new Runnable()....".

I'll try working on it now so the events are in the render thread, maybe by using a queue and run all the events before rendering/ drawing of the objects is done.


....I'm confused of how you're getting the same rendering glitches in the 1.25. The only model glitches I see in that version is there there is sometimes cracks between 2 objects, which are subtitley noticeable.

I'm sending you an email with a zip of 4 pictures (it would make this post too long if I tinypic'd them and they are too big to upload as an attachment through here).
The pictures were taken within the movement of 50-100 pixels (camera x translation of 1 - 2f) , or within one movement action. The game would flicker between types of these instances throughout the movement.

I haven't changed anything drastic since the version I sent you, so that copy should still work. The problem is visual in both the menu and gameplay. Drag left/right slowly and you'll be able to see the glitching better, but it works at any movement speed.

To go into the gameplay, have "Campaign" selected and hit "go". I'm working on the lag between menu/gameplay.

No good either. I added the jar, cleaned the project, remove the limit so renderscene is on every frame, (enabled the fps counter), then tested the game. And it still has the visual glitches.

I was just able to try the new jar...and it worked-ish. The fogging problem is fixed, but now there is graphical issues.
When moving left/right (which only effects the camera), the objects would flicker/ spin around as if the rotation is being forgotten. The camera would be on the opposite side of the object, or very far away, or drawing the object very close.

I have a class which interfaces the camera class. It has a cameraLook (Object3D), cameraPlace (Object3D) and a root (Object3D, the previous 2 are childs of this). After the look/ place are put in place (using the TranslateMesh), the game interacts with the camera movement by using the parent node only....the rotation and distance between the place/look are never changed thereafter.

I'm going to be revering back to the previous jar, the 1.25 version. It's easier to have a lighting problem than the objects flying around wildly when trying to move around.

Oh...now I can see of why you said it was surprising that it actually worked, lol.

I still haven't tried the jar yet, I've been busy with other things that are for this weekend.

I'm a bit confused on your reply. Currently I have it so it renders only the first scene or when the models are being changed, and on every frame it draws the scene (because it's parent class clears the framebuffer). I changed it from rendering every scene to only when needed to help prevent the phone from over-heating.
From what I can guess in your reply, your saying that the world.draw(fb) after the world.renderScene(fb) is a redundant call?

I'll try the jar as soon as I can.

Ok, it's sent. And thank you for helping me with the problems.

Hmm...ok. Well, currently, I don't have a stable release. Last night I started converting the project from one activity to multiple activities and the process isn't complete yet. I can't even give the classes in question because I've already changed them for the activity conversion. But, as soon as it's at a stable spot, I'll send the project.
What email can I send it to when it's ready (if the problem still persists)?


Edit: The game is at a stable release now and the problem is still there

Previously, the game had the "Config.glDebugLevel=1;" line in the creation of the render (which currently renders the menu and gameplay, I'm working on switching them to different activities). So I switched the line to be in onDrawFrame part of the render.


public void onDrawFrame(GL10 gl)
{
if(Screen == 1 && Screens.size() == 1)
{
Config.glDebugLevel=1;
Screens.put(1, new Gameplay());
}

fb.clear(back);

Screens.get(Screen).Render(fb);

//FPS(fb);
       
        fb.display();
}


but, the log seems to show nothing besides loading the objects and compiling them. There isn't even any gl calls like in the previous 2 logs.

I also changed the gameplay render function so it would draw the objects every frame...and nothing :-/


boolean firstR = true;
public void Render(FrameBuffer fb)
{
if((Touching || resetting) || firstR)
world.renderScene(fb);
firstR = false;

world.draw(fb);
//fb.clearZBufferOnly();
hud.Render(fb);
}


note: the renderer doesn't contain a world, only a framebuffer which it sends to the menu and gameplay classes. The creation of the gameplay/ menu class makes a new world just for that class.

I went through both logs now, looking for any differences...and I couldn't find any :-/. Does being an engine developer give you a more detailed eye than a normal coder would? lol

Anyway, if the log's aren't too helpful, I'd gladly send you the project for you to check out yourself.