Looks like there's no way (without changes) to define the bounds color on the user side. BoundsAtomPeer.drawBounds() takes a color argument. But the caller (ShapeAtomPeer) doesn't pass anything but null, which defaults to red bounds.

I suggest to make ShapeAtomPeer use some kind of appearance to pass a proper color to drawBounds(). Feel free to change that.

I need to look that up. Please remind me, if I haven't done that over the weekend.

Oh wow. This is a long time ago. I have to admit, that I don't remember that at my advanced age. But I would say, that BSPTreeGroup is not good for a dynamic model. BSP is efficient for static geometry. QuadTreeGroup is also meant for scenes on flat terrain, since it theoretically only optimizes 2D geoemtry. I would recommend OcTreeGroup.

I assume, all of these shapes should be rendered at the same time. So a Switch node or MultiShape3D wouldn't be an option, right? In this case there would be no better option than using an array of shapes.

Well, depending on your usecase it might make sense to put the shapes into some kind of tree structure to optimize rendering.

Thanks a lot.

When you take a look at the DaeLoader you'll find some abstract factory methods, that serve to feed the animation data objects. You can use them to add data yourself without having the loader load them.

Unfortunately the SkeletalKeyframeController lacks a getter for the Skeleton instance. You would need to add one to get access to the skeleton, which in turn provides you with all the skeletal data.

About the messed up texture coortinates I have to say, that there might be a bug in the loader. Would you mind checking the loader code?

It comes with the package.

Possibly. I wrote the loader quite straight forward from the specs. Of course there can be bugs. But possibly the exporter doesn't precisely respect the specs.

The try-catch around the for-loop isn't really a fix. It doesn't only make the whole think a lot slower, but also doesn't fix the problem. The loader must handle the issue and set the missing weights to 1.0 values.

https://jagatoo.svn.sourceforge.net/svnroot/jagatoo/trunk

Looks like there is a bug in the loader. Unfortunately I don't have the time to check it. Would you mind having a look at the loader code, where the bone wheights are read? It is in MD5MeshReader.load() in the JAGaToo project. Some of the boneWeight[][][] objects seem to be null.

[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)?]

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.

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?

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.

Thanks for the hint. Well, it is a little outdated. Though it should still basically work. And there's nothing about Ant.