Disable checking camera view for Object3D

[Thomas.]

Please, could you add two methods for Object3D to enable and disable (default is enable) checking models when are in camera view? (so everytime Object3D will be send to GPU without checking) I think, that could be very helpful for very simple objects like particles or light halo.
And does jPCT-AE support multithreading for this? Galaxy S2 has almost same result as Galaxy S...

Sorry for my English, I do not how better explain it...

[EgonOlsen]

That wouldn't make much sense...the visibility check for objects that are in view is very cheap. Both checks are just a simple if. About the multi-threading: No, it doesn't support this. The desktop version does but even there, it doesn't make much of a difference...if any. The additional overhead from maintaining multiple threads usually eats up the benefits in most cases (at least in this context).
On dual core phones, it might be feasible to do animations in different threads but not the geometry processing. At least not ATM.

[Thomas.]

So, what is it so expensive? render scene takes 2.7ms and draw scene 7.8ms, when I disable particle system, render 2.1ms and draw 3.8ms. And it is just about 50 particles, so 50 triangles...
edit: in both cases particles are not in camera view

[EgonOlsen]

Visibility detection already happens in renderScene(), not in draw(). No idea what causes the draw()-call to take twice the time without any visible particle. How much "not in camera view" is "not in camera view"? Because the visibility detection can be coarse at times. You might want to add an IRenderHook to your particles to check out when they are actually processed by the gpu and when they don't.

[Thomas.]

Particles are on the opposite side of the camera direction... If I understood correctly, when particles are not in camera view, methods beforeRendering and afterRendering are not called? Both are called and does not matter on camera direction and position. Position of particles seem be OK.

[EgonOlsen]

Yes, they shouldn't be called in that case. I'll check it out...which version of jPCT-AE are you using? If it's an older one, have you tried updating?

[Thomas.]

Probably the newest version of beta (file size is 303 087B)

[EgonOlsen]

Ok, i'll have a look at the object gross culling to see if i can reproduce this behaviour.

[EgonOlsen]

Just to be sure: How are you creating the objects for the particles?

[Thomas.]

by this:

Code Select Expand

public Particle() {
super(1);
addTriangle(new SimpleVector(-1, -1, 0), 0, 0, new SimpleVector(1, 1, 0), 1, 1, new SimpleVector(1, -1, 0), 1, 0);
getMesh().compress();
setBillboarding(Object3D.BILLBOARDING_ENABLED);
setAdditionalColor(RGBColor.WHITE);
setLighting(Object3D.LIGHTING_NO_LIGHTS);
enableLazyTransformations();
setVisibility(Object3D.OBJ_INVISIBLE);
//setRenderHook(rh);
build();
}

[EgonOlsen]

You are right. While it works fine for "normal" objects, something is fishy when flat objects like planes or single polygons are displayed (or better: not displayed...). I'll look at it...

[EgonOlsen]

Ahem...it was an optimization that i had added for particle effects that broke the whole thing for...particles... It's fixed now: http://jpct.de/download/beta/jpct_ae.jar

[Thomas.]

YES alright now ... so, why is so expensive rendering 100 simple objects with one triangle?

[EgonOlsen]

Because it requires 100 render calls including enabling/disabling of some states...render calls are pretty expensive.

[Thomas.]

ok, thanks