next »

[minikidder]

*pat_on_the_back*

First day of xith3d, let's see where this goes... I better not get lazy again and give up

Well what can I say, been trying to use jme3 before, but had to search for other engines because jme3 latest on svn is not working atm and not to mention they still have some holes in the intersection algorithm not always detecting intersections.
 Anyway, I want to do something simple for myself, and visualize a directed graph in 3D... I'm thinking of using berkeleydb for storage (although neo4j would maybe be better).
 In 3D though I will likely have like 10 million let's say nodes and I was wondering how can this be handled with xith3D, without getting 0fps ... assuming most nodes would be something like spheres but yet they can be created/deleted at runtime, ... yeah don't know yet...
 I will also employ some algorithm from forg3d I believe, for dynamically laying out the graph, so the nodes don't occupy same space for example... I already translated the Euler part from C to java but I now need the storage and 3D parts

Not sure what else to blabber about maybe I should go and check out the examples in xith-tk

Btw, thanks for coding xith
so far so good.

[Marvin Fröhlich]

You might want to consider using cubes instead of spheres, because they can consist of much less polys.

You shouldn't create each logical node as one shape, but create bigger shapes, where each holds more than one cube. This saves a lot of  performance. Use indexed geometry to be able to switch parts of it on and off.

[minikidder]

Sure thing, I can use cubes...
I may not understand what else you said but I will reread this as I gather more understanding. Now I'm just wondering if a cube is also a shape and grouping a bunch of cubes can become a shape and if yes then can I still individually change the other shapes? or even group/ungroup them so they become one shape when no changes to them are needed to be done and then ungroup as many shapes so that when I for example add another sibling cube so they need to react between them and space out to make room for new cube.
 I'm guessing that since multiple cubes are now one shape, something like only one rendering call needs to be made, rather than one for each cube. And this would be the saving of performance. If so then, maybe I could have just one big shape containing all cubes, so I do only one call rather than 1 million render calls (even though this call is done automatically), and then find a way to be able to modify the cube's position/rotation ... because they need time (real time) to expand such that they are not occupying the same space...
 about the indexed geometry, I'm not sure what that is xD maybe used to cull ? and not draw the parts outside of frustum of behind other cubes, but I thought this was done automatically; I'll get back to this I guess, after I understand more about 3D and xith.

Thanks btw!

[Marvin Fröhlich]

I'm guessing that since multiple cubes are now one shape, something like only one rendering call needs to be made, rather than one for each cube.
And this would be the saving of performance.

Yes, this is quite exactly, what saves performance. Additionally the driver can handle 3000 vertices in a single buffer more efficiently than 100 buffers of 30 vertices each.

If so then, maybe I could have just one big shape containing all cubes, so I do only one call rather than 1 million render calls (even though this call is done automatically), and then find a way to be able to modify the cube's position/rotation ...

Well, there are always trade-offs. OpenGL can handle buffers of 4096 vertices optimally (IIRC). So you should chunk your geometries into these sizes. Additionally it is more efficient to update 4096 vertices in case you need to change at least one of them then to update all 1 mio.

As for the rest: You should work through all the examples of Xith-tk, especially the ones about scenegraph and geometry. After that your other questions should all be answered automatically.