www.jpct.net
jPCT-AE - a 3d engine for Android => Support => Topic started by: MichaelJPCT on June 05, 2017, 07:31:54 am
-
i want to enlarge a bound box as the shader for the object3d enlarges the object.
after i setboundingbox, is there anything in the engine that may reverse the bound box back to the smaller one?
i ask this question because another engine would recalculate the bound box automatically.
-
i tried setboundingbox at runtime, after build(), but i didn't see any effect - the bound box was still small.
-
It's permanent until you call build() again. What do you mean by "I didn't see any effect"?
-
my shader modifies vertex position so that the model look larger than the actual Mesh defined.
but the bound box is as large as the defined Mesh.
so if a small portion of the modified model should be visible but the defined Mesh is out of view, the model is not rendered.
so i want to enlarge the bound box to be the same as the modified model.
but it didn't work - the model is still not rendered if the defined Mesh is out of view.
-
Then you are doing something wrong. Make sure to set the bounding box after calling build() and that you neither call build() or calcBoundingBox() afterwards at any time.
-
i am sure setboundingbox is called after build().
after i create the object3d, i call getMesh().compress() -> build() -> strip(), can these affect the result?
-
No, actually not. You can obtain the bounding box from the object. Just log the results while the app is running and see if that fits the values that you have set. If yes, then maybe your BB hasn't the size that it has to have. If no, something modifies the BB later in the process.
-
how to obtain the BB? i don't see getBoundingBox() method.
-
It's part of Mesh: http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Mesh.html#getBoundingBox() (http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Mesh.html#getBoundingBox())
-
i called setBoundingBox with larger values, then called getMesh().getBoundingBox(). i got the small , original values.
and i am sure my program doesn't change the BB after i call setBoundingBox.
-
That can't be!? Some code changes the bounding box afterwards, either explicit by calling build() or calcBoundingBox() or implicit by cloning the Object3D and letting jPCT-AE auto-build the cloned object or something like that. Keyframe animations will modify the BB as well.
But just to be sure: After setting the new bb...if you then call getBB immediately after, are you getting the correct results?
-
i tried calling getBoundingBox immediately after setBoundingBox, the value i got was the small, original one, not the larger one i set.
but the javadoc says getBoundingBox triggers a recalculation, so getBoundingBox should output the original value, right?
-
You are of course right...sorry, I forgot about that behaviour. Well, in that case, it's not an option to use that method. Anyway, your approach should work fine. I don't see, why it would fail unless your BB isn't reset or it's not big enough. Have you tried what happens if you set it to a very small one? Does that change anything?
-
i tried, smaller value has no effect either.
-
Then something resets the box. Can you create a test case for this issue?
-
see below. in the sample, you can see a triangle suddenly disappears when fov changes, while it shouldn't.
i found if the shape is created by Primitives.getBox, setBoundingBox works correctly.
import com.threed.jpct.*;
import javax.microedition.khronos.egl.EGLConfig;
import javax.microedition.khronos.egl.EGLDisplay;
import javax.microedition.khronos.opengles.GL10;
import android.opengl.GLSurfaceView;
import android.os.Bundle;
import android.app.Activity;
public class Sim extends Activity {
static GLSurfaceView GLview;
static MyRenderer rend;
static FrameBuffer frmBuf;
static World world=new World();
static Camera cam=world.getCamera();
static float fov=1f;
static Object3D shape;
static String glslV="uniform mat4 modelViewProjectionMatrix;"+
"attribute vec4 position; void main(){ vec4 p=position;"+
"p.y*=2.0; gl_Position=modelViewProjectionMatrix*p; }";
static String glslF="void main(){gl_FragColor=vec4(1,1,1,1);}";
static GLSLShader glsl=new GLSLShader(glslV,glslF);
protected void onCreate(Bundle a) {
super.onCreate(a);
rend=new MyRenderer();
GLview=new GLSurfaceView(getApplication());
GLview.setEGLContextClientVersion(2);
GLview.setRenderer(rend);
setContentView(GLview); }
class MyRenderer implements GLSurfaceView.Renderer {
public void onSurfaceCreated(GL10 g,EGLConfig c) {
shape=new Object3D(new float[]{5,0,0,0,-5,0,-5,0,0},null,new int[]{0,1,2},-1);
shape.build();
shape.setBoundingBox(-100,100,-100,100,-100,100);
world.addObject(shape);
shape.translate(0,15,50);
world.setGlobalShader(glsl);
cam.setFOVLimits(0.001f,1); }
public void onSurfaceChanged(GL10 g,int w,int h) {
if (frmBuf!=null) frmBuf.dispose(); frmBuf=new FrameBuffer(w,h); }
public void onDrawFrame(GL10 g) {
frmBuf.clear();
fov-=0.002;
if (fov<0.1) fov=1f;
cam.setFOV(fov);
world.renderScene(frmBuf);
world.draw(frmBuf);
frmBuf.display(); } }
}
-
Thanks, I'll look into it.
-
Now that was a funny one...For single polygon objects, the engine applied an optimization for the bounding box culling, so that it actually used the polygon for culling, not the box (less work to do that way). That has been added to speed up particle effects on slower devices, but it obviously couldn't handle your special case. This version should fix the problem: http://jpct.de/download/beta/jpct_ae.jar (http://jpct.de/download/beta/jpct_ae.jar)
-
in my actual app, the shape is a quad -- 2 triangles, same problem.
do you mean the new version would slow down particle rendering? if so , i would prefer the old version. there is other way to solve the culling problem - make the shape larger and modify the shader.
since you don't keep branches of the engine, i like the one with faster performance. you just need to tell (in javadoc) people why setBoundingBox doesn't work in some case.
-
The optimization applies to quads as well. It's still in there, just not used anymore in all cases. I don't think it will impact performance in any way noticable.