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 - jpro

Pages: [1]
1
Support / Terminology of Object3D
« on: December 09, 2011, 03:59:40 pm »
I have a prototype I've been working on, which I originally started in OpenGL and am trying to port over to JPCT. The majority of this transfer was quite painless - JPCT is way easier to use than base OpenGL calls, and I can only see the benefits getting larger as the project progresses. However, I've not yet been able to get the same performance as the OpenGL solution. This morning I was thinking that a big part of the problem is I don't exactly know what some of these Object3D functions do behind the scenes.

From a high level, I view an Object3D as a set of triangles that, when added to a World, will be rendered. But that's perhaps not even accurate, and there's also several functions that need to be called that are in a lot ways very black-box in their description.

Here are the functions I'm curious about:

Quote
public void build()
Initializes some basic object properties that are needed for almost all further processing. build() should be called if the object is "ready to render" (loaded, Textures assigned, placed, rendering modes set...).
Adding new triangles to an object after calling build() may work but doesn't have to. If you want to do this, call unbuild() before.

Based on this description this tells me an Object3D is initially in a state that is not renderable. At a high level what does build do to make it renderable?

Quote
public void compile()
Compiles an Object3D. Don't confuse this with build(), which does something completely different. A compiled object can be rendered faster when using the hardware renderer but has some shortcomings...

Based on the Javadoc I'm assuming this sets up the Object3D in a display list or VBO (depending on settings).

2
Support / Merging Primitive planes
« on: December 01, 2010, 08:37:25 pm »
Is there any reason I shouldn't do:

Code: [Select]
Object3D plane1 = Primitives.getPlane(1, 10f);
Object3D plane2 = Primitives.getPlane(1, 10f);
plane2.rotateX((float) Math.toRadians(90));

Object3D merged = Object3D.mergeObjects(plane1, plane2);
world.addObject(merged);
world.buildAllObjects();

When I do so only one plane is visible.

3
Support / Performance with many objects
« on: November 02, 2010, 03:26:17 am »
Is there something I should be doing to prevent rendering objects that are not visible? In the simple demo app I've developed I build a 4x4x4 grid of cube Object3Ds, stacked into a block. That gives me around 250 FPS. If I increase the size of the stack to 16^3 or 4096 Cubes, FPS drops to about 15. I originally was doing this as a physics demo so I went ahead and disabled the physics entirely but that didn't change anything. Profiling the code indicates the bottleneck is rendering.

A lot of the cubes (the ones in the center) are not visible at all, but I imagine they are still being updated/rendered in some way? Is there something I should be doing to prevent this? Unless I'm mistaken I can't merge them into some united list or object, since the physics engine will be altering them individually.

Many apologies if this is obvious or has been covered. I spent about two hours trying to find a solution but nothing has worked yet so I got desperate.

edit:

Some of what I read online indicates that this type of culling is mostly unnecessary. If so, why does my performance drop so much when rendering a lot cubes? I'm not doing anything fancy like turning off back face culling.

Pages: [1]