next »

[olamedia]

How can i hide nodes completely or hide some sides?

The performance of next code is about 3-6 fps on my machine.
Previous test i made for jogl alone, hiding some boxes and sides, resulted in 60-70 fps.

Code:

int size = 100;
for (int x = 0; x <= size; x++) {
for (int y = -4; y <= 0; y++) {
for (int z = 0; z <= size; z++) {
Texture grass = ResourceBag.getInstance().getTexture(
RES_TEX_GRASS);
grass.setFilter(TextureFilter.POINT);
Box b = new Box(x - 50, y, z - 100, 1, 1, 1, grass);
b.setIsShadowReceiver(false);
Appearance app = b.getAppearance(true);
app.setMaterial(new Material(Colorf.WHITE, Colorf.BLACK,
Colorf.WHITE, Colorf.BLACK, 0.8f, Material.AMBIENT,
true, true));
bg.addChild(b);
}
}
}

I saw some methods (ex. Box.combine) at openmali, but seems it doesn't used by xith.

Ardor3D has MeshCombiner for that reason

Code:

Mesh merged = MeshCombiner.combine(origNode);

What should i use writing with xith3d.

[Marvin Fröhlich]

The Box code from OpenMaLi is purely mathematical. It doesn't combine scenegraph geometries.

I don't think, there is code to combine to boxes automatically. Though, if you construct them from triangles (not strips), you can simply copy the vertices into one big vertex array. And if there are gaps between the cubes, you don't have any choice, but to use triangles.

The preferred way to toggle a node (your boxes) on and off is to use the setRenderable() method on the shapes.

Your scene consists of 51005 boxes, that are simply managed in one big TransformGroup. This is really unoptimized for such a big number of shapes. You should at least group nearby boxes into simple GroupNodes, so that the renderer can check visibility for whole box-groups. Well, if your boxes are all visible at the same time, you've got a problem.

[olamedia]

well, how to turn off one side only?
probably i need create custom geometry while merging boxes...

Is it possible to make "quads" then merging them with some method into one geometry?

if your boxes are all visible at the same time

Yes, for "normal" view distance minecraft shows 128 blocks ahead, so for "plains" i need to show at least 128 blocks.

Currently i'm choosing engine and i like xith3d for it's rich model & image format support, picking systema and frustrum culling and a whole scenegrapth.

For jogl i was using only display lists, no VBO.
Is xith3d using VBO by default? I'd like to combine each 16x16 chunk into single mesh then using it as a single VBO. (and then reconstructing VBO for changed chunk only)

Also jogl implementation took 30Mb only, while this 300Mb.

Another question - is it possible to get jogl's GLAutoDrawable to render simple blocks directly? And still use xith3d's picking system...

org.xith3d.render.DefaultRenderer.renderOnceInternal() 80%
    org.xith3d.render.RenderPeer.renderAtom() 50%
        org.xith3d.render.lwjgl.DisplayListRenderPeer.playbackDisplayList() 20%
        org.xith3d.render.lwjgl.MaterialStateUnitPeer.apply() 20%
    org.xith3d.render.preprocessing.FrustumCuller.cullAtoms() 10%
    org.xith3d.render.DefaultRenderer.sortAllAtoms() 23%

._____.

I'm sure i don't need sorting as blocks are always sorted in world.
Is sorting required for culler or picking?
Also binding material is very expensive >_<

[Marvin Fröhlich]

Sorting is done automatically.

VBOs should be used by default, if supported, though DisplayLists are faster and are preferred when it makes sense. But you can control that through Geometry.setOptimization().

For your big scene I suggest using indexed geometry. DisplayLists can not be used then though. You can put everything into one big Geometry and control through index, what's enabled and what not. But be aware, that there's an upper bound, that you shouldn't exceed. Make sure, your VBOs don't get bigger than 64000 vertices, IIRC. I suggest to look that boundary up just to make sure.

Xith has two separate picking systems. One is a pure software implementation (PickingLibrary). And the other one is the OpenGL picking, that should also do it's job, if you render something directly. I guess, you're aware of Xith's direct OpenGL access, are you?

[olamedia]

Sorting is done automatically.

VBOs should be used by default, if supported, though DisplayLists are faster and are preferred when it makes sense. But you can control that through Geometry.setOptimization().

Well.. VBO can be used with display lists together, i think, yes?

For your big scene I suggest using indexed geometry. DisplayLists can not be used then though. You can put everything into one big Geometry and control through index, what's enabled and what not. But be aware, that there's an upper bound, that you shouldn't exceed. Make sure, your VBOs don't get bigger than 64000 vertices, IIRC. I suggest to look that boundary up just to make sure.

4913 is max vertices count for 16x16x16 chunk using indexed geometry.
1446 for solid chunk; 578 for one side exposed.

Xith has two separate picking systems. One is a pure software implementation (PickingLibrary). And the other one is the OpenGL picking, that should also do it's job, if you render something directly. I guess, you're aware of Xith's direct OpenGL access, are you?

OpenGL picking is not very good probably... (I tried it, even rendering custom scene for it, without materials) but talking about geometry groups i found that i can check picking against chunks at first then choosing concrete block. Am i able to use xith's software picking in a custom way? probably 1) setup chunk's boxes, 2) run picking 3) setup boxes from picked chunk 3) run picking... Or some faster direct way...

So now the primary question: Can I use xith's picking and frustrum culling (some methods) directly for a some custom "box" (group of chunks->chunk->box->etc.. slowly narrowing choice)? How to disable sorting (all boxes are opaque)?

And no, I'm still not aware of direct access options.

11% takes org.xith3d.render.preprocessing.FrustumCuller.addShapeAtom()
20% takes org.xith3d.render.DefaultRenderer.sortAllAtoms()

Can I switch them off for boxes, leaving on on groups?

[Marvin Fröhlich]

Well.. VBO can be used with display lists together, i think, yes?

No, VBOs are meant as a replacement for DisplayLists. Though my experience tells me, that display lists are still faster.

Using display lists together with VBOs would mean a lot of wasted memory, since the VBOs would not be used instead for the first frame, where the display lists are recorded.

4913 is max vertices count for 16x16x16 chunk using indexed geometry.
1446 for solid chunk; 578 for one side exposed.

Thanks, good to know the exact numbers.

OpenGL picking is not very good probably... (I tried it, even rendering custom scene for it, without materials) but talking about geometry groups i found that i can check picking against chunks at first then choosing concrete block. Am i able to use xith's software picking in a custom way? probably 1) setup chunk's boxes, 2) run picking 3) setup boxes from picked chunk 3) run picking... Or some faster direct way...

Check the PickingLibrary's methods. Some of them take interface implementations for pick testing. Hopefully this helps you to customize the behavior.

But early group testing is done in both picking strategies (OpenGL- and software picking). So I don't expect, that you can optimize the code except of you use more complex group nodes like tree implementations. But if you can optimize the code, please share your improvements.

So now the primary question: Can I use xith's picking and frustrum culling (some methods) directly for a some custom "box" (group of chunks->chunk->box->etc.. slowly narrowing choice)?

The picking system is not designed to be used standalone. But all the frustum culling test methods come from OpenMaLi. So you can use them even without Xith.

How to disable sorting (all boxes are opaque)?[/b]

Have a look at the render options. They should allow you to change the sorting strategy or disable it.

And no, I'm still not aware of direct access options.

The BranchGraph should provide a callback to render directly. If you can't find it, I can look it up when I am at home.